Memchached 還是 Redis?

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

在設計任何緩存系統時，我們考慮如下幾點：

• 讀/寫速度
• 內存使用情況
• 磁盤 I/O 轉儲.
• 伸縮性.

我寫這篇教程是考慮到你已經知道了這些緩存的基礎知識。

[[235494]]

Redis & Memchached 之間的相似之處:

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

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

為什么選 Memcached?

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

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

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

Memcached 非常適合處理高流量的網站。它可以一次性讀取大量的信息，并在優秀的反應時間內返回。Redis不但能處理高流量的讀，還能處理繁重的寫入。

為什么選 Redis?

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

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

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

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

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

結論

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

Redis可能會非常有用的一些示例應用程序：

電子商務應用：大多數的電子商務應用量級比較重，Redis可以提升你的頁面加載速度。你可以存儲所有的配置文件到Redis，從內存中讀取這些配置信息速度會非常快速。你也可以在Redis中存儲完整的頁面緩存，因為它的鍵值容量很大。你也可以存儲會話信息到Redis。

物聯網應用：在物聯網應用中，物聯網設備非常頻繁的發送數據到服務器，比如每秒鐘數千條。在把它們存儲到任何持久性存儲器之前，你可以先把這些高容量的原始數據推送到Redis。

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

***一件事：不管你選擇什么，緩存系統都不是數據庫。你不能光靠緩存，系統同時需要緩存和數據庫。

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