Memchached 還是 Redis?

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

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

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

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

[[235494]]

Redis & Memchached 之間的相似之處:

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

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

為什么選 Memcached?

當緩存相對較小和使用靜態(tài)的數(shù)據(jù)時候，比如HTML代碼片段，Memcached可能更為可取。Memcached內(nèi)部的內(nèi)存管理在最簡單的用例中更為有效，因為它的元數(shù)據(jù)消耗相對更少的內(nèi)存資源。

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

Memcached比Redis更具優(yōu)勢的另一個場景在伸縮性。因為Memcached是多線程的，所以你可以通過給它更多計算資源讓它輕松擴展。Redis是單線程的，可以通過集群無損水平擴展。集群是一個有效的擴展方案，但是相對來說配置、操作復(fù)雜。Memcached不支持復(fù)制功能（數(shù)據(jù)從一臺機器自動復(fù)制到另外一臺）。

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

為什么選 Redis?

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

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

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

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

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

結(jié)論

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

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

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

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

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

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

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