選redis還是memcache,原始碼怎麼說?

2021-08-21 02:38:47 字數 2425 閱讀 7022

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,服務端集群沒有天然支援水平擴充套件,

需要在客戶端進行分片,這其實對呼叫方並不友好

。如果能服務端集群能夠支援水平擴充套件,會更完美一些。

選redis還是memcache,原始碼怎麼說?

memcache和redis是網際網路分層架構中,最常用的kv快取。不少同學在選型的時候會糾結,到底是選擇memcache還是redis。畫外音 不鼓勵粗暴的實踐,例如 memcache提供的功能是redis提供的功能的子集,不用想太多,選redis準沒錯 雖然redis比memcache更晚出來,...

選redis還是memcache,原始碼怎麼說?

memcache和redis是網際網路分層架構中,最常用的kv快取。不少同學在選型的時候會糾結,到底是選擇memcache還是redis。畫外音 不鼓勵粗暴的實踐,例如 memcache提供的功能是redis提供的功能的子集,不用想太多,選redis準沒錯 雖然redis比memcache更晚出來,...

選redis還是memcache,原始碼怎麼說?

memcache和redis是網際網路分層架構中,最常用的kv快取。不少同學在選型的時候會糾結,到底是選擇memcache還是redis。畫外音 不鼓勵粗暴的實踐,例如 memcache提供的功能是redis提供的功能的子集,不用想太多,選redis準沒錯 雖然redis比memcache更晚出來,...