建站
咨詢
售后
建站咨詢
新聞中心
memcache和redis是互聯(lián)網(wǎng)分層架構(gòu)中，最常用的KV緩存。不少同學(xué)在選型的時(shí)候會(huì)糾結(jié)，到底是選擇memcache還是redis。
創(chuàng)新互聯(lián)自2013年創(chuàng)立以來，先為梅列等服務(wù)建站，梅列等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為梅列企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
畫外音：不鼓勵(lì)粗暴的實(shí)踐，例如“memcache提供的功能是redis提供的功能的子集，不用想太多，選redis準(zhǔn)沒錯(cuò)”。
雖然redis比memcache更晚出來，且功能確實(shí)也更豐富，但對(duì)于一個(gè)技術(shù)人，了解“所以然”恐怕比“選擇誰(shuí)”更重要一些。
什么時(shí)候傾向于選擇redis?
業(yè)務(wù)需求決定技術(shù)選型，當(dāng)業(yè)務(wù)有這樣一些特點(diǎn)的時(shí)候，選擇redis會(huì)更加適合。
其一：需要支持復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。
value是哈希，列表，集合，有序集合這類復(fù)雜的數(shù)據(jù)結(jié)構(gòu)時(shí)，會(huì)選擇redis，因?yàn)閙c無法滿足這些需求。
最典型的場(chǎng)景，用戶訂單列表，用戶消息，帖子評(píng)論列表等。
其二：需要持久化。
mc無法滿足持久化的需求，只得選擇redis。
但是，這里要提醒的是，真的使用對(duì)了redis的持久化功能么?
千萬不要把redis當(dāng)作數(shù)據(jù)庫(kù)用：
- redis的定期快照不能保證數(shù)據(jù)不丟失;
- redis的AOF會(huì)降低效率，并且不能支持太大的數(shù)據(jù)量;
不要期望redis做固化存儲(chǔ)會(huì)比mysql做得好，不同的工具做各自擅長(zhǎng)的事情，把redis當(dāng)作數(shù)據(jù)庫(kù)用，這樣的設(shè)計(jì)八成是錯(cuò)誤的。
緩存場(chǎng)景，開啟固化功能，有什么利弊?
如果只是緩存場(chǎng)景，數(shù)據(jù)存放在數(shù)據(jù)庫(kù)，緩存在redis，此時(shí)如果開啟固化功能：
優(yōu)點(diǎn)是，redis掛了再重啟，內(nèi)存里能夠快速恢復(fù)熱數(shù)據(jù)，不會(huì)瞬時(shí)將壓力壓到數(shù)據(jù)庫(kù)上，沒有一個(gè)cache預(yù)熱的過程。
缺點(diǎn)是，在redis掛了的過程中，如果數(shù)據(jù)庫(kù)中有數(shù)據(jù)的修改，可能導(dǎo)致redis重啟后，數(shù)據(jù)庫(kù)與redis的數(shù)據(jù)不一致。
因此，只讀場(chǎng)景，或者允許一些不一致的業(yè)務(wù)場(chǎng)景，可以嘗試開啟redis的固化功能。
其三：需要天然高可用。
redis天然支持集群功能，可以實(shí)現(xiàn)主動(dòng)復(fù)制，讀寫分離。
redis官方也提供了sentinel集群管理工具，能夠?qū)崿F(xiàn)主從服務(wù)監(jiān)控，故障自動(dòng)轉(zhuǎn)移，這一切，對(duì)于客戶端都是透明的，無需程序改動(dòng)，也無需人工介入。
而memcache，要想要實(shí)現(xiàn)高可用，需要進(jìn)行二次開發(fā)，例如客戶端的雙讀雙寫，或者服務(wù)端的集群同步。
但是，這里要提醒的是，大部分業(yè)務(wù)場(chǎng)景，緩存真的需要高可用么?
- 緩存場(chǎng)景，很多時(shí)候，是允許cache miss;
- 緩存掛了，很多時(shí)候可以通過DB讀取數(shù)據(jù);
所以，需要認(rèn)真剖析業(yè)務(wù)場(chǎng)景，高可用，是否真的是對(duì)緩存的主要需求?畫外音：即時(shí)通訊業(yè)務(wù)中，用戶的在線狀態(tài)，就有高可用需求。
其四：存儲(chǔ)的內(nèi)容比較大。
memcache的value存儲(chǔ)，最大為1M，如果存儲(chǔ)的value很大，只能使用redis。
什么時(shí)候傾向于memcache?
純KV，數(shù)據(jù)量非常大，并發(fā)量非常大的業(yè)務(wù)，使用memcache或許更適合。
這要從mc與redis的底層實(shí)現(xiàn)機(jī)制差異說起。
其一：內(nèi)存分配機(jī)制有差異。
memcache使用預(yù)分配內(nèi)存池的方式管理內(nèi)存，能夠省去內(nèi)存分配時(shí)間。
redis則是臨時(shí)申請(qǐng)空間，可能導(dǎo)致碎片。
從這一點(diǎn)上，mc會(huì)更快一些。
其二：虛擬內(nèi)存使用有差異。
memcache把所有的數(shù)據(jù)存儲(chǔ)在物理內(nèi)存里。
redis有自己的VM機(jī)制，理論上能夠存儲(chǔ)比物理內(nèi)存更多的數(shù)據(jù)，當(dāng)數(shù)據(jù)超量時(shí)，會(huì)引發(fā)swap，把冷數(shù)據(jù)刷到磁盤上。
從這一點(diǎn)上，數(shù)據(jù)量大時(shí)，mc會(huì)更快一些。
其三：網(wǎng)絡(luò)模型有差異。
memcache使用非阻塞IO復(fù)用模型，redis也是使用非阻塞IO復(fù)用模型。
但由于redis還提供一些非KV存儲(chǔ)之外的排序，聚合功能，在執(zhí)行這些功能時(shí)，復(fù)雜的CPU計(jì)算，會(huì)阻塞整個(gè)IO調(diào)度。
從這一點(diǎn)上，由于redis提供的功能較多，mc會(huì)更快一些。
其四：線程模型有差異。
memcache使用多線程，主線程監(jiān)聽，worker子線程接受請(qǐng)求，執(zhí)行讀寫，這個(gè)過程中，可能存在鎖沖突。
redis使用單線程，雖無鎖沖突，但難以利用多核的特性提升整體吞吐量。
從這一點(diǎn)上，mc會(huì)快一些。
最后說兩點(diǎn)
其一：代碼可讀性，代碼質(zhì)量，redis完勝。
看過mc和redis的代碼，從可讀性上說，redis是我見過代碼最清爽的軟件，甚至沒有之一，或許簡(jiǎn)單是redis設(shè)計(jì)的初衷，編譯redis甚至不需要configure，不需要依賴第三方庫(kù)，一個(gè)make就搞定了。
而memcache，可能是考慮了太多的擴(kuò)展性，多系統(tǒng)的兼容性，代碼不清爽，看起來費(fèi)勁。
例如網(wǎng)絡(luò)IO的部分，redis源碼1-2個(gè)文件就搞定了，mc使用了libevent，一個(gè)fd傳過來傳過去，又pipe又線程傳遞的，特別容易把人繞暈。
畫外音：理論上，mc只支持kv，而redis支持了這么多功能，mc性能應(yīng)該高非常多非常多，但實(shí)際并非如此，真的可能和代碼質(zhì)量有關(guān)。
其二：水平擴(kuò)展，都需要應(yīng)用自己解決。
不管是mc和redis，服務(wù)端集群沒有天然支持水平擴(kuò)展，需要在客戶端進(jìn)行分片，這其實(shí)對(duì)調(diào)用方并不友好。如果能服務(wù)端集群能夠支持水平擴(kuò)展，會(huì)更完美一些。
說了很多，希望大家對(duì)redis和memcache有了新的認(rèn)識(shí)，哪怕是一點(diǎn)點(diǎn)。
【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
網(wǎng)頁(yè)題目：選Redis還是MemCache，源碼怎么說？
本文來源：http://www.dlmjj.cn/article/djiosej.html
