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

memcache和redis是互聯(lián)網(wǎng)分層架構(gòu)中，最常用的KV緩存。不少同學在選型的時候會糾結(jié)，到底是選擇memcache還是redis。

畫外音：不鼓勵粗暴的實踐，例如“memcache提供的功能是redis提供的功能的子集，不用想太多，選redis準沒錯”。

雖然redis比memcache更晚出來，且功能確實也更豐富，但對于一個技術(shù)人，了解“所以然”恐怕比“選擇誰”更重要一些。

什么時候傾向于選擇redis？

業(yè)務需求決定技術(shù)選型，當業(yè)務有這樣一些特點的時候，選擇redis會更加適合。

其一：需要支持復雜的數(shù)據(jù)結(jié)構(gòu)。

value是哈希，列表，集合，有序集合這類復雜的數(shù)據(jù)結(jié)構(gòu)時，會選擇redis，因為mc無法滿足這些需求。

最典型的場景，用戶訂單列表，用戶消息，帖子評論列表等。

其二：需要持久化。

mc無法滿足持久化的需求，只得選擇redis。

但是，這里要提醒的是，真的使用對了redis的持久化功能么？

千萬不要把redis當作數(shù)據(jù)庫用：

（1）redis的定期快照不能保證數(shù)據(jù)不丟失；

（2）redis的AOF會降低效率，并且不能支持太大的數(shù)據(jù)量；

不要期望redis做固化存儲會比mysql做得好，不同的工具做各自擅長的事情，把redis當作數(shù)據(jù)庫用，這樣的設(shè)計八成是錯誤的。

緩存場景，開啟固化功能，有什么利弊？

如果只是緩存場景，數(shù)據(jù)存放在數(shù)據(jù)庫，緩存在redis，此時如果開啟固化功能：

優(yōu)點是，redis掛了再重啟，內(nèi)存里能夠快速恢復熱數(shù)據(jù)，不會瞬時將壓力壓到數(shù)據(jù)庫上，沒有一個cache預熱的過程。

缺點是，在redis掛了的過程中，如果數(shù)據(jù)庫中有數(shù)據(jù)的修改，可能導致redis重啟后，數(shù)據(jù)庫與redis的數(shù)據(jù)不一致。

因此，只讀場景，或者允許一些不一致的業(yè)務場景，可以嘗試開啟redis的固化功能。

其三：需要天然高可用。

redis天然支持集群功能，可以實現(xiàn)主動復制，讀寫分離。

redis官方也提供了sentinel集群管理工具，能夠?qū)崿F(xiàn)主從服務監(jiān)控，故障自動轉(zhuǎn)移，這一切，對于客戶端都是透明的，無需程序改動，也無需人工介入。

而memcache，要想要實現(xiàn)高可用，需要進行二次開發(fā)，例如客戶端的雙讀雙寫，或者服務端的集群同步。

但是，這里要提醒的是，大部分業(yè)務場景，緩存真的需要高可用么？

（1）緩存場景，很多時候，是允許cache miss；

（2）緩存掛了，很多時候可以通過DB讀取數(shù)據(jù)；

所以，需要認真剖析業(yè)務場景，高可用，是否真的是對緩存的主要需求？

畫外音：即時通訊業(yè)務中，用戶的在線狀態(tài)，就有高可用需求。

其四：存儲的內(nèi)容比較大。

memcache的value存儲，最大為1M，如果存儲的value很大，只能使用redis。

什么時候傾向于memcache？

純KV，數(shù)據(jù)量非常大，并發(fā)量非常大的業(yè)務，使用memcache或許更適合。

這要從mc與redis的底層實現(xiàn)機制差異說起。

其一：內(nèi)存分配機制有差異。

memcache使用預分配內(nèi)存池的方式管理內(nèi)存，能夠省去內(nèi)存分配時間。

redis則是臨時申請空間，可能導致碎片。

從這一點上，mc會更快一些。

其二：虛擬內(nèi)存使用有差異。

memcache把所有的數(shù)據(jù)存儲在物理內(nèi)存里。

redis有自己的VM機制，理論上能夠存儲比物理內(nèi)存更多的數(shù)據(jù)，當數(shù)據(jù)超量時，會引發(fā)swap，把冷數(shù)據(jù)刷到磁盤上。

從這一點上，數(shù)據(jù)量大時，mc會更快一些。

其三：網(wǎng)絡(luò)模型有差異。

memcache使用非阻塞IO復用模型，redis也是使用非阻塞IO復用模型。

但由于redis還提供一些非KV存儲之外的排序，聚合功能，在執(zhí)行這些功能時，復雜的CPU計算，會阻塞整個IO調(diào)度。

從這一點上，由于redis提供的功能較多，mc會更快一些。

其四：線程模型有差異。

memcache使用多線程，主線程監(jiān)聽，worker子線程接受請求，執(zhí)行讀寫，這個過程中，可能存在鎖沖突。

redis使用單線程，雖無鎖沖突，但難以利用多核的特性提升整體吞吐量。

從這一點上，mc會快一些。

最后說兩點

其一：代碼可讀性，代碼質(zhì)量，redis完勝。

看過mc和redis的代碼，從可讀性上說，redis是我見過代碼最清爽的軟件，甚至沒有之一，或許簡單是redis設(shè)計的初衷，編譯redis甚至不需要configure，不需要依賴第三方庫，一個make就搞定了。

而memcache，可能是考慮了太多的擴展性，多系統(tǒng)的兼容性，代碼不清爽，看起來費勁。

例如網(wǎng)絡(luò)IO的部分，redis源碼1-2個文件就搞定了，mc使用了libevent，一個fd傳過來傳過去，又pipe又線程傳遞的，特別容易把人繞暈。

畫外音：理論上，mc只支持kv，而redis支持了這么多功能，mc性能應該高非常多非常多，但實際并非如此，真的可能和代碼質(zhì)量有關(guān)。

其二：水平擴展，都需要應用自己解決。

不管是mc和redis，服務端集群沒有天然支持水平擴展，需要在客戶端進行分片，這其實對調(diào)用方并不友好。如果能服務端集群能夠支持水平擴展，會更完美一些。

說了很多，希望大家對redis和memcache有了新的認識，哪怕是一點點。

架構(gòu)師之路-分享技術(shù)思路

相關(guān)推薦：

《不用緩存服務，還能怎么緩存數(shù)據(jù)？》

《群消息，究竟存1份還是多份？》

技術(shù)人，謝轉(zhuǎn)。