選redis還是memcache，源碼怎麼說？

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，服務端叢集沒有天然支援水準擴充，需要在用戶端進行分片，這其實對調用方并不友好。如果能服務端叢集能夠支援水準擴充，會更完美一些。