緩存技術PK：選擇Memcached仍是Redis(轉)

【IT168 技術】要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顯然更適合被你們做爲通用性的首選方案——除了少部分特殊場景以外。

 

原地址：http://tech.it168.com/a2014/1016/1674/000001674122.shtml

 

Memcached優點：

(1) 對小型靜態數據進行緩存處理，Memcached在處理元數據時所消耗的內存資源相對更少

(2) Memcached在橫向擴展方面也比Redis更具優點，但該優點如今逐漸縮小

 

Memcached缺點：

(1) Memcached的數據回收機制使用的是LRU(即最低近期使用量)算法，並且每每會比較武斷地直接刪除掉與新數據體系相近的原有內容 

(2) 只能將對象序列化爲二進制進行緩存

 

Redis優點：

(1) 緩存內容及持久性進行細節調整的能力

(2) 更加智能地對數據進行緩存處理及操做

(3) 散列方式將對象域及值加以保存，保存的數據具有透明化特性，也就是說服務器可以直接對這些數據進行操做

(4) 更加複雜的緩存管理模式，能夠緩存List、Set等，用於緩存更加複雜的管理方式

(5) 可以具體調整的數據持久性方案

(6) Redis可以提供複製功能。複製功能旨在幫助緩存體系實現高可用性配置方案，從而在遭遇故障的狀況下繼續爲應用程序提供不間斷的緩存服務

 

Redis缺點：

(1) 

 

Redis 疑問：

(1) 六種不一樣回收策略確切提升緩存資源的實際利用率，是哪六種回收策略