Redis與memcached區別

Redis與memcached區別

 

 

參考：http://blog.csdn.net/tonysz126/article/details/8280696

http://blog.csdn.net/colorant/article/details/21089057

https://www.zhihu.com/question/21419897

1.   爲何須要緩存

少許的數據存儲，高速讀寫訪問。此類產品經過數據所有in-memory的方式保證高速訪問，同時提供數據落地功能

 

2.   Redis與Memcached的區別

 

2.1.          數據類型存儲

         Memcached只支持簡單的K/V數據類型

         Redis不只僅支持簡答的K/V類型數據，同時還提供了List,Set,SortedSet,Hash等數據結構的存儲

 

2.2.          數據的備份

         Redis能夠以master-slave的方式配置服務器，Slave節點對數據進行replica備份，Slave節點也能夠充當Read only的節點分擔數據讀取的工做

 

2.3.          數據的持久化

         memcached不保證存儲的數據的有效性，Slab內部基於LRU也會自動淘汰舊數據。

客戶端不能假設數據在服務器端的當前狀態，這應該說是Memcached的Feature設定，用戶沒必要太多關心或者本身管理數據的淘汰更新工做。Memcached也不作數據的持久化工做，可是有許多基於memcached協議的項目實現了數據的持久化，例如memcacheDB使用BerkeleyDB進行數據存儲，但本質上它已經不是一個Cache Server，而只是一個兼容Memcached的協議key-valueData Store了。

 

         Redis支持數據的持久化，能夠將內存中的數據保存在磁盤中，重啓時能夠再次加載使用。Redis內建支持兩種持久化方案，snapshot快照和AOF 增量Log方式。快照顧名思義就是隔一段時間將完整的數據Dump下來存儲在文件中。AOF增量Log則是記錄對數據的修改操做（實際上記錄的就是每一個對數據產生修改的命令自己），兩種方案能夠並存，也各有優缺點，具體參見 http://redis.io/topics/persistence。

         Redis並非全部的數據都一直存儲在內存中，這是和Memcached相比最大的區別。Redis只會緩存全部的key信息，若是Redis發現內存的使用量超過一個閥值後，將進行swap操做，計算出哪些key須要交換到磁盤中。而後再將這些key對應的value持久化到磁盤，同時在內存中清除這些數據。

         Redis將內存中的數據swap到磁盤中的時候，提供服務的主線程和進行swap操做的子線程會共享這部份內存，因此若是更新須要swap的數據，Redis將阻塞這個操做，直到子線程完成swap操做後才能夠進行修改。

 

2.4.          數據的一致性（事務）

         Memcached提供了cas命令，能夠保證多個併發訪問操做同一份數據的一致性問題。

除了increment/decrement這樣的原子操做命令，不存在對事務的支持

 

         Redis沒有提供cas 命令，並不能保證這點。不過Redis提供了事務的功能，能夠保證一串 命令的原子性，中間不會被任何操做打斷。

         Redis經過Multi / Watch /Exec等命令能夠支持事務的概念，原子性的執行一批命令。在2.6之後的版本中因爲添加了對Script腳本的支持，而腳本固有的是以transaction事務的方式執行的，而且更加易於使用

 

2.5.          網絡IO模型

          Memcached是多線程，非阻塞IO複用的網絡模型，分爲監聽主線程和worker子線程，監聽線程監聽網絡鏈接，接受請求後，將鏈接描述字pipe 傳遞給worker線程，進行讀寫IO, 網絡層使用libevent封裝的事件庫，多線程模型能夠發揮多核做用，可是引入了cache coherency和鎖的問題，好比，Memcached最經常使用的stats 命令，實際Memcached全部操做都要對這個全局變量加鎖，進行計數等工做，帶來了性能損耗。

          Redis使用單線程的IO複用模型，本身封裝了一個簡單的AeEvent事件處理框架，主要實現了epoll、kqueue和select，對於單純只有IO操做來講，單線程能夠將速度優點發揮到最大，可是Redis也提供了一些簡單的計算功能，好比排序、聚合等，對於這些操做，單線程模型實際會嚴重影響總體吞吐量，CPU計算過程當中，整個IO調度都是被阻塞住的。

2.6.          內存管理

          Memcached使用預分配的內存池的方式，使用slab和大小不一樣的chunk來管理內存，Item根據大小選擇合適的chunk存儲，內存池的方式能夠省去申請/釋放內存的開銷，而且能減少內存碎片產生，但這種方式也會帶來必定程度上的空間浪費，而且在內存仍然有很大空間時，新的數據也可能會被剔除，緣由能夠參考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/

Redis使用現場申請內存的方式來存儲數據，而且不多使用free-list等方式來優化內存分配，會在必定程度上存在內存碎片，Redis跟據存儲命令參數，會把帶過時時間的數據單獨存放在一塊兒，並把它們稱爲臨時數據，非臨時數據是永遠不會被剔除的，即使物理內存不夠致使swap也不會剔除任何非臨時數據(但會嘗試剔除部分臨時數據)，這點上Redis更適合做爲存儲而不是cache

 

2.7.          集羣

Memcached自己並不支持分佈式，所以只能在客戶端經過像一致性哈希這樣的分佈式算法來實現Memcached的分佈式存儲。下圖給出了Memcached的分佈式存儲實現架構。當客戶端向Memcached集羣發送數據以前，首先會經過內置的分佈式算法計算出該條數據的目標節點，而後數據會直接發送到該節點上存儲。但客戶端查詢數據時，一樣要計算出查詢數據所在的節點，而後直接向該節點發送查詢請求以獲取數據。

 

Redis3.0以前

客戶端Redis Sharding技術其主要思想是採用一致性哈希算法(consistent hashing)，將key和節點name同時hashing。採用一致性哈希而不是採用簡單相似哈希求模映射的主要緣由是當增長或減小節點時，不會產生因爲從新匹配形成的rehashing。一致性哈希隻影響相鄰節點key分配，影響量小。

 

Redis3.0

Redis Cluster中，Sharding採用slot(槽)的概念，一共分紅16384個槽，這有點兒類pre sharding思路。對於每一個進入Redis的鍵值對，根據key進行散列，分配到這16384個slot中的某一箇中。使用的hash算法也比較簡單，就是CRC16後16384取模。

http://doc.redisfans.com/topic/cluster-tutorial.html

3.   總結

1.Redis使用最佳方式是所有數據in-memory。

2.Redis更多場景是做爲Memcached的替代者來使用。

3.當須要除key/value以外的更多數據類型支持時，使用Redis更合適。

4.當存儲的數據不能被剔除時，使用Redis更合適。