memcache和redis是互聯網分層架構中，最常用的KV緩存。不少同學在選型的時候會糾結，到底是選擇memcache還是redis。
畫外音：不鼓勵粗暴的實踐，例如“memcache提供的功能是redis提供的功能的子集，不用想太多，選redis準沒錯”。
雖然redis比memcache更晚出來，且功能確實也更豐富，但對於一個技術人，瞭解“所以然”恐怕比“選擇誰”更重要一些。
什麼時候傾向於選擇redis？
業務需求決定技術選型，當業務有這樣一些特點的時候，選擇redis會更加適合。
複雜數據結構
value是哈希，列表，集合，有序集合這類複雜的數據結構時，會選擇redis，因為mc無法滿足這些需求。
最典型的場景，用戶訂單列表，用戶消息，帖子評論列表等。
持久化
mc無法滿足持久化的需求，只得選擇redis。
但是，這裡要提醒的是，
真的使用對了redis的持久化功能麼？千萬不要把redis當作數據庫用：
（1）redis的定期快照不能保證數據不丟失
（2）redis的AOF會降低效率，並且不能支持太大的數據量
不要期望redis做固化存儲會比mysql做得好，不同的工具做各自擅長的事情，把redis當作數據庫用，這樣的設計八成是錯誤的。
緩存場景，開啟固化功能，有什麼利弊？
如果只是緩存場景，數據存放在數據庫，緩存在redis，此時如果開啟固化功能：
優點是，redis掛了再重啟，內存裡能夠快速恢復熱數據，不會瞬時將壓力壓到數據庫上，沒有一個cache預熱的過程。
缺點是，在redis掛了的過程中，如果數據庫中有數據的修改，可能導致redis重啟後，數據庫與redis的數據不一致。
因此，只讀場景，或者允許一些不一致的業務場景，可以嘗試開啟redis的固化功能。
天然高可用
redis天然支持集群功能，可以實現主動複製，讀寫分離。
redis官方也提供了sentinel集群管理工具，能夠實現主從服務監控，故障自動轉移，這一切，對於客戶端都是透明的，無需程序改動，也無需人工介入。
而memcache，要想要實現高可用，需要進行二次開發，例如客戶端的雙讀雙寫，或者服務端的集群同步。
但是，這裡要提醒的是，大部分業務場景，緩存真的需要高可用麼？
（1）緩存場景，很多時候，是允許cache miss
（2）緩存掛了，很多時候可以通過DB讀取數據
所以，需要認真剖析業務場景，高可用，是否真的是對緩存的主要需求？
畫外音：即時通訊業務中，用戶的在線狀態，就有高可用需求。
存儲的內容比較大
memcache的value存儲，最大為1M，如果存儲的value很大，只能使用redis。
什麼時候傾向於memcache？
純KV，數據量非常大，併發量非常大的業務，使用memcache或許更適合。
這要從mc與redis的底層實現機制差異說起。
內存分配
memcache使用預分配內存池的方式管理內存，能夠省去內存分配時間。
redis則是臨時申請空間，可能導致碎片。
從這一點上，mc會更快一些。
虛擬內存使用
memcache把所有的數據存儲在物理內存裡。
redis有自己的VM機制，理論上能夠存儲比物理內存更多的數據，當數據超量時，會引發swap，把冷數據刷到磁盤上。
從這一點上，數據量大時，mc會更快一些。
網絡模型
memcache使用非阻塞IO複用模型，redis也是使用非阻塞IO複用模型。
但由於redis還提供一些非KV存儲之外的排序，聚合功能，在執行這些功能時，複雜的CPU計算，會阻塞整個IO調度。
從這一點上，由於redis提供的功能較多，mc會更快一些。
線程模型
memcache使用多線程，主線程監聽，worker子線程接受請求，執行讀寫，這個過程中，可能存在鎖衝突。
redis使用單線程，雖無鎖衝突，但難以利用多核的特性提升整體吞吐量。
從這一點上，mc會快一些。
最後說兩點
代碼可讀性，代碼質量
看過mc和redis的代碼，從可讀性上說，redis是我見過代碼最清爽的軟件，甚至沒有之一，或許簡單是redis設計的初衷，編譯redis甚至不需要configure，不需要依賴第三方庫，一個make就搞定了。
而memcache，可能是考慮了太多的擴展性，多系統的兼容性，代碼不清爽，看起來費勁。
例如網絡IO的部分，redis源碼1-2個文件就搞定了，mc使用了libevent，一個fd傳過來傳過去，又pipe又線程傳遞的，特別容易把人繞暈。
畫外音：理論上，mc只支持kv，而redis支持了這麼多功能，mc性能應該高非常多非常多，但實際並非如此，真的可能和代碼質量有關。
水平擴展的支持
不管是mc和redis，服務端集群沒有天然支持水平擴展，需要在客戶端進行分片，這其實對調用方並不友好。如果能服務端集群能夠支持水平擴展，會更完美一些。
閱讀更多 Java高併發框架 的文章
