Redis 和 Memcache 都是基於記憶體的資料儲存系統。Memcached是高效能分散式記憶體快取服務；Redis是一個開源的key-value儲存系統。與Memcached類似，Redis將大部分資料儲存在記憶體中，支援的資料型別包括：字串、雜湊 表、連結串列、等資料型別的相關操作。下面我們來進行來看一下redis和memcached的區別。權威比較

Redis的作者Salvatore Sanfilippo曾經對這兩種基於記憶體的資料儲存系統進行過比較：

1. Redis支援伺服器端的資料操作：Redis相比Memcached來說，擁有更多的資料結構和支援更豐富的資料操作，通常在Memcached裡，你需要將資料拿到客戶端來進行類似的修改再set回去。這大大增加了網路IO的次數和資料體積。在Redis中，這些複雜的操作通常和一般的GET/SET一樣高效。所以，如果需要快取能夠支援更復雜的結構和操作
   ，首選Redis。
2. 記憶體使用效率對比：使用簡單的key-value儲存的話，Memcached的記憶體利用率更高，而如果Redis採用hash結構來做key-value儲存，由於其組合式的壓縮，其記憶體利用率會高於Memcached。
3. 效能對比：由於Redis只使用單核，而Memcached可以使用多核，所以平均每一個核上Redis在儲存小資料時比Memcached效能更高。而在100k以上的資料中，Memcached效能要高於Redis，雖然Redis最近也在儲存大資料的效能上進行優化，但是比起Memcached，還是稍有遜色。

具體為什麼會出現上面的結論，以下為收集到的資料：

1、資料型別支援不同

與Memcached僅支援簡單的key-value結構的資料記錄不同，Redis支援的資料型別要豐富得多。最為常用的資料型別主要由五種：String、Hash、List、Set和Sorted Set。Redis內部使用一個redisObject物件來表示所有的key和value。redisObject最主要的資訊如圖所示：

1）String

常用命令：set/get/decr/incr/mget等；

應用場景：String是最常用的一種資料型別，普通的key/value儲存都可以歸為此類；

實現方式：String在redis內部儲存預設就是一個字串，被redisObject所引用，當遇到incr、decr等操作時會轉成數值型進行計算，此時redisObject的encoding欄位為int。

2）Hash

常用命令：hget/hset/hgetall等

應用場景：我們要儲存一個使用者資訊物件資料，其中包括使用者ID、使用者姓名、年齡和生日，通過使用者ID我們希望獲取該使用者的姓名或者年齡或者生日；

3）List

常用命令：lpush/rpush/lpop/rpop/lrange等；

應用場景：Redis list的應用場景非常多，也是Redis最重要的資料結構之一，比如twitter的關注列表，粉絲列表等都可以用Redis的list結構來實現；

實現方式：Redis list的實現為一個雙向連結串列，即可以支援反向查詢和遍歷，更方便操作，不過帶來了部分額外的記憶體開銷，Redis內部的很多實現，包括髮送緩衝佇列等也都是用的這個資料結構。

4）Set

常用命令：sadd/spop/smembers/sunion等；

應用場景：Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要儲存一個列表資料，又不希望出現重複資料時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的；

實現方式：set 的內部實現是一個 value永遠為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。

5）Sorted Set

常用命令：zadd/zrange/zrem/zcard等；

應用場景：Redis sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted set可以通過使用者額外提供一個優先順序(score)的引數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重複的集合列表，那麼可以選擇sorted set資料結構，比如twitter 的public timeline可以以發表時間作為score來儲存，這樣獲取時就是自動按時間排好序的。

實現方式：Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證資料的儲存和有序，HashMap裡放的是成員到score的對映，而跳躍表裡存放的是所有的成員，排序依據是HashMap裡存的score,使用跳躍表的結構可以獲得比較高的查詢效率，並且在實現上比較簡單。

2、記憶體管理機制不同

 在Redis中，並不是所有的資料都一直儲存在記憶體中的。這是和Memcached相比一個最大的區別。當實體記憶體用完時，Redis可以將一些很久沒用到的value交換到磁碟。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中讀取資料的時候，如果讀取的key對應的value不在記憶體中，那麼Redis就需要從swap檔案中載入相應資料，然後再返回給請求方。 這裡就存在一個I/O執行緒池的問題。在預設的情況下，Redis會出現阻塞，即完成所有的swap檔案載入後才會相應。這種策略在客戶端的數量較小，進行批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程式中，這顯然是無法滿足大併發的情況的。所以Redis執行我們設定I/O執行緒池的大小，對需要從swap檔案中載入相應資料的讀取請求進行併發操作，減少阻塞的時間。

3、資料持久化支援

  Redis雖然是基於記憶體的儲存系統，但是它本身是支援記憶體資料的持久化的，而且提供兩種主要的持久化策略：RDB快照和AOF日誌。而memcached是不支援資料持久化操作的。

1）RDB快照

 Redis支援將當前資料的快照存成一個數據檔案的持久化機制，即RDB快照。但是一個持續寫入的資料庫如何生成快照呢？Redis藉助了fork命令的copy on write機制。在生成快照時，將當前程序fork出一個子程序，然後在子程序中迴圈所有的資料，將資料寫成為RDB檔案。我們可以通過Redis的save指令來配置RDB快照生成的時機，比如配置10分鐘就生成快照，也可以配置有1000次寫入就生成快照，也可以多個規則一起實施。這些規則的定義就在Redis的配置檔案中，你也可以通過Redis的CONFIG SET命令在Redis執行時設定規則，不需要重啟Redis。

 Redis的RDB檔案不會壞掉，因為其寫操作是在一個新程序中進行的，當生成一個新的RDB檔案時，Redis生成的子程序會先將資料寫到一個臨時檔案中，然後通過原子性rename系統呼叫將臨時檔案重新命名為RDB檔案，這樣在任何時候出現故障，Redis的RDB檔案都總是可用的。同時，Redis的RDB檔案也是Redis主從同步內部實現中的一環。RDB有他的不足，就是一旦資料庫出現問題，那麼我們的RDB檔案中儲存的資料並不是全新的，從上次RDB檔案生成到Redis停機這段時間的資料全部丟掉了。在某些業務下，這是可以忍受的。

2）AOF日誌

 AOF日誌的全稱是append only file，它是一個追加寫入的日誌檔案。與一般資料庫的binlog不同的是，AOF檔案是可識別的純文字，它的內容就是一個個的Redis標準命令。只有那些會導致資料發生修改的命令才會追加到AOF檔案。每一條修改資料的命令都生成一條日誌，AOF檔案會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite。其功能就是重新生成一份AOF檔案，新的AOF檔案中一條記錄的操作只會有一次，而不像一份老檔案那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似，也是fork一個程序，直接遍歷資料，寫入新的AOF臨時檔案。在寫入新檔案的過程中，所有的寫操作日誌還是會寫到原來老的AOF檔案中，同時還會記錄在記憶體緩衝區中。當重完操作完成後，會將所有緩衝區中的日誌一次性寫入到臨時檔案中。然後呼叫原子性的rename命令用新的AOF檔案取代老的AOF檔案。

 AOF是一個寫檔案操作，其目的是將操作日誌寫到磁碟上，所以它也同樣會遇到我們上面說的寫操作的流程。在Redis中對AOF呼叫write寫入後，通過appendfsync選項來控制呼叫fsync將其寫到磁碟上的時間，下面appendfsync的三個設定項，安全強度逐漸變強。

• appendfsync no 當設定appendfsync為no的時候，Redis不會主動呼叫fsync去將AOF日誌內容同步到磁碟，所以這一切就完全依賴於作業系統的除錯了。對大多數Linux作業系統，是每30秒進行一次fsync，將緩衝區中的資料寫到磁碟上。
• appendfsync everysec 當設定appendfsync為everysec的時候，Redis會預設每隔一秒進行一次fsync呼叫，將緩衝區中的資料寫到磁碟。但是當這一次的fsync呼叫時長超過1秒時。Redis會採取延遲fsync的策略，再等一秒鐘。也就是在兩秒後再進行fsync，這一次的fsync就不管會執行多長時間都會進行。這時候由於在fsync時檔案描述符會被阻塞，所以當前的寫操作就會阻塞。所以結論就是，在絕大多數情況下，Redis會每隔一秒進行一次fsync。在最壞的情況下，兩秒鐘會進行一次fsync操作。這一操作在大多數資料庫系統中被稱為group commit，就是組合多次寫操作的資料，一次性將日誌寫到磁碟。
• appednfsync always 當設定appendfsync為always時，每一次寫操作都會呼叫一次fsync，這時資料是最安全的，當然，由於每次都會執行fsync，所以其效能也會受到影響。

  對於一般性的業務需求，建議使用RDB的方式進行持久化，原因是RDB的開銷並相比AOF日誌要低很多，對於那些無法忍資料丟失的應用，建議使用AOF日誌。

4、叢集管理的不同

  為了保證單點故障下的資料可用性，Redis Cluster引入了Master節點和Slave節點。在Redis Cluster中，每個Master節點都會有對應的兩個用於冗餘的Slave節點。這樣在整個叢集中，任意兩個節點的宕機都不會導致資料的不可用。當Master節點退出後，叢集會自動選擇一個Slave節點成為新的Master節點。