前言

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

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

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

要分析它們的區(qū)別，主要從以下幾個(gè)方面對(duì)比：

• 線程模型

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

• 淘汰策略

• 管道與事務(wù)

• 持久化

• 高可用

• 集群化

線程模型

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

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

這樣做好的好處是，當(dāng)某個(gè)請(qǐng)求處理比較耗時(shí)，不會(huì)影響到其他請(qǐng)求的處理。

當(dāng)然，缺點(diǎn)是CPU的多線程切換必然存在性能損耗，同時(shí)，多線程在訪問共享資源時(shí)必然要加鎖，也會(huì)在一定程度上降低性能。

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

這意味著使用Redis，一旦某個(gè)請(qǐng)求處理耗時(shí)比較長(zhǎng)，那么整個(gè)Redis就會(huì)阻塞住，直到這個(gè)請(qǐng)求處理完成后返回，才能處理下一個(gè)請(qǐng)求，使用Redis時(shí)一定要避免復(fù)雜的耗時(shí)操作。

單線程的好處是，少了CPU的上下文切換損耗，沒有了多線程訪問資源的鎖競(jìng)爭(zhēng)，但缺點(diǎn)是無法利用CPU多核的性能。

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

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

“

嚴(yán)格來說，Redis的單線程指的是處理請(qǐng)求的線程，它本身還有其他線程在工作，例如有其他線程用來異步處理耗時(shí)的任務(wù)。

Redis6.0又進(jìn)一步完善了多線程，在接收請(qǐng)求和發(fā)送請(qǐng)求時(shí)使用多線，進(jìn)一步提高了處理性能。

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

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

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

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

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

• list：可以方便的構(gòu)建一個(gè)鏈表，或者當(dāng)作隊(duì)列使用

• hash：靈活地操作我們需要的字段，進(jìn)行“整存零取”、“零存整取”以及“零存零取”

• set：構(gòu)建一個(gè)不重復(fù)的集合，并方便地進(jìn)行差集、并集運(yùn)算

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

• geo：用于地圖相關(guān)的業(yè)務(wù)，標(biāo)識(shí)兩個(gè)地點(diǎn)的坐標(biāo)，以及計(jì)算它們的距離

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

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

淘汰策略

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

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

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

同時(shí)Redis提供了多種淘汰策略：

• volatile-lru：從過期key中按LRU機(jī)制淘汰

• allkeys-lru：在所有key中按LRU機(jī)制淘汰

• volatile-random：在過期key中隨機(jī)淘汰key

• allkeys-random：在所有key中隨機(jī)淘汰key

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

• volatile-lfu：在所有key中按LFU機(jī)制淘汰

• allkeys-lfu：在過期key中按LFU機(jī)制淘汰

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

管道與事務(wù)

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

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

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

持久化

Memcached不支持?jǐn)?shù)據(jù)的持久化，如果Memcached服務(wù)宕機(jī)，那么這個(gè)節(jié)點(diǎn)的數(shù)據(jù)將全部丟失。

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

• RDB：將整個(gè)實(shí)例中的數(shù)據(jù)快照到磁盤上，全量持久化

• AOF：把每一個(gè)寫命令持久到磁盤，增量持久化

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

高可用

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

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

同時(shí)Redis還提供了哨兵節(jié)點(diǎn)，在主節(jié)點(diǎn)宕機(jī)時(shí)，主動(dòng)把從節(jié)點(diǎn)提升為主節(jié)點(diǎn)，繼續(xù)提供服務(wù)。

主從兩個(gè)節(jié)點(diǎn)還可以提供讀寫分離功能，進(jìn)一步提高程序訪問的性能。

集群化

Memcached和Redis都是由多個(gè)節(jié)點(diǎn)組成集群對(duì)外提供服務(wù)，但他們的機(jī)制也有所不同。

Memcached的集群化是在客戶端采用一致性哈希算法向指定節(jié)點(diǎn)發(fā)送數(shù)據(jù)，當(dāng)一個(gè)節(jié)點(diǎn)宕機(jī)時(shí)，其他節(jié)點(diǎn)會(huì)分擔(dān)這個(gè)節(jié)點(diǎn)的請(qǐng)求。

而Redis集群化采用的是每個(gè)節(jié)點(diǎn)維護(hù)一部分虛擬槽位，通過key的哈希計(jì)算，將key映射到具體的虛擬槽位上，這個(gè)槽位再映射到具體的Redis節(jié)點(diǎn)。

同時(shí)每個(gè)Redis節(jié)點(diǎn)都包含至少一個(gè)從節(jié)點(diǎn)，組成主從架構(gòu)，進(jìn)一步提高每個(gè)節(jié)點(diǎn)的高可用能力。

當(dāng)增加或下線節(jié)點(diǎn)時(shí)，需要手動(dòng)觸發(fā)數(shù)據(jù)遷移，重新進(jìn)行哈希槽位映射。

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

總結(jié)

從以上幾個(gè)方面進(jìn)行對(duì)比分析，總結(jié)如下表。

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

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

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

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

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

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝