作者：Gamer_young
連結：https://www.jianshu.com/p/0cee8085fc8f
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。
 

使用場景：

一、如果需要快取的資料只是key-value 這樣簡單的結構時，採用Memcache，足夠穩定可靠。如果有持久化需求、儲存、排序等一系列複製操作時，或者對資料結構和處理有高階要求的應用，選擇Redis。

二、memcache使用場景：

1、在動態系統中減少資料庫負載，提升效能，做快取，適合多讀少寫，大資料量的情況（如人人網大量查詢使用者資訊、好友資訊、文章資訊等）。它的一個總原則是將經常需要從資料庫讀取的資料快取在memcached中，這些資料也分為幾類：

（1）經常被讀取並且實時性要求不強可以等到自動過期的資料。例如網站首頁最新文章列表、某某排行等資料。也就是雖然新資料產生了，但對使用者體驗不會產生任何影響的場景。這類資料就使用典型的快取策略，設定一過合理的過期時間，當資料過期以後再從資料庫中讀取。當然你得制定一個快取清除策略，便於編輯或者其它人員能馬上看到效果。

（2）經常被讀取並且實時性要求強的資料。比如使用者的好友列表，使用者文章列表，使用者閱讀記錄等。這類資料首先被載入到memcached中，當發生更改（新增、修改、刪除）時就清除快取。在快取的時候，我將查詢的SQL語句md5（）得到它的 hash值作為key,結果陣列作為值寫入memcached，並且將該SQL涉及的table_name以及hash值配對存入memcached中。 當更改了這個表時，我就將與此表相配對的key的快取全部刪除。

2、秒殺功能：一個人下單，要牽涉資料庫讀取，寫入訂單，更改庫存，及事務要求， 對於傳統型資料庫來說，壓力是巨大的。

可以利用 memcached 的 incr/decr 功能， 在記憶體儲存 count 庫存量， 秒殺 1000 臺每人搶單主要在記憶體操作，速度非常快，搶到 count < =1000 的號人，得一個訂單號，這時再去另一個頁面慢慢支付。

三、不適用memcached的業務場景：

1、快取物件的大小大於1MB；

2、key的長度大於250字元（所以我們把一些key先md5再儲存）；

3、應用執行在不安全的環境中Memcached為提供任何安全策略，僅僅通過telnet就可以訪問到memcached。如果應用執行在共享的系統上，需要著重考慮安全問題；

 4、業務本身需要的是持久化資料。

四、Redis場景：適用於對讀寫效率要求都很高，資料處理業務複雜和對安全性要求較高的系統（如新浪微博的計數和微博釋出部分系統，對資料安全性、讀寫要求都很高）、Pub/Sub構建實時訊息系統、統計。

區別：

1、儲存方式：Memcache把資料全部存在記憶體之中，斷電後會掛掉，資料不能超 過記憶體大小。Redis支援資料的持久化，可以將記憶體中的資料儲存在磁碟中，重啟時可以再次載入進行使用。（RDB快照和AOF日誌兩 種持久化方式）。

2、Redis支援資料的備份，及master-slave模式的資料備份。

3、資料支援型別：Redis在資料支援上要比Memcache多得多。

4、使用底層模型不同：新版本的Redis直接自己構建了VM機制，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求。

 5、 redis有一個致命缺陷 當記憶體滿了時 dump資料cpu佔用100%。

總結：

1、Redis使用最佳方式是全部資料in-memory。

2、Redis更多場景是作為Memcache的替代者來使用。

3、當需要除key/value之外的更多資料型別支援時，使用Redis更合適。

 4、當儲存的資料不能被剔除時，使用Redis更合適。

 5、如果要說記憶體使用效率，使用簡單的key-value儲存的話，Memcached的記憶體利用率更高，而如果Redis採用hash結構來做key-value儲存，由於其組合式的壓縮，其記憶體利用率會高於Memcached。當然，這和你的應用場景和資料特性有關。