[[253797]]

 ▌1：極簡緩存架構(gòu)

通過JSR107規(guī)范，我們將框架定義為客戶端層、緩存提供層、緩存管理層、緩存存儲(chǔ)層。其中緩存存儲(chǔ)層又分為基本存儲(chǔ)層、LRU存儲(chǔ)層和Weak存儲(chǔ)層，如下圖所示。

緩存分層圖

其中：

客戶端層：使用者直接通過該層與數(shù)據(jù)進(jìn)行交互。

緩存提供層：主要對緩存管理層的生命周期進(jìn)行維護(hù)，負(fù)責(zé)緩存管理層的創(chuàng)建，保存、獲取以及銷毀。

緩存管理層：主要對緩存客戶端的生命周期進(jìn)行維護(hù)，負(fù)責(zé)緩存客戶端的創(chuàng)建，保存、獲取以及銷毀

緩存存儲(chǔ)層：負(fù)責(zé)數(shù)據(jù)以什么樣的形式進(jìn)行存儲(chǔ)。

基本存儲(chǔ)層：是以普通的ConcurrentHashMap為存儲(chǔ)核心,數(shù)據(jù)不淘汰。

LRU存儲(chǔ)層：是以最近最少用為原則進(jìn)行的數(shù)據(jù)存儲(chǔ)和緩存淘汰機(jī)制。

Weak存儲(chǔ)層：是以弱引用為原則的數(shù)據(jù)存儲(chǔ)和緩存淘汰機(jī)制。

▌2：容量評(píng)估

緩存系統(tǒng)主要消耗的是服務(wù)器的內(nèi)存，因此，在使用緩存時(shí)必須先對應(yīng)用需要緩存的數(shù)據(jù)大小進(jìn)行評(píng)估，包括緩存的數(shù)據(jù)結(jié)構(gòu)、緩存大小、緩存數(shù)量、緩存的失效時(shí)間，然后根據(jù)業(yè)務(wù)情況自行推算在未來一定時(shí)間內(nèi)的容量的使用情況，根據(jù)容量評(píng)估的結(jié)果來申請和分配緩存資源，否則會(huì)造成資源浪費(fèi)或者緩存空間不夠。

▌3：業(yè)務(wù)分離

建議將使用緩存的業(yè)務(wù)進(jìn)行分離，核心業(yè)務(wù)和非核心業(yè)務(wù)使用不同的緩存實(shí)例，從物理上進(jìn)行隔離，如果有條件，則請對每個(gè)業(yè)務(wù)使用單獨(dú)的實(shí)例或者集群，以減小應(yīng)用之間互相影響的可能性。筆者就經(jīng)常聽說有的公司應(yīng)用了共享緩存，造成緩存數(shù)據(jù)被覆蓋以及緩存數(shù)據(jù)錯(cuò)亂的線上事故。

▌4：監(jiān)控為王

所有的緩存實(shí)例都需要添加監(jiān)控，這是非常重要的，我們需要對慢查詢、大對象、內(nèi)存使用情況做可靠的監(jiān)控。

▌5：失效時(shí)間

任何緩存的key都必須設(shè)定緩存失效時(shí)間，且失效時(shí)間不能集中在某一點(diǎn)，否則會(huì)導(dǎo)致緩存占滿內(nèi)存或者緩存雪崩。

▌6：大量key同時(shí)失效時(shí)間的危害

在使用緩存時(shí)需要進(jìn)行緩存設(shè)計(jì)，要充分考慮如何避免常見的緩存穿透、緩存雪崩、緩存并發(fā)等問題，尤其是對于高并發(fā)的緩存使用，需要對key的過期時(shí)間進(jìn)行隨機(jī)設(shè)置，例如，將過期時(shí)間設(shè)置為10秒+random(2)，也就是將過期時(shí)間隨機(jī)設(shè)置成10～12秒。

筆者曾經(jīng)見過一個(gè)case：在應(yīng)用程序中對使用的大量緩存key設(shè)置了同一個(gè)固定的失效時(shí)間，當(dāng)緩存失效時(shí)，會(huì)造成在一段時(shí)間內(nèi)同時(shí)訪問數(shù)據(jù)庫，造成數(shù)據(jù)庫的壓力較大。

▌7：先更新數(shù)據(jù)庫后更新緩存有啥問題?

想象一下，如果兩個(gè)線程同時(shí)執(zhí)行更新操作，線程1更新數(shù)據(jù)庫后，線程2也更新了數(shù)據(jù)庫，然后開始寫緩存，但線程2先執(zhí)行了更新緩存的操作，而線程1在執(zhí)行更新緩存的時(shí)候就把線程2更新的數(shù)據(jù)給覆蓋掉了，這樣就會(huì)出現(xiàn)數(shù)據(jù)不一致。

▌8：先刪緩存， 行不行?

“先刪緩存，然后執(zhí)行數(shù)據(jù)庫事務(wù)”也有人討論這種方案，不過這種操作對于如商品這種查詢非常頻繁的業(yè)務(wù)不適用，因?yàn)樵谀銊h緩存的同時(shí)，已經(jīng)有另一個(gè)系統(tǒng)來讀緩存了，此時(shí)事務(wù)還沒有提交。當(dāng)然對于如用戶維度的業(yè)務(wù)是可以考慮的。

▌9：數(shù)據(jù)庫和緩存數(shù)據(jù)一致性

京東采用了通過canal更新緩存原子性的方法，如下圖所示。

最終一致性方案

幾個(gè)關(guān)注點(diǎn)：

更新數(shù)據(jù)時(shí)使用更新時(shí)間戳或者版本對比。

使用如canal訂閱數(shù)據(jù)庫binlog;此處把mysql看成發(fā)布者，binlog是發(fā)布的內(nèi)容，canal(canal 是阿里巴巴mysql數(shù)據(jù)庫binlog的增量訂閱&消費(fèi)組件)看成消費(fèi)者，canal訂閱binlog然后更新到Redis。

將更新請求按照相應(yīng)的規(guī)則分散到多個(gè)隊(duì)列，然后每個(gè)隊(duì)列的進(jìn)行單線程更新，更新時(shí)拉取***的數(shù)據(jù)保存;更新之前獲取相關(guān)的鎖再進(jìn)行更新。

▌10.先更新數(shù)據(jù)庫，再刪除緩存的一種實(shí)踐

流程如下圖所示：

過程不贅述，只強(qiáng)調(diào)一個(gè)，數(shù)據(jù)庫update變更會(huì)同步發(fā)到消息，通過消息去刪除緩存。如果刪除失敗，消息有重試機(jī)制保障。另外除了極端情況，緩存更新是比較及時(shí)的。

▌11：本地緩存的挑戰(zhàn)

如果對性能的要求不是非常高，則盡量使用分布式緩存，而不要使用本地緩存，因?yàn)楸镜鼐彺嬖诜?wù)的各個(gè)節(jié)點(diǎn)之間復(fù)制，在某一時(shí)刻副本之間是不一致的，如果這個(gè)緩存代表的是開關(guān)，而且分布式系統(tǒng)中的請求有可能會(huì)重復(fù)，就會(huì)導(dǎo)致重復(fù)的請求走到兩個(gè)節(jié)點(diǎn)，一個(gè)節(jié)點(diǎn)的開關(guān)是開，一個(gè)節(jié)點(diǎn)的開關(guān)是關(guān)，如果請求處理沒有做到冪等，就會(huì)造成處理重復(fù)，在嚴(yán)重情況下會(huì)造成資金損失。

▌12：緩存熱點(diǎn)與多級(jí)緩存

對于分布式緩存，我們需要在Nginx+Lua應(yīng)用中進(jìn)行應(yīng)用緩存來減少Redis集群的訪問沖擊;即首先查詢應(yīng)用本地緩存，如果***則直接緩存，如果沒有***則接著查詢Redis集群、回源到Tomcat;然后將數(shù)據(jù)緩存到應(yīng)用本地。如同14-8所示。

此處到應(yīng)用Nginx的負(fù)載機(jī)制采用：正常情況采用一致性哈希，如果某個(gè)請求類型訪問量突破了一定的閥值，則自動(dòng)降級(jí)為輪詢機(jī)制。另外對于一些秒殺活動(dòng)之類的熱點(diǎn)我們是可以提前知道的，可以把相關(guān)數(shù)據(jù)預(yù)先推送到應(yīng)用Nginx并將負(fù)載均衡機(jī)制降級(jí)為輪詢。

分布式緩存方案

另外可以考慮建立實(shí)時(shí)熱點(diǎn)發(fā)現(xiàn)系統(tǒng)來發(fā)現(xiàn)熱點(diǎn)，如下圖所示：

實(shí)時(shí)熱點(diǎn)發(fā)現(xiàn)方案

1)接入Nginx將請求轉(zhuǎn)發(fā)給應(yīng)用Nginx;

2)應(yīng)用Nginx首先讀取本地緩存;如果***直接返回，不***會(huì)讀取分布式緩存、回源到Tomcat進(jìn)行處理;

3)應(yīng)用Nginx會(huì)將請求上報(bào)給實(shí)時(shí)熱點(diǎn)發(fā)現(xiàn)系統(tǒng)，如使用UDP直接上報(bào)請求、或者將請求寫到本地kafka、或者使用flume訂閱本地nginx日志;上報(bào)給實(shí)時(shí)熱點(diǎn)發(fā)現(xiàn)系統(tǒng)后，它將進(jìn)行統(tǒng)計(jì)熱點(diǎn)(可以考慮storm實(shí)時(shí)計(jì)算);

4)根據(jù)設(shè)置的閥值將熱點(diǎn)數(shù)據(jù)推送到應(yīng)用Nginx本地緩存。

因?yàn)樽隽吮镜鼐彺?，因此對于?shù)據(jù)一致性需要我們?nèi)タ紤]，即何時(shí)失效或更新緩存：

1)如果可以訂閱數(shù)據(jù)變更消息，那么可以訂閱變更消息進(jìn)行緩存更新;

2)如果無法訂閱消息或者訂閱消息成本比較高，并且對短暫的數(shù)據(jù)一致性要求不嚴(yán)格(比如在商品詳情頁看到的庫存，可以短暫的不一致，只要保證下單時(shí)一致即可)，那么可以設(shè)置合理的過期時(shí)間，過期后再查詢新的數(shù)據(jù);

3)如果是秒殺之類的，可以訂閱活動(dòng)開啟消息，將相關(guān)數(shù)據(jù)提前推送到前端應(yīng)用，并將負(fù)載均衡機(jī)制降級(jí)為輪詢;

4)建立實(shí)時(shí)熱點(diǎn)發(fā)現(xiàn)系統(tǒng)來對熱點(diǎn)進(jìn)行統(tǒng)一推送和更新。

應(yīng)對緩存大熱點(diǎn)：數(shù)據(jù)復(fù)制模式

在Facebook有一招，就是通過多個(gè)key_index(key:xxx#N) 來解決數(shù)據(jù)的熱點(diǎn)讀問題。解決方案是所有熱點(diǎn)key發(fā)布到所有web服務(wù)器;每個(gè)服務(wù)器的key有對應(yīng)別名，可以通過client端的算法路由到某臺(tái)服務(wù)器;做刪除動(dòng)作時(shí)，刪除所有的別名key?？珊唵慰偨Y(jié)為一個(gè)通用的group內(nèi)一致模型。把緩存集群劃分為若干分組(group)，在同組內(nèi)，所有的緩存服務(wù)器，都發(fā)布熱點(diǎn)key的數(shù)據(jù)。

對于大量讀操作而言，通過client端路由策略，隨意返回一臺(tái)機(jī)器即可;而寫操作，有一種解法是通過定時(shí)任務(wù)來寫入;Facebook采取的是刪除所有別名key的策略。如何保障這一個(gè)批量操作都成功?

(1)容忍部分失敗導(dǎo)致的數(shù)據(jù)版本問題

(2)只要有寫操作，則通過定時(shí)任務(wù)刷新緩存;如果涉及3臺(tái)服務(wù)器，則都操作成功代表該任務(wù)表的這條記錄成功完成使命，否則會(huì)重試。

▌13：緩存失效的連接風(fēng)暴

引起這個(gè)問題的主要原因還是高并發(fā)的時(shí)候，平時(shí)我們設(shè)定一個(gè)緩存的過期時(shí)間時(shí)，可能有一些會(huì)設(shè)置1分鐘，5分鐘，并發(fā)很高可能會(huì)出在某一個(gè)時(shí)間同時(shí)生成了很多的緩存，并且過期時(shí)間都一樣，這個(gè)時(shí)候就可能引發(fā)過期時(shí)間到后，這些緩存同時(shí)失效，請求全部轉(zhuǎn)發(fā)到DB，DB可能會(huì)壓力過重。那如何解決這些問題呢?

其中的一個(gè)簡單方案就是將緩存失效時(shí)間分散開，比如我們可以在原有的失效時(shí)間基礎(chǔ)上增加一個(gè)隨機(jī)值，比如1-5分鐘隨機(jī)，這樣每一個(gè)緩存的過期時(shí)間的重復(fù)率就會(huì)降低，就很難引發(fā)集體失效的事件。

如果緩存集中在一段時(shí)間內(nèi)失效，DB的壓力凸顯。這個(gè)沒有***解決辦法，但可以分析用戶行為，盡量讓失效時(shí)間點(diǎn)均勻分布。

上述是緩存使用過程中經(jīng)常遇到的并發(fā)穿透、并發(fā)失效問題。一般情況下，我們解決這些問題的方法是，引入空值、鎖和隨機(jī)緩存過期時(shí)間的機(jī)制。

▌14：緩存預(yù)熱

提前把數(shù)據(jù)讀入到緩存的做法就是數(shù)據(jù)預(yù)熱處理。數(shù)據(jù)預(yù)熱處理要注意一些細(xì)節(jié)問題：

(1)是否有監(jiān)控機(jī)制確保預(yù)熱數(shù)據(jù)都寫成功了!筆者曾經(jīng)遇到部分?jǐn)?shù)據(jù)成功而影響高峰期業(yè)務(wù)的案例;

(2)數(shù)據(jù)預(yù)熱配備回滾方案，遇到緊急回滾時(shí)便于操作。對于新建cache server集群，也可以通過數(shù)據(jù)預(yù)熱模式來做一番手腳。如下圖所示，先從冷集群中獲取key，如果獲取不到，則從熱集群中獲取。同時(shí)把獲取到的key put到冷集群。如下圖

數(shù)據(jù)預(yù)熱

(3)預(yù)熱數(shù)據(jù)量的考量，要做好容量評(píng)估。在容量允許的范圍內(nèi)預(yù)熱全量，否則預(yù)熱訪問量高的。

(4)預(yù)熱過程中需要注意是否會(huì)因?yàn)榕繑?shù)據(jù)庫操作或慢sql等引發(fā)數(shù)據(jù)庫性能問題。

▌15：超時(shí)時(shí)間設(shè)計(jì)

在使用遠(yuǎn)程緩存(如Redis、Memcached)時(shí)，一定要對操作超時(shí)時(shí)間進(jìn)行設(shè)置，這是非常關(guān)鍵的，一般我們設(shè)計(jì)緩存作為加速數(shù)據(jù)庫讀取的手段，也會(huì)對緩存操作做降級(jí)處理，因此推薦使用更短的緩存超時(shí)時(shí)間，如果一定要給出一個(gè)數(shù)字，則希望是100毫秒以內(nèi)。

筆者曾經(jīng)遇到過一個(gè)案例：某個(gè)正常運(yùn)行的應(yīng)用突然報(bào)警線程數(shù)過高，之后很快就出現(xiàn)了內(nèi)存溢出。

分析原因?yàn)椋河捎诰彺孢B接數(shù)達(dá)到***限制，應(yīng)用無法連接緩存，并且超時(shí)時(shí)間設(shè)置得較大，導(dǎo)致訪問緩存的服務(wù)都在等待緩存操作返回，由于緩存負(fù)載較高，處理不完所有的請求，但是這些服務(wù)都在等待緩存操作返回，服務(wù)這時(shí)在等待，并沒有超時(shí)，就不能降級(jí)并繼續(xù)訪問數(shù)據(jù)庫。這在BIO模式下線程池就會(huì)撐滿，使用方的線程池也都撐滿;在NIO模式下一樣會(huì)使服務(wù)的負(fù)載增加，服務(wù)響應(yīng)變慢，甚至使服務(wù)被壓垮。

▌16：不要把緩存到存儲(chǔ)

大家都知道一個(gè)顛撲不破的真理：在分布式架構(gòu)下，一切系統(tǒng)都可能fail，無論是緩存、存儲(chǔ)包括數(shù)據(jù)庫還是應(yīng)用服務(wù)器，而且部分緩存本身就未提供持久化機(jī)制比如memcached。即使使用持久化機(jī)制的cache，也要慎用，如果作為唯一存儲(chǔ)的話。

▌17：緩存崩潰解決之道

當(dāng)我們使用分布式緩存時(shí)，應(yīng)該考慮如何應(yīng)對其中一部分緩存實(shí)例宕機(jī)的情況。接下來部分將介紹分布式緩存時(shí)的常用算法。而當(dāng)緩存數(shù)據(jù)是可丟失的情況時(shí)，我們可以選擇一致性哈希算法。

取模

對于取模機(jī)制如果其中一個(gè)實(shí)例壞了，如果摘除此實(shí)例將導(dǎo)致大量緩存不***，瞬間大流量可能導(dǎo)致后端DB/服務(wù)出現(xiàn)問題。對于這種情況可以采用主從機(jī)制來避免實(shí)例壞了的問題，即其中一個(gè)實(shí)例壞了可以那從/主頂上來。但是取模機(jī)制下如果增加一個(gè)節(jié)點(diǎn)將導(dǎo)致大量緩存不***，一般是建立另一個(gè)集群，然后把數(shù)據(jù)遷移到新集群，然后把流量遷移過去。

一致性哈希

對于一致性哈希機(jī)制如果其中一個(gè)實(shí)例壞了，如果摘除此實(shí)例將只影響一致性哈希環(huán)上的部分緩存不***，不會(huì)導(dǎo)致瞬間大量回源到后端DB/服務(wù)，但是也會(huì)產(chǎn)生一些影響。

▌18. 緩存崩潰后的快速恢復(fù)

如果出現(xiàn)之前說到的一些問題，可以考慮如下方案：

1)主從機(jī)制，做好冗余，即其中一部分不可用，將對等的部分補(bǔ)上去;

2)如果因?yàn)榫彺鎸?dǎo)致應(yīng)用可用性已經(jīng)下降可以考慮：

部分用戶降級(jí)，然后慢慢減少降級(jí)量;

后臺(tái)通過Worker預(yù)熱緩存數(shù)據(jù)。

也就是如果整個(gè)緩存集群壞了，而且沒有備份，那么只能去慢慢將緩存重建;為了讓部分用戶還是可用的，可以根據(jù)系統(tǒng)承受能力，通過降級(jí)方案讓一部分用戶先用起來，將這些用戶相關(guān)的緩存重建;另外通過后臺(tái)Worker進(jìn)行緩存數(shù)據(jù)的預(yù)熱。

▌19. 開啟Nginx Proxy Cache性能不升反降

開啟Nginx Proxy Cache后，性能下降，而且過一段內(nèi)存使用率到達(dá)98%;解決方案：

1)對于內(nèi)存占用率高的問題是內(nèi)核問題，內(nèi)核使用LRU機(jī)制，本身不是問題，不過可以通過修改內(nèi)核參數(shù)：

sysctl -wvm.extra_free_kbytes=6436787

sysctl -wvm.vfs_cache_pressure=10000

2)使用Proxy Cache在機(jī)械盤上性能差可以通過tmpfs緩存或nginx共享字典緩存元數(shù)據(jù)，或者使用SSD，我們目前使用內(nèi)存文件系統(tǒng)。

▌20：“網(wǎng)絡(luò)抖動(dòng)時(shí)，返回502錯(cuò)誤”緣于timeout

Twemproxy配置的timeout時(shí)間太長，之前設(shè)置為5s，而且沒有分別針對連接、讀、寫設(shè)置超時(shí)。后來我們減少超時(shí)時(shí)間，內(nèi)網(wǎng)設(shè)置在150ms以內(nèi)，當(dāng)超時(shí)時(shí)訪問動(dòng)態(tài)服務(wù)。

▌21：應(yīng)對惡意刷的經(jīng)驗(yàn)

商品詳情頁庫存接口2014年被惡意刷，每分鐘超過600w訪問量，tomcat機(jī)器只能定時(shí)重啟;因?yàn)槭窃斍轫撜故镜臄?shù)據(jù)，緩存幾秒鐘是可以接受的，因此開啟nginxproxy cache來解決該問題，開啟后降到正常水平;后來我們使用Nginx+Lua架構(gòu)改造服務(wù)，數(shù)據(jù)過濾、URL重寫等在Nginx層完成，通過URL重寫+一致性哈希負(fù)載均衡，不怕隨機(jī)URL，一些服務(wù)提升了10%+的緩存***率。

▌22：網(wǎng)卡打滿了咋辦?

用Redis都有個(gè)很頭疼的問題,就是Redis的網(wǎng)卡打滿問題,由于Redis的性能很高,在大并發(fā)請求下,很容易將網(wǎng)卡打滿.通常情況下,1臺(tái)服務(wù)器上都會(huì)跑幾十個(gè)Redis實(shí)例 ，一旦網(wǎng)卡打滿,很容易干擾到應(yīng)用層可用性.所以我們基于開源的Contiv netplugin項(xiàng)目，限制了網(wǎng)卡的使用, 主要功能是提供基于Policy的網(wǎng)絡(luò)和存儲(chǔ)管理。Contiv比較“誘人”的一點(diǎn)就是，它的網(wǎng)絡(luò)管理能力，既有L2(VLAN)、L3(BGP)，又有 Overlay(VxLAN)，有了它就可以無視底層的網(wǎng)絡(luò)基礎(chǔ)架構(gòu)，向上層容器提供一致的虛擬網(wǎng)絡(luò)了。最主要的一點(diǎn)是，既滿足了業(yè)務(wù)場景，又兼容了以往的網(wǎng)絡(luò)架構(gòu)。在轉(zhuǎn)發(fā)性能上，它能接近物理網(wǎng)卡的性能，特別在沒有萬兆網(wǎng)絡(luò)的老機(jī)房也能很好的使用。在網(wǎng)絡(luò)流量監(jiān)控方面，我們通過使用ovs的sflow來抓取宿主機(jī)上所有的網(wǎng)絡(luò)流量，然后自開發(fā)了一個(gè)簡單的sflow Collecter, 服務(wù)器收到sflow的數(shù)據(jù)包進(jìn)行解析，篩選出關(guān)鍵數(shù)據(jù)，然后進(jìn)行匯總分析，得到所需要的監(jiān)控?cái)?shù)據(jù)。通過這個(gè)定制的網(wǎng)絡(luò)插件,我們可以隨意的控制某個(gè)Redis的流量,流量過大,也不會(huì)影響其他的項(xiàng)目,而如果某個(gè)服務(wù)器上的Redis流量很低,我們也可以縮小它的配額,提供給本機(jī)其他需要大流量的程序使用,這些,通過后臺(tái)的監(jiān)控程序,可以實(shí)現(xiàn)完全自動(dòng)化。

▌23：緩存組件的選擇

緩存的種類很多，我們實(shí)際使用時(shí)，需要根據(jù)緩存位置(系統(tǒng)前后端)、待存數(shù)據(jù)類型、訪問方式、內(nèi)存效率等情況來選擇最適合的緩存組件。本小節(jié)接下來將主要探討在應(yīng)用層后端如何選擇分布式緩存組件。

一般業(yè)務(wù)系統(tǒng)中，大部分?jǐn)?shù)據(jù)都是簡單KV數(shù)據(jù)類型，如前述微博Feed系統(tǒng)中的feed content、feed列表、用戶信息等。這些簡單類型數(shù)據(jù)只需要進(jìn)行set、get、delete操作，不需要在緩存端做計(jì)算操作，最適合以memcached作為緩存組件。

其次對于需要部分獲取、事物型變更、緩存端計(jì)算的集合類數(shù)據(jù)，擁有豐富數(shù)據(jù)結(jié)構(gòu)和訪問接口的Redis 也許會(huì)更適合。Redis還支持以主從(master-slave)方式進(jìn)行數(shù)據(jù)備份，支持?jǐn)?shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤，重啟時(shí)再次加載使用。因磁盤緩存(diskstore)方式的性能問題，Redis數(shù)據(jù)基本只適合保存在內(nèi)存中，由此帶來的問題是：在某些業(yè)務(wù)場景，如果待緩存的數(shù)據(jù)量特別大，而數(shù)據(jù)的訪問量不太大或者有冷熱區(qū)分，也必須將所有數(shù)據(jù)全部放在內(nèi)存中，緩存成本(特別是機(jī)器成本)會(huì)特別高。如果業(yè)務(wù)遇到這種場景，可以考慮用pika、ssdb等其他緩存組件。pika、ssdb都兼容Redis協(xié)議，同時(shí)采用多線程方案，支持持久化和復(fù)制，單個(gè)緩存實(shí)例可以緩存數(shù)百G的數(shù)據(jù)，其中少部分的熱數(shù)據(jù)存放內(nèi)存，大部分溫?zé)釘?shù)據(jù)或冷數(shù)據(jù)都可以放在磁盤，從而很好的降低緩存成本。

對前面講到的這些后端常用的緩存組件，可以參考下表進(jìn)行選擇。

***，對于對存儲(chǔ)效率、訪問性能等有更高要求的業(yè)務(wù)場景，結(jié)合業(yè)務(wù)特性進(jìn)行緩存組件的定制化設(shè)計(jì)與開發(fā)，也是一個(gè)很好的選擇。

總之，緩存組件的選型要考慮數(shù)據(jù)模型、訪問方式、緩存成本甚至開發(fā)人員的知識(shí)結(jié)構(gòu)，從而進(jìn)行因地制宜的取舍，不要盲目引入不熟悉、不活躍、不成熟的緩存組件，否則中途頻繁調(diào)整緩存方案，會(huì)給開發(fā)進(jìn)度、運(yùn)維成本帶來較大的挑戰(zhàn)。