<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    paulwong

    Redis與Memcached的區別(轉)

     如果簡單地比較Redis與Memcached的區別,大多數都會得到以下觀點:
    1 Redis不僅僅支持簡單的k/v類型的數據,同時還提供list,set,hash等數據結構的存儲。
    2 Redis支持數據的備份,即master-slave模式的數據備份。
    3 Redis支持數據的持久化,可以將內存中的數據保持在磁盤中,重啟的時候可以再次加載進行使用。

    在Redis中,并不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別(我個人是這么認為的)。

    Redis只會緩存所有的key的信息,如果Redis發現內存的使用量超過了某一個閥值,將觸發swap的操作,Redis根據“swappability = age*log(size_in_memory)”計算出哪些key對應的value需要swap到磁盤。然后再將這些key對應的value持久化到磁盤中,同時在內存中清除。這種特性使得Redis可以保持超過其機器本身內存大小的數據。當然,機器本身的內存必須要能夠保持所有的key,畢竟這些數據是不會進行swap操作的。

    同時由于Redis將內存中的數據swap到磁盤中的時候,提供服務的主線程和進行swap操作的子線程會共享這部分內存,所以如果更新需要swap的數據,Redis將阻塞這個操作,直到子線程完成swap操作后才可以進行修改。

    可以參考使用Redis特有內存模型前后的情況對比:

    VM off: 300k keys, 4096 bytes values: 1.3G used
    VM on: 300k keys, 4096 bytes values: 73M used
    VM off: 1 million keys, 256 bytes values: 430.12M used
    VM on: 1 million keys, 256 bytes values: 160.09M used
    VM on: 1 million keys, values as large as you want, still: 160.09M used 

    當從Redis中讀取數據的時候,如果讀取的key對應的value不在內存中,那么Redis就需要從swap文件中加載相應數據,然后再返回給請求方。這里就存在一個I/O線程池的問題。在默認的情況下,Redis會出現阻塞,即完成所有的swap文件加載后才會相應。這種策略在客戶端的數量較小,進行批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中,這顯然是無法滿足大并發的情況的。所以Redis運行我們設置I/O線程池的大小,對需要從swap文件中加載相應數據的讀取請求進行并發操作,減少阻塞的時間。

    redis、memcache、mongoDB 對比
    從以下幾個維度,對redis、memcache、mongoDB 做了對比,歡迎拍磚

    1、性能
    都比較高,性能對我們來說應該都不是瓶頸
    總體來講,TPS方面redis和memcache差不多,要大于mongodb


    2、操作的便利性
    memcache數據結構單一
    redis豐富一些,數據操作方面,redis更好一些,較少的網絡IO次數
    mongodb支持豐富的數據表達,索引,最類似關系型數據庫,支持的查詢語言非常豐富


    3、內存空間的大小和數據量的大小
    redis在2.0版本后增加了自己的VM特性,突破物理內存的限制;可以對key value設置過期時間(類似memcache)
    memcache可以修改最大可用內存,采用LRU算法
    mongoDB適合大數據量的存儲,依賴操作系統VM做內存管理,吃內存也比較厲害,服務不要和別的服務在一起

    4、可用性(單點問題)

    對于單點問題,
    redis,依賴客戶端來實現分布式讀寫;主從復制時,每次從節點重新連接主節點都要依賴整個快照,無增量復制,因性能和效率問題,
    所以單點問題比較復雜;不支持自動sharding,需要依賴程序設定一致hash 機制。
    一種替代方案是,不用redis本身的復制機制,采用自己做主動復制(多份存儲),或者改成增量復制的方式(需要自己實現),一致性問題和性能的權衡

    Memcache本身沒有數據冗余機制,也沒必要;對于故障預防,采用依賴成熟的hash或者環狀的算法,解決單點故障引起的抖動問題。

    mongoDB支持master-slave,replicaset(內部采用paxos選舉算法,自動故障恢復),auto sharding機制,對客戶端屏蔽了故障轉移和切分機制。


    5、可靠性(持久化)

    對于數據持久化和數據恢復,

    redis支持(快照、AOF):依賴快照進行持久化,aof增強了可靠性的同時,對性能有所影響

    memcache不支持,通常用在做緩存,提升性能;

    MongoDB從1.8版本開始采用binlog方式支持持久化的可靠性


    6、數據一致性(事務支持)

    Memcache 在并發場景下,用cas保證一致性

    redis事務支持比較弱,只能保證事務中的每個操作連續執行

    mongoDB不支持事務


    7、數據分析

    mongoDB內置了數據分析的功能(mapreduce),其他不支持


    8、應用場景
    redis:數據量較小的更性能操作和運算上

    memcache:用于在動態系統中減少數據庫負載,提升性能;做緩存,提高性能(適合讀多寫少,對于數據量比較大,可以采用sharding)

    MongoDB:主要解決海量數據的訪問效率問題

    posted on 2013-09-06 11:12 paulwong 閱讀(17845) 評論(0)  編輯  收藏 所屬分類: REDISMONGODB

    主站蜘蛛池模板: 国产AV无码专区亚洲精品| 337p日本欧洲亚洲大胆艺术| a在线观看免费视频| 亚洲资源在线视频| 日韩a在线观看免费观看| 久久久久国色AV免费观看| 亚洲欧洲国产经精品香蕉网| 国产成人青青热久免费精品| 华人在线精品免费观看| 四虎亚洲精品高清在线观看| 亚洲男女内射在线播放| 2021国产精品成人免费视频| 羞羞视频网站免费入口| 久久精品国产亚洲AV嫖农村妇女| 在线免费观看韩国a视频| 日本高清高色视频免费| 国产精品亚洲а∨天堂2021| 久久久久久亚洲Av无码精品专口| 国产成人免费网站在线观看| 91香蕉国产线在线观看免费 | 亚洲最大中文字幕无码网站| 亚洲欧洲中文日韩久久AV乱码| h视频在线观看免费完整版| 一级毛片免费不卡| 亚洲综合精品第一页| 亚洲国产精品lv| 亚洲精品tv久久久久| 国产精品成人免费一区二区| 鲁丝片一区二区三区免费| 另类专区另类专区亚洲| 2020久久精品亚洲热综合一本| 亚洲精品乱码久久久久久按摩| 国产成人在线免费观看| 久久久久国产精品免费免费搜索 | 无遮挡呻吟娇喘视频免费播放| 亚洲视频在线免费看| 亚洲国产精品无码AAA片| 亚洲国产精品13p| 免费无码又爽又刺激高潮的视频| 精品香蕉在线观看免费| 嫩草影院在线播放www免费观看 |