當前位置:首頁 > 公眾號精選 > 架構(gòu)師社區(qū)
[導讀]我們都知道,Redis和Memcached都是內(nèi)存數(shù)據(jù)庫,它們的訪問速度非常之快。但我們在開發(fā)過程中,這兩個內(nèi)存數(shù)據(jù)庫,我們到底要如何選擇呢?它們的優(yōu)劣都有哪些?

作者:Kaito

鏈接:kaito-kidd.com/2020/06/28/redis-vs-memcached/

前言

我們都知道,Redis和Memcached都是內(nèi)存數(shù)據(jù)庫,它們的訪問速度非常之快。但我們在開發(fā)過程中,這兩個內(nèi)存數(shù)據(jù)庫,我們到底要如何選擇呢?它們的優(yōu)劣都有哪些?

為什么現(xiàn)在看Redis要比Memcached更火一些?

這篇文章,我們就從各個方面來對比這兩個內(nèi)存數(shù)據(jù)庫的差異,方便你在使用時,做出最符合業(yè)務(wù)需要的選擇。

要分析它們的區(qū)別,主要從以下幾個方面對比:

  • 線程模型

  • 數(shù)據(jù)結(jié)構(gòu)

  • 淘汰策略

  • 管道與事務(wù)

  • 持久化

  • 高可用

  • 集群化

線程模型

要說性能,必須要分析它們的服務(wù)模型。

Memcached處理請求采用多線程模型,并且基于IO多路復用技術(shù),主線程接收到請求后,分發(fā)給子線程處理。

這樣做好的好處是,當某個請求處理比較耗時,不會影響到其他請求的處理。

當然,缺點是CPU的多線程切換必然存在性能損耗,同時,多線程在訪問共享資源時必然要加鎖,也會在一定程度上降低性能。

Redis同樣采用IO多路復用技術(shù),但它處理請求采用是單線程模型,從接收請求到處理數(shù)據(jù)都在一個線程中完成。

這意味著使用Redis,一旦某個請求處理耗時比較長,那么整個Redis就會阻塞住,直到這個請求處理完成后返回,才能處理下一個請求,使用Redis時一定要避免復雜的耗時操作。

單線程的好處是,少了CPU的上下文切換損耗,沒有了多線程訪問資源的鎖競爭,但缺點是無法利用CPU多核的性能。

由于Redis是內(nèi)存數(shù)據(jù)庫,它的訪問速度非常地快,所以它的性能瓶頸不在于CPU,而在于內(nèi)存和網(wǎng)絡(luò)帶寬,這也是作者采用單線程模型的主要原因。同時,單線程對于程序開發(fā)非常友好,調(diào)試起來也很方便。開發(fā)多線程程序必然會增加一定的調(diào)試難度。

因此,當我們的業(yè)務(wù)使用key的數(shù)據(jù)比較大時,Memcached的訪問性能要比Redis好一些。如果key的數(shù)據(jù)比較小,兩者差別并不大。

嚴格來說,Redis的單線程指的是處理請求的線程,它本身還有其他線程在工作,例如有其他線程用來異步處理耗時的任務(wù)。

Redis6.0又進一步完善了多線程,在接收請求和發(fā)送請求時使用多線,進一步提高了處理性能。

數(shù)據(jù)結(jié)構(gòu)

Memcached支持的數(shù)據(jù)結(jié)構(gòu)很單一,僅支持string類型的操作。并且對于value的大小限制必須在1MB以下,過期時間不能超過30天。

而Redis支持的數(shù)據(jù)結(jié)構(gòu)非常豐富,除了常用的數(shù)據(jù)類型string、list、hash、set、zset之外,還可以使用geo、hyperLogLog數(shù)據(jù)類型。

使用Memcached時,我們只能把數(shù)據(jù)序列化后寫入到Memcached中。然后再從Memcached中讀取數(shù)據(jù),再反序列化為我們需要的格式,只能“整存整取”。

而Redis對于不同的數(shù)據(jù)結(jié)構(gòu)可以采用不同的操作方法,非常靈活。

  • list:可以方便的構(gòu)建一個鏈表,或者當作隊列使用

  • hash:靈活地操作我們需要的字段,進行“整存零取”、“零存整取”以及“零存零取”

  • set:構(gòu)建一個不重復的集合,并方便地進行差集、并集運算

  • zset:構(gòu)建一個排行榜,或帶有權(quán)重的列表

  • geo:用于地圖相關(guān)的業(yè)務(wù),標識兩個地點的坐標,以及計算它們的距離

  • hyperLogLog:使用非常少的內(nèi)存計算UV

總之,Redis正是因為提供了這么豐富的數(shù)據(jù)結(jié)構(gòu),近幾年在內(nèi)存數(shù)據(jù)庫領(lǐng)域大放異彩,為我們的業(yè)務(wù)開發(fā)提供了極大的便利。

淘汰策略

Memcached必須設(shè)置整個實例的內(nèi)存上限,數(shù)據(jù)達到上限后觸發(fā)LRU淘汰機制,優(yōu)先淘汰不常用使用的數(shù)據(jù)。

但它的數(shù)據(jù)淘汰機制存在一些問題:剛寫入的數(shù)據(jù)可能會被優(yōu)先淘汰掉,這個問題主要是它本身內(nèi)存管理設(shè)計機制導致的。

Redis沒有限制必須設(shè)置內(nèi)存上限,如果內(nèi)存足夠使用,Redis可以使用足夠大的內(nèi)存。

同時Redis提供了多種淘汰策略:

  • volatile-lru:從過期key中按LRU機制淘汰

  • allkeys-lru:在所有key中按LRU機制淘汰

  • volatile-random:在過期key中隨機淘汰key

  • allkeys-random:在所有key中隨機淘汰key

  • volatile-ttl:優(yōu)先淘汰最近要過期的key

  • volatile-lfu:在所有key中按LFU機制淘汰

  • allkeys-lfu:在過期key中按LFU機制淘汰

我們可以針對業(yè)務(wù)場景,使用不同的數(shù)據(jù)淘汰策略。

管道與事務(wù)

Redis還支持管道功能,客戶端一次性打包發(fā)送多條命令到服務(wù)端,服務(wù)端依次處理客戶端發(fā)來的命令。這樣可以減少來回往來的網(wǎng)絡(luò)IO次數(shù),提供高訪問性能。

另外它還支持事務(wù),這里所說的事務(wù)并不是MySQL那樣嚴格的事務(wù)模型,這種事務(wù)模型是Redis特有的。

一般事務(wù)會配合管道一塊使用,客戶端一次性打包發(fā)送多條命令到服務(wù)端,并且標識這些命令必須嚴格按順序執(zhí)行,不能被其他客戶端打斷。同時執(zhí)行事務(wù)之前,客戶端可以告訴服務(wù)端某個key稍后會進行相關(guān)操作,如果這個客戶端在操作這個key之前,有其他客戶端對這個key進行更改,那么當前客戶端在執(zhí)行這些命令時會放棄整個事務(wù)操作,保證一致性。

持久化

Memcached不支持數(shù)據(jù)的持久化,如果Memcached服務(wù)宕機,那么這個節(jié)點的數(shù)據(jù)將全部丟失。

Redis支持將數(shù)據(jù)持久化磁盤上,提供RDB和AOF兩種方式:

  • RDB:將整個實例中的數(shù)據(jù)快照到磁盤上,全量持久化

  • AOF:把每一個寫命令持久到磁盤,增量持久化

Redis使用這兩種方式相互配合,完成數(shù)據(jù)完整性保障,最大程度降低服務(wù)宕機導致的數(shù)據(jù)丟失問題。

高可用

Memcached沒有主從復制架構(gòu),只能單節(jié)點部署,如果節(jié)點宕機,那么該節(jié)點數(shù)據(jù)全部丟失。業(yè)務(wù)需要對這種情況做兼容處理,當某個節(jié)點不可用時,把數(shù)據(jù)寫入到其他節(jié)點以降低對業(yè)務(wù)的影響。

Redis擁有主從復制架構(gòu),兩個節(jié)點組成主從架構(gòu),從可以實時同步主的數(shù)據(jù),提高整個Redis服務(wù)的可用性。

同時Redis還提供了哨兵節(jié)點,在主節(jié)點宕機時,主動把從節(jié)點提升為主節(jié)點,繼續(xù)提供服務(wù)。

主從兩個節(jié)點還可以提供讀寫分離功能,進一步提高程序訪問的性能。

集群化

Memcached和Redis都是由多個節(jié)點組成集群對外提供服務(wù),但他們的機制也有所不同。

Memcached的集群化是在客戶端采用一致性哈希算法向指定節(jié)點發(fā)送數(shù)據(jù),當一個節(jié)點宕機時,其他節(jié)點會分擔這個節(jié)點的請求。

而Redis集群化采用的是每個節(jié)點維護一部分虛擬槽位,通過key的哈希計算,將key映射到具體的虛擬槽位上,這個槽位再映射到具體的Redis節(jié)點。

同時每個Redis節(jié)點都包含至少一個從節(jié)點,組成主從架構(gòu),進一步提高每個節(jié)點的高可用能力。

當增加或下線節(jié)點時,需要手動觸發(fā)數(shù)據(jù)遷移,重新進行哈希槽位映射。

Redis官方的集群化解決方案為Redis cluster,它采用無中心化的設(shè)計。另外也有第三方的采用中心化設(shè)計proxy方式的集群化解決方案,例如Codis、Twemproxy。

總結(jié)

從以上幾個方面進行對比分析,總結(jié)如下表。

# Memcached Redis
線程模型 多線程 單線程
數(shù)據(jù)結(jié)構(gòu) 僅支持string、value最大1M、過期時間不能超過30天 string、list、hash、set、zset、geo、hyperLogLog
淘汰策略 LRU LRU、LFU、隨機等多種策略
管道與事務(wù) 不支持 支持
持久化 不支持 支持
高可用 不支持 主從復制+哨兵
集群化 客戶端一致性哈希算法 主從復制+哨兵+固定哈希槽位

整體來說,Redis提供了非常豐富的功能,而且性能基本上與Memcached相差無幾,這也是它最近這幾年占領(lǐng)內(nèi)存數(shù)據(jù)庫鰲頭的原因。

如果你的業(yè)務(wù)需要各種數(shù)據(jù)結(jié)構(gòu)給予支撐,同時要求數(shù)據(jù)的高可用保障,那么選擇Redis是比較合適的。

如果你的業(yè)務(wù)非常簡單,只是簡單的set/get,并且對于內(nèi)存使用并不高,那么使用簡單的Memcached足夠。

如果此文章能給您帶來小小的工作效率提升,不妨在看、轉(zhuǎn)發(fā)一下,以鼓勵我寫出更好的文章!

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒關(guān)注的小伙伴,可以長按關(guān)注一下:

為什么Redis要比Memcached更火?

為什么Redis要比Memcached更火?

為什么Redis要比Memcached更火?

長按訂閱更多精彩▼

為什么Redis要比Memcached更火?

如有收獲,點個在看,誠摯感謝


免責聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!

本站聲明: 本文章由作者或相關(guān)機構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫毥谦F公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運行,同時企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風險,如企業(yè)系統(tǒng)復雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機 衛(wèi)星通信

要點: 有效應(yīng)對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅持高質(zhì)量發(fā)展策略,塑強核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運營商 數(shù)字經(jīng)濟

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術(shù)學會聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(shù)(集團)股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉