Memcached vs Redis, 挑選哪一個？

本文由我翻譯自：

https://www.linkedin.com/pulse/memcached-vs-redis-which-one-pick-ranjeet-vimal

作者：Ranjeet Vimal

Memchached 還是 Redis?

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

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

• 讀/寫速度
• 記憶體使用情況
• 磁碟 I/O 轉儲.
• 伸縮性.

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

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一樣。所以出現故障的時候，可以多在這個角度上分析原因，也許能很快的解決。

作者部落格