緩存技術: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、應用場景不一樣:Redis出來作爲NoSQL數據庫使用外,還能用做消息隊列、數據堆棧和數據緩存等;Memcached適合於緩存SQL語句、數據集、用戶臨時性數據、延遲查詢數據和session等。


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、集羣管理的不同

  Memcached只能採用客戶端實現分佈式存儲Redis更偏向於在服務器端構建分佈式存儲。最新版本的Redis已經支持了分佈式存儲功能。Redis Cluster是一個實現了分佈式且允許單點故障的Redis高級版本,它沒有中心節點,具有線性可伸縮的功能。Redis Cluster的分佈式存儲架構中,節點與節點之間通過二進制協議進行通信,節點與客戶端之間通過ascii協議進行通信。在數據的放置策略上,Redis Cluster將整個key的數值域分成4096個哈希槽,每個節點上可以存儲一個或多個哈希槽,也就是說當前Redis Cluster支持的最大節點數就是4096。Redis Cluster使用的分佈式算法也很簡單:crc16( key ) % HASH_SLOTS_NUMBER。

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

綜合結論

應該說Memcached和Redis都能很好的滿足解決我們的問題,它們性能都很高,總的來說,可以把Redis理解爲是對Memcached的拓展,是更加重量級的實現,提供了更多更強大的功能。具體來說:

1.性能上: 
性能上都很出色,具體到細節,由於Redis只使用單核,而Memcached可以使用多核,所以平均每一個核上Redis在存儲小數據時比 
Memcached性能更高。而在100k以上的數據中,Memcached性能要高於Redis,雖然Redis最近也在存儲大數據的性能上進行優化,但是比起 Memcached,還是稍有遜色。

2.內存空間和數據量大小: 
MemCached可以修改最大內存,採用LRU算法。Redis增加了VM的特性,突破了物理內存的限制。

3.操作便利上: 
MemCached數據結構單一,僅用來緩存數據,而Redis支持更加豐富的數據類型,也可以在服務器端直接對數據進行豐富的操作,這樣可以減少網絡IO次數和數據體積。

4.可靠性上: 
MemCached不支持數據持久化,斷電或重啓後數據消失,但其穩定性是有保證的。Redis支持數據持久化和數據恢復,允許單點故障,但是同時也會付出性能的代價。

5.應用場景: 
Memcached:動態系統中減輕數據庫負載,提升性能;做緩存,適合多讀少寫,大數據量的情況(如人人網大量查詢用戶信息、好友信息、文章信息等)。 
Redis:適用於對讀寫效率要求都很高,數據處理業務複雜和對安全性要求較高的系統(如新浪微博的計數和微博發佈部分系統,對數據安全性、讀寫要求都很高)。


文章轉自:

鏈接:https://www.zhihu.com/question/19645807/answer/145409185

發佈了31 篇原創文章 · 獲贊 13 · 訪問量 4萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章