成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

選Redis還是Memcache,源碼怎么說?

開發 開發工具 后端 Redis
memcache和redis是互聯網分層架構中,最常用的KV緩存。不少同學在選型的時候會糾結,到底是選擇memcache還是redis。

memcache和redis是互聯網分層架構中,最常用的KV緩存。不少同學在選型的時候會糾結,到底是選擇memcache還是redis。

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

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

什么時候傾向于選擇redis?

業務需求決定技術選型,當業務有這樣一些特點的時候,選擇redis會更加適合。

復雜數據結構

value是哈希,列表,集合,有序集合這類復雜的數據結構時,會選擇redis,因為mc無法滿足這些需求。

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

持久化

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

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

千萬不要把redis當作數據庫用:

  • redis的定期快照不能保證數據不丟失
  • redis的AOF會降低效率,并且不能支持太大的數據量

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

緩存場景,開啟固化功能,有什么利弊?

如果只是緩存場景,數據存放在數據庫,緩存在redis,此時如果開啟固化功能:

  • 優點是,redis掛了再重啟,內存里能夠快速恢復熱數據,不會瞬時將壓力壓到數據庫上,沒有一個cache預熱的過程。
  • 缺點是,在redis掛了的過程中,如果數據庫中有數據的修改,可能導致redis重啟后,數據庫與redis的數據不一致。

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

天然高可用

redis天然支持集群功能,可以實現主動復制,讀寫分離。

redis官方也提供了sentinel集群管理工具,能夠實現主從服務監控,故障自動轉移,這一切,對于客戶端都是透明的,無需程序改動,也無需人工介入。

而memcache,要想要實現高可用,需要進行二次開發,例如客戶端的雙讀雙寫,或者服務端的集群同步。

但是,這里要提醒的是,大部分業務場景,緩存真的需要高可用么?

  • 緩存場景,很多時候,是允許cache miss
  • 緩存掛了,很多時候可以通過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會快一些。

***說兩點

1. 代碼可讀性,代碼質量

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

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

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

畫外音:理論上,mc只支持kv,而redis支持了這么多功能,mc性能應該高非常多非常多,但實際并非如此,真的可能和代碼質量有關。

2. 水平擴展的支持

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

【本文為51CTO專欄作者“58沈劍”原創稿件,轉載請聯系原作者】

戳這里,看該作者更多好文

責任編輯:趙寧寧 來源: 51CTO專欄
相關推薦

2021-01-31 18:58:31

redismemcache源碼

2018-12-19 09:15:36

SDN軟件定義網絡廣域網

2018-01-05 10:48:54

混合云尚陽科技IDC

2025-06-10 02:44:00

RAGAnthropic神經網絡

2019-01-09 08:42:18

2019-10-31 15:45:25

Java薪酬語言

2022-05-05 09:14:41

AlpineDocker鏡像開發

2020-12-16 18:00:06

數字貨幣數據安全數字化轉型

2021-01-18 18:30:49

服務器開發工具

2021-01-19 05:26:22

Github ActiJenkinsDevOps

2015-05-06 13:52:52

微軟外媒

2013-10-28 10:13:53

SDN技術SDN軟件定義網絡

2017-03-30 15:01:59

嵌入式

2017-07-13 09:48:22

Hadoop數據倉庫

2021-11-09 10:41:34

數字化轉型IT技術

2018-08-16 14:28:34

2015-05-07 14:37:01

CoreOSAppC紅帽

2023-07-07 08:15:18

JavaPython編寫

2020-11-24 06:00:55

PythonPython之父編程語言

2020-06-16 14:03:48

邊緣計算網絡人工智能
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 99久久婷婷国产精品综合 | 国产一区二区三区免费 | 美女爽到呻吟久久久久 | 夜夜骑首页 | 五月婷亚洲 | 国产精品乱码一区二三区小蝌蚪 | 精品久久久久一区二区国产 | 黑人巨大精品 | 国产精品乱码一二三区的特点 | 久久国产精品久久久久久 | 亚洲日本三级 | 毛片网站免费观看 | 精品1区2区 | 国产精品久久性 | 国产99免费| 国产目拍亚洲精品99久久精品 | 91新视频| 青青久草| 看a级黄色毛片 | 免费看黄视频网站 | 久久精品1 | 国产精品免费一区二区三区四区 | 国产激情视频网站 | 亚洲精品乱码久久久久久9色 | 91伊人网 | 特黄视频 | 欧美日韩成人一区二区 | 二区精品 | 一级毛片视频在线观看 | 暖暖成人免费视频 | 久久精彩 | 免费久久网站 | 日韩电影中文字幕在线观看 | 国产小视频精品 | 亚洲精品一区国语对白 | 亚洲一区二区久久 | 欧美一区二区三区的 | 久久福利电影 | 国产高清视频一区二区 | 欧产日产国产精品视频 | 中文字幕第一页在线 |