Memcached和Redis作為兩種Inmemory的key-value數(shù)據(jù)庫，在設(shè)計和思想方面有著很多共通的地方，功能和應(yīng)用方面在很多場合下(作為分布式緩存服務(wù)器使用等)?也很相似，在這里把兩者放在一起做一下對比的介紹

??

基本架構(gòu)和思想

?

首先簡單介紹一下兩者的架構(gòu)和設(shè)計思路

?

Memcached

?

Memcached采用客戶端-服務(wù)器的架構(gòu)，客戶端和服務(wù)器端的通訊使用自定義的協(xié)議標(biāo)準(zhǔn)，只要滿足協(xié)議格式要求，客戶端Library可以用任何語言實現(xiàn)。

?

從用戶的角度來說，服務(wù)器維護了一個鍵-值關(guān)系的數(shù)據(jù)表，服務(wù)器之間相互獨立，互相之間不共享數(shù)據(jù)也不做任何通訊操作?？蛻舳诵枰浪械姆?wù)器，并自行負(fù)責(zé)管理數(shù)據(jù)在各個服務(wù)器間的分配。

?

在服務(wù)器端，內(nèi)部的數(shù)據(jù)存儲，使用基于Slab的內(nèi)存管理方式，有利于減少內(nèi)存碎片和頻繁分配銷毀內(nèi)存所帶來的開銷。各個Slab按需動態(tài)分配一個page的內(nèi)存（和4Kpage的概念不同，這里默認(rèn)page為1M），page內(nèi)部按照不同slab class的尺寸再劃分為內(nèi)存chunk供服務(wù)器存儲KV鍵值對使用

?

Memcached的基本應(yīng)用模型如下圖所示

?

?

?

?

Redis

?

Redis的基本應(yīng)用模式和上圖memcached的基本相似，不難發(fā)現(xiàn)網(wǎng)上到處都是關(guān)于redis是否可以完全替代memcached使用的問題

?

Redis內(nèi)部的數(shù)據(jù)結(jié)構(gòu)最終也會落實到key-Value對應(yīng)的形式，不過從暴露給用戶的數(shù)據(jù)結(jié)構(gòu)來看，要比memcached豐富，除了標(biāo)準(zhǔn)的通常意義的鍵值對，Redis還支持List，Set，?Hashes，Sorted Set等數(shù)據(jù)結(jié)構(gòu)

?

基本命令

?

Memcached的命令或者說通訊協(xié)議非常簡單，Server所支持的命令基本就是對特定key的添加，刪除，替換，原子更新，讀取等，具體包括?Set, Get, Add, Replace, Append, Inc/Dec?等等

?

Memcached的通訊協(xié)議包括文本格式和二進制格式，用于滿足簡單網(wǎng)絡(luò)客戶端工具（如telnet）和對性能要求更高的客戶端的不同需求

?

Redis的命令在KV（String類型）上提供與Memcached類似的基本操作，在其它數(shù)據(jù)結(jié)構(gòu)上也支持基本類似的操作（當(dāng)然還有這些數(shù)據(jù)結(jié)構(gòu)所特有的操作，如Set的union，List的pop等）而支持更多的數(shù)據(jù)結(jié)構(gòu)，在一定程度上也就意味著更加廣泛的應(yīng)用場合

?

除了多種數(shù)據(jù)結(jié)構(gòu)的支持，Redis相比Memcached還提供了許多額外的特性，比如Subscribe/publish命令，以支持發(fā)布/訂閱模式這樣的通知機制等等，這些額外的特性同樣有助于拓展它的應(yīng)用場景

?

Redis的客戶端-服務(wù)器通訊協(xié)議完全采用文本格式（在將來可能的服務(wù)器間通訊會采用二進制格式）

?

?

事務(wù)

?

redis通過Multi / Watch /Exec等命令可以支持事務(wù)的概念，原子性的執(zhí)行一批命令。在2.6以后的版本中由于添加了對Script腳本的支持，而腳本固有的是以transaction事務(wù)的方式執(zhí)行的，并且更加易于使用，所以不排除將來取消Multi等命令接口的可能性

?

Memcached的應(yīng)用模式中，除了increment/decrement這樣的原子操作命令，不存在對事務(wù)的支持

?

數(shù)據(jù)備份，有效性，持久化等

?

memcached不保證存儲的數(shù)據(jù)的有效性，Slab內(nèi)部基于LRU也會自動淘汰舊數(shù)據(jù)，客戶端不能假設(shè)數(shù)據(jù)在服務(wù)器端的當(dāng)前狀態(tài)，這應(yīng)該說是Memcached的Feature設(shè)定，用戶不必太多關(guān)心或者自己管理數(shù)據(jù)的淘汰更新工作，當(dāng)然是否適合你的應(yīng)用，取決于具體的需求，它也可能成為你需要精確自行控制Cache生命周期的一個障礙

?

Memcached也不做數(shù)據(jù)的持久化工作，但是有許多基于memcached協(xié)議的項目實現(xiàn)了數(shù)據(jù)的持久化，例如memcacheDB使用BerkeleyDB進行數(shù)據(jù)存儲，但本質(zhì)上它已經(jīng)不是一個Cache Server，而只是一個兼容Memcached的協(xié)議key-valueData Store了

?

Redis可以以master-slave的方式配置服務(wù)器，Slave節(jié)點對數(shù)據(jù)進行replica備份，Slave節(jié)點也可以充當(dāng)Read only的節(jié)點分擔(dān)數(shù)據(jù)讀取的工作

?

Redis內(nèi)建支持兩種持久化方案，snapshot快照和AOF?增量Log方式?？煺疹櫭剂x就是隔一段時間將完整的數(shù)據(jù)Dump下來存儲在文件中。AOF增量Log則是記錄對數(shù)據(jù)的修改操作（實際上記錄的就是每個對數(shù)據(jù)產(chǎn)生修改的命令本身），兩種方案可以并存，也各有優(yōu)缺點，具體參見http://redis.io/topics/persistence

?

以上Redis的數(shù)據(jù)備份持久化方案等，如果不需要，為了提高性能，也完全可以Disable

?

?

性能

?

性能方面，兩者都有一些自己考慮和實現(xiàn)

?

Memcached

?

memcached自身并不主動定期檢查和標(biāo)記哪些數(shù)據(jù)需要被淘汰，只有當(dāng)再次讀取相關(guān)數(shù)據(jù)時才檢查時間戳，或者當(dāng)內(nèi)存不夠使用需要主動淘汰數(shù)據(jù)時進一步檢查LRU數(shù)據(jù)

?

?

Redis

?

Redis為了減少大量小數(shù)據(jù)CMD操作的網(wǎng)絡(luò)通訊時間開銷 RTT (Round Trip Time)，支持pipeline和script技術(shù)

?

• 所謂的pipeline就是支持在一次通訊中，發(fā)送多個命令給服務(wù)器批量執(zhí)行，帶來的代價是服務(wù)器端需要更多的內(nèi)存來緩存查詢結(jié)果。

• Redis內(nèi)嵌了LUA解析器，可以執(zhí)行lua?腳本，腳本可以通過eval等命令直接執(zhí)行，也可以使用script load等方式上傳到服務(wù)器端的script cache中重復(fù)使用

?

這兩種方式都可以有效地減少網(wǎng)絡(luò)通訊開銷，增加數(shù)據(jù)吞吐率

?

對于KV的操作，Memcached和Redis都支持Multiple的Get和Set命令（Memcached的Multiple Set命令貌似只在二進制的協(xié)議中支持），這同樣有利于性能的提升

?

實際性能方面，網(wǎng)上有很多測試比較，給出的結(jié)果各不相同，這無疑和各種測試的測試用例，測試環(huán)境，和測試時具體使用的客戶端Library實現(xiàn)有關(guān)。但是總體看下來，比較靠譜的結(jié)論是在kv類操作上，兩者的性能接近，Memcached的結(jié)構(gòu)更加簡單，理論上應(yīng)該會略微快一些。

?

?

集群

?

memcached的服務(wù)器端互相完全獨立，客戶端通常通過對鍵值應(yīng)用Hash算法決定數(shù)據(jù)的分區(qū)，為了減少服務(wù)器的增減對Hash結(jié)果的影響，導(dǎo)致大面積的緩存失效，多數(shù)客戶端實現(xiàn)了一致性hash算法

?

Redis計劃在服務(wù)器端內(nèi)建對集群的支持，但是目前代碼還處于alpha階段（貌似已經(jīng)Design了兩三年了？）在此之前，同樣可以認(rèn)為每個Redis服務(wù)器實例相互之間是完全獨立的，需要依靠客戶端處理分區(qū)算法和可用服務(wù)器列表管理的工作。

?

?

Redis官方推薦的用于Sharding的客戶端程序庫是Twitter的開源項目?Twemproxy，?Twemproxy同時支持Memcached和Redis的文本通訊協(xié)議。

?

需要注意的是，Redis的許多命令在集群環(huán)境下是不能正確運行的，例如set的交集，以及跨節(jié)點的事務(wù)操作等等，因為目前的Redis集群設(shè)計，根本目標(biāo)也就是服務(wù)器之間互相匯報一下存活狀態(tài)，以及對數(shù)據(jù)做榮譽備份平衡負(fù)載等而已，本質(zhì)上對數(shù)據(jù)的跨節(jié)點操作并不提供任何額外支持，所以在數(shù)據(jù)服務(wù)的層面上來說，各個服務(wù)器依舊是完全獨立的。

?

這些操作如果一定要實現(xiàn)，當(dāng)然可以通過客戶端代碼來實現(xiàn)（效率有多高且不說），類似的問題memcached集群當(dāng)然也會遇上，但是原本memcached就不支持復(fù)雜的操作和數(shù)據(jù)類型，許多運算邏輯原本就是由客戶端代碼或應(yīng)用程序自己處理的。

?

?

MR類批處理應(yīng)用

?

提供指定范圍的遍歷操作，是支持類似MapReduce這樣的批處理應(yīng)用邏輯的關(guān)鍵之一，但是要在基于hash方式存儲的數(shù)據(jù)結(jié)構(gòu)的基礎(chǔ)上提供這樣的支持并不容易（或者說要實現(xiàn)高效的范圍或遍歷操作并不容易）

?

Redis支持Scan操作用于遍歷數(shù)據(jù)集，這一操作基于其內(nèi)部數(shù)據(jù)結(jié)構(gòu)及實現(xiàn)的限制，可以保證在Scan開始時的所有數(shù)據(jù)都能被獲取到，但是不能保證不返回重復(fù)的數(shù)據(jù)，這需要由客戶端來檢查，或者客戶端對此無所謂。Scan操作還支持Match條件用來過濾鍵值，雖然存在一定的局限性，例如match條件的比較是在獲取數(shù)據(jù)之后再執(zhí)行的，效率是一個問題，更明顯的問題是不能保證每次scan的iterate過程都能返回同樣數(shù)量的有效數(shù)據(jù)。

?

對于范圍操作，Redis的Ordered Set支持在插入時指定數(shù)據(jù)的分?jǐn)?shù)（Score）用于排序，而后支持在指定Score范圍內(nèi)的各種操作，雖然由于不支持基于字符串的或自定義的基準(zhǔn)的Range操作，這樣的范圍操作應(yīng)用起來有很大的局限性（或者說需要滿足特定的應(yīng)用模式），但是還是比沒有好了

?

Memcached核心協(xié)議本身不支持任何范圍類的操作，也沒有對遍歷操作的支持，甚至不存在官方合法的列舉所有Key的操作，這當(dāng)然很大程度上源于其設(shè)計思想和精簡的架構(gòu)

?

不過還是有一些兼容memcached協(xié)議的服務(wù)器實現(xiàn)了范圍類操作，具體格式可以參考?https://code.google.com/p/memcached/wiki/RangeOps?所建議的標(biāo)準(zhǔn)

?

此外Redis的Hashes數(shù)據(jù)結(jié)構(gòu)，在一定程度上可以滿足獲取特定子集數(shù)據(jù)的應(yīng)用邏輯需求。

?

綜上來說，如果要實現(xiàn)類似HBase支持的scan操作，不論是Redis還是memcached都無法做到，但是對于Redis來說，能否用于批處理類應(yīng)用，不能一概而論，取決于具體的數(shù)據(jù)的格式邏輯和使用方式。通過適當(dāng)?shù)恼{(diào)整應(yīng)用程序使用數(shù)據(jù)的方式，還是有可能在一定程度上實現(xiàn)對MR類批處理，或范圍查詢類應(yīng)用邏輯的支持的。而對于鍵值分布在一個較大的連續(xù)空間，數(shù)量不確定，同時又無法很好的映射為數(shù)值進而使用ordered set來處理的這樣一些數(shù)據(jù)結(jié)構(gòu)，應(yīng)該還是很難高效的分區(qū)遍歷的

總結(jié)

以上是生活随笔為你收集整理的Memcached和Redis的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。