好好耕耘redis和memcached的區別

傑克.陳發表於2018-07-17
Redis
原文:好好耕耘 redis和memcached的區別

觀點一：

1、Redis和Memcache都是將資料存放在記憶體中，都是記憶體資料庫。不過memcache還可用於快取其他東西，例如圖片、視訊等等；

2、Redis不僅僅支援簡單的k/v型別的資料，同時還提供list，set，hash等資料結構的儲存；

3、虛擬記憶體–Redis當實體記憶體用完時，可以將一些很久沒用到的value 交換到磁碟；

4、過期策略–memcache在set時就指定，例如set key1 0 0 8,即永不過期。Redis可以通過例如expire 設定，例如expire name 10；

5、分散式–設定memcache叢集，利用magent做一主多從;redis可以做一主多從。都可以一主一從；

6、儲存資料安全–memcache掛掉後，資料沒了；redis可以定期儲存到磁碟（持久化）；

7、災難恢復–memcache掛掉後，資料不可恢復; redis資料丟失後可以通過aof恢復；

8、Redis支援資料的備份，即master-slave模式的資料備份；

9、mongodb和memcached不是一個範疇內的東西。mongodb是文件型的非關係型資料庫，其優勢在於查詢功能比較強大，能儲存海量資料。mongodb和memcached不存在誰替換誰的問題。

觀點二：

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:主要解決海量資料的訪問效率問題   


相關文章