要Memcached還是要Redis?在構建一款現代且由數據庫驅動的Web應用程序並希望使其擁有更爲出色的性能表現時，這個問題總會時不時出現、並給每一位開發人員帶來困擾。在考慮對應用程序的性能表現進行提升時，緩存機制往往是解決問題的重要起點，而Memcached與Redis則經常被作爲初步方案來加以比較。
這兩套聲名顯赫的緩存引擎擁有着諸多相似之處，但它們同樣也具備大量顯著差異。作爲二者當中更年輕也更加靈活的方案，Redis被大部分技術人員視爲首選目標——但請別掉以輕心，不容忽視的重要例外情況也是客觀存在的。
兩者相似之處
讓我們先從二者的相似之處談起。Memcached與Redis都屬於內存內、鍵值數據存儲方案。它們都從屬於數據管理解決方案中的NoSQL家族，而且都基於同樣的鍵值數據模型。雙方都選擇將全部數據保存在內存當中，這自然也就讓它們成爲非常理想的緩衝層實現方案。從性能表現的角度來看，兩類數據存儲機制也具備諸多共通性，包括擁有幾乎相同的特徵(與指標)表現、而且高度關注工作負載的數據吞吐量與延遲狀況。
除了同爲內存內鍵值數據存儲方案，Memcached與Redis還都是相當成熟而且極具人氣的開源項目。Memcached最初是由Brad Fitzpatrick於2003年開發而成，當時其直接服務對象爲LiveJournal交友網站。在此之後，Memcached被重新用C語言進行了編寫(其最初實現方式爲Perl語言)且投身於公共領域，並在這裏逐步發展爲現代Web應用程序的構建基石。Memcached項目的當前開發工作主要關注其運行穩定性及優化效果方面，而不再積極爲其打造更多新型功能。
Redis則由Salvatore Sanfilippo於2009年創建，而且時至今日Sanfilippo仍然擔任着該項目的首席開發者以及惟一維護者的角色。Redis有時候會被人們稱爲“強化版的Memcached”。考慮到從Memcached身上吸取並借鑑到大量寶貴的經驗教訓，這樣的評價其實並不令人意外。Redis在功能多樣性方面要勝過Memcached，這雖然讓者更爲強大也更具靈活性、但其複雜程度也較後者爲甚。
作爲兩套被衆多企業採納並部署在無數關鍵性生產任務環境當中的解決方案，Memcached與Redis在任何一種可行性編程語言領域都擁有能夠提供支持的客戶端庫，而且二者也被包含在開發人員們使用的多種庫及軟件包之內。事實上，現在我們甚至已經很難找到一套不包含Memcached或者Redis內置支持機制的Web堆棧。
Memcached與Redis爲什麼如此受人擁戴?除了二者卓越的實際效果之外，雙方各自極爲簡便的上手難度也是又一大加分項。無論是Memcached還是Redis，其使用便捷性在開發人員當中都可謂廣爲人知。只需要幾分鐘我們就能完成安裝工作，並讓它們開始與應用程序順暢協作。換句話來說，只需投入一小部分時間與精力，大家就能獲得立竿見影且效果極佳的性能表現提升——具體而言，性能將直接步入新的量級。面對如此簡單而又能夠帶來巨大收益的解決方案，又有誰能抗拒得了它們的誘惑呢?
何時應該使用Memcached
相對Memcached而言，Redis的面世時間更晚且具備更多功能，因此開發人員通常將其視爲默認性首選方案。不過有兩類特殊場景仍然是Memcached的一家天下。首先就是對小型靜態數據進行緩存處理，最具代表性的例子就是HTML代碼片段。Memcached的內部內存管理機制雖然不像Redis的那樣複雜，但卻更具實際效率——這是因爲Memcached在處理元數據時所消耗的內存資源相對更少。作爲Memcached所支持的惟一一種數據類型，字符串非常適合用於保存那些只需要進行讀取操作的數據，因爲字符串本身無需進行進一步處理。
除此之外，Memcached在橫向擴展方面也比Redis更具優勢。由於其在設計上的思路傾向以及相對更爲簡單的功能設置，Memcached在實現擴展時的難度比Redis低得多。不過根據我們瞭解到的情況，目前已經有多種經過測試且切實有效的方案能夠將Redis擴展至多臺服務器之上，而其即將發佈的3.0版本(感興趣的朋友可以點擊此處查看其候選版本說明)將包含專門針對橫向擴展場景的內置集羣化機制。
何時應該使用Redis
除非大家需要考慮某種限定性條件(例如處理傳統應用程序)對於Memcached的特殊依賴性，或者自己的實際用例屬於前面提到的兩類場景中的一種，否則請直接選擇Redis並加以運用。憑藉着Redis所帶來的卓越緩存方案，我們將擁有強大的處理能力——例如對緩存內容及持久性進行細節調整的能力——以及出色的整體執行效率。
Redis幾乎在緩存管理工作中的每一個側面都表現出顯而易見的優越性。這套緩存方案採用所謂數據回收機制，能夠將陳舊數據從內存中刪除以提供新數據所必需的緩存空間。Memcached的數據回收機制使用的是LRU(即最低近期使用量)算法，而且往往會比較武斷地直接刪除掉與新數據體系相近的原有內容。相比之下，Redis允許用戶更爲精準地進行細化控制，利用六種不同回收策略確切提高緩存資源的實際利用率。Redis還採用更爲複雜的內存管理與回收對象備選方案。
Redis還能爲我們帶來最大程度的靈活性空間，從而保證管理員在打理緩存對象時擁有充裕的施展平臺。在這方面，Memcached將鍵名限制在250字節，值也被限制在不超過1MB，且只適用於普通字符串。相比之下，Redis則將鍵名與值的最大上限各自設定爲512MB，且支持二進制格式。Redis支持六種數據類型，因此能夠更加智能地對數據進行緩存處理及操作，這相當於爲應用程序開發人員敞開了一道通往無儘可能性的大門。
相對於將對象保存爲序列化字符串，Redis允許開發人員以散列方式將對象域及值加以保存，並利用單一鍵對其進行管理。Redis散列機制的存在保證開發人員無需經歷獲取完整字符串、反序列化、更新值、對象重新序列化並在每次值更新後利用其替代緩存內完整字符串這一系列複雜的流程——這也意味着資源消耗量得以降低、性能表現迎來顯著提升。Redis所支持的其它數據類型，例如Lists以及Sets——也可被用於實現更加複雜的緩存管理模式。
Redis的另一大重要優勢在於，它所保存的數據具備透明化特性，也就是說服務器能夠直接對這些數據進行操作。Redis當中提供160多種可用命令，其中大部分用於實現數據處理操作並通過服務器端腳本將邏輯嵌入至數據存儲體系當中。這些內置命令及用戶腳本帶來了極大的靈活性優勢，足以幫助大家直接在Redis內部完成數據處理任務——而不必將數據在網絡中的其它專門處理系統之間來回移動。
Redis還提供可選而且能夠具體調整的數據持久性方案，其設計目的在於在發生規劃內停機或者計劃外故障之後對緩存內容進行重新引導。雖然我們更傾向於強調緩存內數據的易失性與暫時性，但將數據在磁盤中加以持久保存在某些緩存場景當中仍然極具現實意義。這種機制能夠在設備重啓之後快速將保存在磁盤上的數據重新載入至緩存當中，從而大大縮短緩存預熱週期並根據主數據存儲內容對當前緩存內容進行重新評估。
最後但也同樣重要的一點是，Redis能夠提供複製功能。複製功能旨在幫助緩存體系實現高可用性配置方案，從而在遭遇故障的情況下繼續爲應用程序提供不間斷的緩存服務。很明顯，一套成熟的緩存方案應該能夠在應用程序發生故障時略微甚至完全不給用戶體驗或者應用程序性能表現帶來任何影響，而這種對緩存內容及服務可用性的有力保障在大多數情況下也成爲緩存解決方案的一大主要優勢。
開源軟件業界一直在不斷努力，爲我們帶來當下技術領域中最爲出色的各類解決方案。而在談到利用緩存機制對應用程序性能表現加以提升這一話題時，Redis與Memcached作爲兩款廣受讚譽而且久經考驗的解決方案、也自然而然地成爲完成這項任務的兩大首選技術成果。不過從功能多樣性以及設計先進性的角度出發，Redis顯然更適合被大家作爲通用性的首選方案——除了少部分特殊場景之外。