Memchached 還是 Redis?

該用哪一個(gè)？當(dāng)我們討論改進(jìn)性能的時(shí)候，這是每次技術(shù)討論中最常見(jiàn)的一個(gè)問(wèn)題。每當(dāng)性能需要改善時(shí)，采用緩存常常是邁出的***步。與此同時(shí)，選擇Memcached 或者 Redis 通常是***個(gè)需要考慮的地方。哪個(gè)能給我們提供更佳的性能？它們的優(yōu)點(diǎn)和缺點(diǎn)又是什么？

在設(shè)計(jì)任何緩存系統(tǒng)時(shí)，我們考慮如下幾點(diǎn)：

• 讀/寫(xiě)速度
• 內(nèi)存使用情況
• 磁盤(pán) I/O 轉(zhuǎn)儲(chǔ).
• 伸縮性.

我寫(xiě)這篇教程是考慮到你已經(jīng)知道了這些緩存的基礎(chǔ)知識(shí)。

[[235494]]

Redis & Memchached 之間的相似之處:

Memcached/Redis 兩者都提供基于內(nèi)存的、鍵-值數(shù)據(jù)存儲(chǔ)，盡管Redis更準(zhǔn)確的說(shuō)是結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)。Redis是內(nèi)存中的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)器，用于數(shù)據(jù)庫(kù)、緩存、消息代理。兩者（Memcached/Redis）都屬于數(shù)據(jù)管理方案中的NoSQL家族，都是基于鍵-值存儲(chǔ)的。它們都在內(nèi)存中保存數(shù)據(jù)，當(dāng)然使它們作為緩存層特別有用。

截至今日，Memcached提供的每項(xiàng)主要功能及其優(yōu)勢(shì)，都是Redis功能和特性的子集。任何用例中可能使用Memcached的地方都可以對(duì)等的使用Redis。它們都是閃電般快速的高速緩存。Memcached提供的只是Redis擁有功能的冰山一角。Memcached是一個(gè)基于易失性內(nèi)存的鍵-值存儲(chǔ)器。Redis一樣可以做到（跟Memcached做得一樣好），但是它還是一個(gè)結(jié)構(gòu)化數(shù)據(jù)服務(wù)器。

為什么選 Memcached?

當(dāng)緩存相對(duì)較小和使用靜態(tài)的數(shù)據(jù)時(shí)候，比如HTML代碼片段，Memcached可能更為可取。Memcached內(nèi)部的內(nèi)存管理在最簡(jiǎn)單的用例中更為有效，因?yàn)樗脑獢?shù)據(jù)消耗相對(duì)更少的內(nèi)存資源。

當(dāng)數(shù)據(jù)尺寸是動(dòng)態(tài)的時(shí)候，Memcached的內(nèi)存管理效率下降的很快，此時(shí)Memcached的內(nèi)存會(huì)變成碎片。而且，大的數(shù)據(jù)集經(jīng)常牽扯到數(shù)據(jù)序列化，總是需要更多的空間來(lái)存儲(chǔ)。如果你使用Memcached，數(shù)據(jù)會(huì)隨著重啟動(dòng)而丟失，重建緩存是個(gè)代價(jià)高昂的過(guò)程。

Memcached比Redis更具優(yōu)勢(shì)的另一個(gè)場(chǎng)景在伸縮性。因?yàn)镸emcached是多線程的，所以你可以通過(guò)給它更多計(jì)算資源讓它輕松擴(kuò)展。Redis是單線程的，可以通過(guò)集群無(wú)損水平擴(kuò)展。集群是一個(gè)有效的擴(kuò)展方案，但是相對(duì)來(lái)說(shuō)配置、操作復(fù)雜。Memcached不支持復(fù)制功能（數(shù)據(jù)從一臺(tái)機(jī)器自動(dòng)復(fù)制到另外一臺(tái)）。

Memcached 非常適合處理高流量的網(wǎng)站。它可以一次性讀取大量的信息，并在優(yōu)秀的反應(yīng)時(shí)間內(nèi)返回。Redis不但能處理高流量的讀，還能處理繁重的寫(xiě)入。

為什么選 Redis?

Redis有五種主要的數(shù)據(jù)結(jié)構(gòu)可以選擇。通過(guò)對(duì)緩存數(shù)據(jù)智能化的緩存和處理，它為應(yīng)用程序開(kāi)發(fā)人員打開(kāi)了存在各種可能的新世界。由于其數(shù)據(jù)結(jié)構(gòu)（使用多種格式存儲(chǔ)數(shù)據(jù)：列表、數(shù)組、集合、有序集合）特性，Redis作為緩存系統(tǒng)提供了更多的能力和總體上更好的效率。緩存使用一種稱為“數(shù)據(jù)回收”的機(jī)制，通過(guò)從內(nèi)存中刪除舊數(shù)據(jù)為新數(shù)據(jù)騰出空間。Memcached的數(shù)據(jù)回收機(jī)制使用了LRU（Least Recently Used-最近最少使用）算法，但回收與新數(shù)據(jù)近似大小的數(shù)據(jù)時(shí)有點(diǎn)隨意性。

Redis允許對(duì)回收進(jìn)行細(xì)粒度的控制，讓你選擇六種不同的回收策略。Redis同時(shí)支持惰性（被動(dòng)）和主動(dòng)回收，只有在需要更多空間或主動(dòng)激活時(shí)才回收數(shù)據(jù)。另一方面，Memcached只支持惰性回收。

以下是redis提供的一些功能，可以用于“真實(shí)”數(shù)據(jù)存儲(chǔ)，而不僅僅是緩存。

• 強(qiáng)大的數(shù)據(jù)類型和可利用它們的強(qiáng)大命令支持。哈希、有序集合、列表等。
• 默認(rèn)的磁盤(pán)持久化支持
• 使用樂(lè)觀鎖的事務(wù)支持 (WATCH/MULTI/EXEC)
• 發(fā)布/訂閱功能，速度極快
• 高達(dá)512MB的鍵值尺寸上限（Memcached每個(gè)鍵值限于1MB大小）
• Lua 腳本支持 (2.6及以上版本)
• 內(nèi)置集群支持 (3.0及以上版本)
• 一切都極快

強(qiáng)大的數(shù)據(jù)類型尤為重要。它們?cè)试SRedis提供一個(gè)出色的共享隊(duì)列（list），一個(gè)很棒的消息傳遞解決方案（pub/sub），一個(gè)存儲(chǔ)會(huì)話信息（hashes）的好地方，還有一個(gè)引人注目的高分值追蹤區(qū)域（sorted sets）。它們僅僅是簡(jiǎn)單探討就能得到的使用樣例。

結(jié)論

Redis與Memcached相比，性能和內(nèi)存使用情況相當(dāng)相似。除非你已經(jīng)在Memcached上投入了大筆資金，否則向前推進(jìn)使用Redis是顯而易見(jiàn)的解決方案。不僅Redis是更好的選擇，它還支持全新類型的用例和使用模式。

Redis可能會(huì)非常有用的一些示例應(yīng)用程序：

電子商務(wù)應(yīng)用：大多數(shù)的電子商務(wù)應(yīng)用量級(jí)比較重，Redis可以提升你的頁(yè)面加載速度。你可以存儲(chǔ)所有的配置文件到Redis，從內(nèi)存中讀取這些配置信息速度會(huì)非常快速。你也可以在Redis中存儲(chǔ)完整的頁(yè)面緩存，因?yàn)樗逆I值容量很大。你也可以存儲(chǔ)會(huì)話信息到Redis。

物聯(lián)網(wǎng)應(yīng)用：在物聯(lián)網(wǎng)應(yīng)用中，物聯(lián)網(wǎng)設(shè)備非常頻繁的發(fā)送數(shù)據(jù)到服務(wù)器，比如每秒鐘數(shù)千條。在把它們存儲(chǔ)到任何持久性存儲(chǔ)器之前，你可以先把這些高容量的原始數(shù)據(jù)推送到Redis。

實(shí)時(shí)分析：可以在Memcached上實(shí)現(xiàn)一個(gè)實(shí)時(shí)的分析引擎，以數(shù)據(jù)庫(kù)為后盾。但是Redis非常擅長(zhǎng)統(tǒng)計(jì)列表和一系列事物。在所有的Redis功能特性中，它對(duì)鍵值進(jìn)行排序的能力超過(guò)了Memcached，還有計(jì)算一組頁(yè)面的點(diǎn)擊次數(shù)等數(shù)據(jù)，然后將這些數(shù)字匯總進(jìn)入分析系統(tǒng)。這些數(shù)據(jù)可通過(guò)工作人員輸入到更大的分析引擎，在這些應(yīng)用場(chǎng)合選擇Redis是正確的決定之一。

***一件事：不管你選擇什么，緩存系統(tǒng)都不是數(shù)據(jù)庫(kù)。你不能光靠緩存，系統(tǒng)同時(shí)需要緩存和數(shù)據(jù)庫(kù)。

這段是我的評(píng)論。總體上看，Redis功能特性遠(yuǎn)優(yōu)于Memcached，完全是下一代產(chǎn)品。選擇哪個(gè)使用似乎答案很明確。但是必須指出，Redis的單線程設(shè)計(jì)，同時(shí)也帶來(lái)了一些重要的隱患。Redis有數(shù)據(jù)持久化功能，這個(gè)功能與Redis的單線程特性結(jié)合，就成了Redis故障的高發(fā)區(qū)域。默認(rèn)的RDB持久化會(huì)阻塞線程，使得Redis對(duì)正常請(qǐng)求無(wú)法響應(yīng)，在高流量網(wǎng)站上容易出現(xiàn)大量請(qǐng)求錯(cuò)誤。這在系統(tǒng)中稱為“涌現(xiàn)”，當(dāng)然這是壞的一個(gè)。當(dāng)然后來(lái)Redis也發(fā)展出了AOF持久化方式（默認(rèn)沒(méi)有打開(kāi)，要手工開(kāi)啟），一定程度上減緩了Redis的持久化問(wèn)題。Redis會(huì)fork一個(gè)子進(jìn)程來(lái)單獨(dú)處理持久化。可是fork功能并非無(wú)代價(jià)，它一樣有消耗內(nèi)存資源，影響主程序響應(yīng)請(qǐng)求的問(wèn)題。阻塞是Redis應(yīng)用的噩夢(mèng)，跟Node.js一樣。所以出現(xiàn)故障的時(shí)候，可以多在這個(gè)角度上分析原因，也許能很快的解決。