架構(gòu)成長(zhǎng)之路：分布式緩存架構(gòu)設(shè)計(jì)分析

前言

在高并發(fā)場(chǎng)景下，需要通過(guò)緩存來(lái)減少數(shù)據(jù)庫(kù)的壓力，使得大量的訪問進(jìn)來(lái)能夠命中緩存，只有少量的需要到數(shù)據(jù)庫(kù)層。由于緩存基于內(nèi)存，可支持的并發(fā)量遠(yuǎn)遠(yuǎn)大于基于硬盤的數(shù)據(jù)庫(kù)。所以對(duì)于高并發(fā)設(shè)計(jì)，緩存的設(shè)計(jì)是必不可少的一環(huán)。

在陽(yáng)春等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作 網(wǎng)站設(shè)計(jì)制作按需網(wǎng)站建設(shè),公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),網(wǎng)絡(luò)營(yíng)銷推廣,成都外貿(mào)網(wǎng)站建設(shè),陽(yáng)春網(wǎng)站建設(shè)費(fèi)用合理。

一、為什么要使用緩存

為什么要使用緩存呢？源于人類的一個(gè)夢(mèng)想，就是多快好省的建設(shè)社會(huì)主義。多快好?。亢芏嗫蛻舳歼@么要求，但是作為具體做技術(shù)的你，當(dāng)然知道，好就不能快，多就沒法省。

可是沒辦法，客戶都這樣要求：

這個(gè)能不能便宜一點(diǎn)，你咋這么貴呀，你看人家都很便宜的。(您好，這種打折的房間比較靠里，是不能面向大海的)
你們的性能怎么這么差啊，用你這個(gè)系統(tǒng)跑的這么慢，你看人家廣告中說(shuō)速度能達(dá)到多少多少。(您好，你如果買一個(gè)頂配的，我們也是有這種性能的)
你們服務(wù)不行啊，你就不能彬彬有禮，穿著整齊，送點(diǎn)水果瓜子啥的？(您好，我們蘭州拉面館沒有這項(xiàng)服務(wù)，可以去對(duì)面的俏江南看一下)
這么貴的菜，一盤就這么一點(diǎn)點(diǎn)，都吃不飽，就不能上一大盤么。（您好，對(duì)面的蘭州拉面10塊錢一大碗）
怎么辦呢？勞動(dòng)人民還是很有智慧的，就是聚焦核心需求，讓最最核心的部分享用好和快，而非核心的部門就多和省就可以了。
你可以大部分時(shí)間住在公司旁邊的出租屋里面，但是出去度假的一個(gè)星期，選一個(gè)面朝大海，春暖花開的五星級(jí)酒店。
你可以大部分時(shí)間都擠地鐵，擠公交，跋涉2個(gè)小時(shí)從北五環(huán)到南五環(huán)，但是有急事的時(shí)候，你可以打車，想旅游的時(shí)候，可以租車。
你可以大部分時(shí)間都吃普通的餐館，而朋友來(lái)了，就去高級(jí)飯店里面搓一頓。

在計(jì)算機(jī)世界也是這樣樣子的，如圖所示。

越是快的設(shè)備，存儲(chǔ)量越小，越貴，而越是慢的設(shè)備，存儲(chǔ)量越大，越便宜。

對(duì)于一家電商來(lái)講，我們既希望存儲(chǔ)越來(lái)越多的數(shù)據(jù)，因?yàn)閿?shù)據(jù)將來(lái)就是資產(chǎn)，就是財(cái)富，只有有了數(shù)據(jù)，我們才知道用戶需要什么，同時(shí)又希望當(dāng)我想訪問這些數(shù)據(jù)的時(shí)候，能夠快速的得到，雙十一拼的就是速度和用戶體驗(yàn)，要讓用戶有流暢的感覺。

所以我們要講大量的數(shù)據(jù)都保存下來(lái)，放在便宜的存儲(chǔ)里面，同時(shí)將經(jīng)常訪問的，放在貴的，小的存儲(chǔ)里面，當(dāng)然貴的快的往往比較資源有限，因而不能長(zhǎng)時(shí)間被某些數(shù)據(jù)長(zhǎng)期霸占，所以要大家輪著用，所以叫緩存，也就是暫時(shí)存著。

二、都有哪些類型的緩存

當(dāng)一個(gè)應(yīng)用剛開始的時(shí)候，架構(gòu)比較簡(jiǎn)單，往往就是一個(gè)Tomcat，后面跟著一個(gè)數(shù)據(jù)庫(kù)。

簡(jiǎn)單的應(yīng)用，并發(fā)量不大的時(shí)候，當(dāng)然沒有問題。

然而數(shù)據(jù)庫(kù)相當(dāng)于我們應(yīng)用的中軍大帳，是我們整個(gè)架構(gòu)中最最關(guān)鍵的一部分，也是最不能掛，也最不能會(huì)被攻破的一部分，因而所有對(duì)數(shù)據(jù)庫(kù)的訪問都需要一道屏障來(lái)進(jìn)行保護(hù)，常用的就是緩存。
我們以Tomcat為分界線，之外我們稱為接入層，接入層當(dāng)然應(yīng)該有緩存，還有cdn。
Tomcat之后，我們稱為應(yīng)用層，應(yīng)用層也應(yīng)該有緩存，這是我們這一節(jié)討論的重點(diǎn)。
最簡(jiǎn)單的方式就是Tomcat里面有一層緩存，常稱為本地緩存LocalCache。

這類的緩存常見的有Ehcache和Guava Cache，由于這類緩存在Tomcat本地，因而訪問速度是非常快的。

但是本地緩存有個(gè)比較大的缺點(diǎn)，就是緩存是放在JVM里面的，會(huì)面臨Full GC的問題，一旦出現(xiàn)了FullGC，就會(huì)對(duì)應(yīng)用的性能和相應(yīng)時(shí)間產(chǎn)生影響，當(dāng)然也可以嘗試jemalloc的分配方式。

還有一種方式，就是在Tomcat和MySQL中間加了一層Cache，我們常稱為分布式緩存。

分布式緩存常見的有Memcached和redis，兩者各有優(yōu)缺點(diǎn)。

Memcached適合做簡(jiǎn)單的key-value存儲(chǔ)，內(nèi)存使用率比較高，而且由于是多核處理，對(duì)于比較大的數(shù)據(jù)，性能較好。

但是缺點(diǎn)也比較明顯，Memcached嚴(yán)格來(lái)講沒有集群機(jī)制，橫向擴(kuò)展完全靠客戶端來(lái)實(shí)現(xiàn)。另外Memcached無(wú)法持久化，一旦掛了數(shù)據(jù)就都丟失了，如果想實(shí)現(xiàn)高可用，也是需要客戶端進(jìn)行雙寫才可以。

所以可以看出Memcached真的是設(shè)計(jì)出來(lái)，簡(jiǎn)簡(jiǎn)單單為了做一個(gè)緩存的。

Redis的數(shù)據(jù)結(jié)構(gòu)就豐富的多了，單線程的處理所有的請(qǐng)求，對(duì)于比較大的數(shù)據(jù)，性能稍微差一點(diǎn)。

Redis提供持久化的功能，包括RDB的全量持久化，或者AOF的增量持久化，從而使得Redis掛了，數(shù)據(jù)是有機(jī)會(huì)恢復(fù)的。

Redis提供成熟的主備同步，故障切換的功能，從而保證了高可用性。

所以很多地方管Redis稱為內(nèi)存數(shù)據(jù)庫(kù)，因?yàn)樗囊恍┨匦砸呀?jīng)有了數(shù)據(jù)庫(kù)的影子。

這也是很多人愿意用Redis的原因，集合了緩存和數(shù)據(jù)庫(kù)的優(yōu)勢(shì)，但是往往會(huì)濫用這些優(yōu)勢(shì)，從而忽略了架構(gòu)層面的設(shè)計(jì)，使得Redis集群有很大的風(fēng)險(xiǎn)。

很多情況下，會(huì)將Redis當(dāng)做數(shù)據(jù)庫(kù)使用，開啟持久化和主備同步機(jī)制，以為就可以高枕無(wú)憂了。

然而Redis的持久化機(jī)制，全量持久化則往往需要額外較大的內(nèi)存，而在高并發(fā)場(chǎng)景下，內(nèi)存本來(lái)就很緊張，如果造成swap，就會(huì)影響性能。增量持久化也涉及到寫磁盤和fsync，也是會(huì)拖慢處理的速度，在平時(shí)還好，如果高并發(fā)場(chǎng)景下，仍然會(huì)影響吞吐量。

所以在架構(gòu)設(shè)計(jì)角度，緩存就是緩存，要意識(shí)到數(shù)據(jù)會(huì)隨時(shí)丟失的，要意識(shí)到緩存的存著的目的是攔截到數(shù)據(jù)庫(kù)的請(qǐng)求。如果為了保證緩存的數(shù)據(jù)不丟失，從而影響了緩存的吞吐量，甚至穩(wěn)定性，讓緩存響應(yīng)不過(guò)來(lái)，甚至掛掉，所有的請(qǐng)求擊穿到數(shù)據(jù)庫(kù)，就是更加嚴(yán)重的事情了。

如果非常需要進(jìn)行持久化，可以考慮使用levelDB此類的，對(duì)于隨機(jī)寫入性能較好的key-value持久化存儲(chǔ)，這樣只有部分的確需要持久化的數(shù)據(jù)，才進(jìn)行持久化，而非無(wú)論什么數(shù)據(jù)，通通往Redis里面扔，同時(shí)統(tǒng)一開啟了持久化。

三、基于緩存的架構(gòu)設(shè)計(jì)要點(diǎn)

所以基于緩存的設(shè)計(jì)：

1、多層次

這樣某一層的緩存掛了，還有另一層可以撐著，等待緩存的修復(fù)，例如分布式緩存因?yàn)槟撤N原因掛了，因?yàn)槌志没脑?，同步機(jī)制的原因，內(nèi)存過(guò)大的原因等，修復(fù)需要一段時(shí)間，在這段時(shí)間內(nèi)，至少本地緩存可以抗一陣，不至于一下子就擊穿數(shù)據(jù)庫(kù)。而且對(duì)于特別特別熱的數(shù)據(jù)，熱到導(dǎo)致集中式的緩存處理不過(guò)來(lái)，網(wǎng)卡也被打滿的情況，由于本地緩存不需要遠(yuǎn)程調(diào)用，也是分布在應(yīng)用層的，可以緩解這種問題。

2、分場(chǎng)景

到底要解決什么問題，可以選擇不同的緩存。是要存儲(chǔ)大的無(wú)格式的數(shù)據(jù)，還是要存儲(chǔ)小的有格式的數(shù)據(jù)，還是要存儲(chǔ)一定需要持久化的數(shù)據(jù)。具體的場(chǎng)景下一節(jié)詳細(xì)談。

3、要分片

使得每一個(gè)緩存實(shí)例都不大，但是實(shí)例數(shù)目比較多，這樣一方面可以實(shí)現(xiàn)負(fù)載均衡，防止單個(gè)實(shí)例稱為瓶頸或者熱點(diǎn)，另一方面如果一個(gè)實(shí)例掛了，影響面會(huì)小很多，高可用性大大增強(qiáng)。分片的機(jī)制可以在客戶端實(shí)現(xiàn)，可以使用中間件實(shí)現(xiàn)，也可以使用Redis的Cluster的方式，分片的算法往往都是哈希取模，或者一致性哈希。

四、緩存的使用場(chǎng)景

當(dāng)你的應(yīng)用扛不住，知道要使用緩存了，應(yīng)該怎么做呢？

場(chǎng)景1：和數(shù)據(jù)庫(kù)中的數(shù)據(jù)結(jié)構(gòu)保持一致，原樣緩存
這種場(chǎng)景是最常見的場(chǎng)景，也是很多架構(gòu)使用緩存的適合，最先涉及到的場(chǎng)景。

基本就是數(shù)據(jù)庫(kù)里面啥樣，我緩存也啥樣，數(shù)據(jù)庫(kù)里面有商品信息，緩存里面也放商品信息，唯一不同的是，數(shù)據(jù)庫(kù)里面是全量的商品信息，緩存里面是最熱的商品信息。

每當(dāng)應(yīng)用要查詢商品信息的時(shí)候，先查緩存，緩存沒有就查數(shù)據(jù)庫(kù)，查出來(lái)的結(jié)果放入緩存，從而下次就查到了。

這個(gè)是緩存最最經(jīng)典的更新流程。這種方式簡(jiǎn)單，直觀，很多緩存的庫(kù)都默認(rèn)支持這種方式。

場(chǎng)景2：列表排序分頁(yè)場(chǎng)景的緩存

有時(shí)候我們需要獲得一些列表數(shù)據(jù)，并對(duì)這些數(shù)據(jù)進(jìn)行排序和分頁(yè)。

例如我們想獲取點(diǎn)贊最多的評(píng)論，或者最新的評(píng)論，然后列出來(lái)，一頁(yè)一頁(yè)的翻下去。

在這種情況下，緩存里面的數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)庫(kù)里面完全不一樣。

如果完全使用數(shù)據(jù)庫(kù)進(jìn)行實(shí)現(xiàn)，則按照某種條件將所有的行查詢出來(lái)，然后按照某個(gè)字段進(jìn)行排序，然后進(jìn)行分頁(yè)，一頁(yè)一頁(yè)的展示。

但是當(dāng)數(shù)據(jù)量比較大的時(shí)候，這種方式往往成為瓶頸，首先涉及的數(shù)據(jù)庫(kù)行數(shù)比較多，而且排序也是個(gè)很慢的活，盡管可能有索引，分頁(yè)也是翻頁(yè)到最后，越是慢。

在緩存里面，就沒必要每行一個(gè)key了，而是可以使用Redis的列表方式進(jìn)行存儲(chǔ)，當(dāng)然列表的長(zhǎng)短是有限制的，肯定放不下數(shù)據(jù)庫(kù)里面這么多，但是大家會(huì)發(fā)現(xiàn)其實(shí)對(duì)于所有的列表，用戶往往沒有耐心看個(gè)十頁(yè)八頁(yè)的，例如百度上搜個(gè)東西，也是有排序和分頁(yè)的，但是你每次都往后翻了嗎，每頁(yè)就十條，就算是十頁(yè)，或者一百頁(yè)，也就一千條數(shù)據(jù)，如果保持ID的話，完全放的下。

如果已經(jīng)排好序，放在Redis里面，那取出列表，翻頁(yè)就非?？炝?。

可以后臺(tái)有一個(gè)線程，異步的初始化和刷新緩存，在緩存里面保存一個(gè)時(shí)間戳，當(dāng)有更新的時(shí)候，刷新時(shí)間戳，異步任務(wù)發(fā)現(xiàn)時(shí)間戳改變了，就刷新緩存。

場(chǎng)景3：計(jì)數(shù)緩存
計(jì)數(shù)對(duì)于數(shù)據(jù)庫(kù)來(lái)講，是一個(gè)非常繁重的工作，需要查詢大量的行，最后得出計(jì)數(shù)的結(jié)論，當(dāng)數(shù)據(jù)改變的時(shí)候，需要重新刷一遍，非常影響性能。

因此可以有一個(gè)計(jì)數(shù)服務(wù)，后端是一個(gè)緩存，將計(jì)數(shù)作為結(jié)果放在緩存里面，當(dāng)數(shù)據(jù)有改變的時(shí)候，調(diào)用計(jì)數(shù)服務(wù)增加或者減少計(jì)數(shù)，而非通過(guò)異步數(shù)據(jù)庫(kù)count來(lái)更新緩存。

計(jì)數(shù)服務(wù)可以使用Redis進(jìn)行單個(gè)計(jì)數(shù)，或者h(yuǎn)ash表進(jìn)行批量計(jì)數(shù)

場(chǎng)景4：重構(gòu)維度緩存

有時(shí)候數(shù)據(jù)庫(kù)里面保持的數(shù)據(jù)的維度是為了寫入方便，而非為了查詢方便的，然而同時(shí)查詢過(guò)程，也需要處理高并發(fā)，因而需要為了查詢方便，將數(shù)據(jù)重新以另一個(gè)維度存儲(chǔ)一遍，或者說(shuō)將多給數(shù)據(jù)庫(kù)的內(nèi)容聚合一下，再存儲(chǔ)一遍，從而不用每次查詢的時(shí)候都重新聚合，如果還是放在數(shù)據(jù)庫(kù)，比較難維護(hù)，放在緩存就好一些。

例如一個(gè)商品的所有的帖子和帖子的用戶，以及一個(gè)用戶發(fā)表過(guò)的所有的帖子就是屬于兩個(gè)維度。

這需要寫入一個(gè)維度的時(shí)候，同時(shí)異步通知，更新緩存中的另一個(gè)維度。

在這種場(chǎng)景下，數(shù)據(jù)量相對(duì)比較大，因而單純用內(nèi)存緩存memcached或者redis難以支撐，往往會(huì)選擇使用levelDB進(jìn)行存儲(chǔ)，如果levelDB的性能跟不上，可以考慮在levelDB之前，再來(lái)一層memcached。

場(chǎng)景5：較大的詳情內(nèi)容數(shù)據(jù)緩存
對(duì)于評(píng)論的詳情，或者帖子的詳細(xì)內(nèi)容，屬于非結(jié)構(gòu)化的，而且內(nèi)容比較大，因而使用memcached比較好。

五、緩存三大矛盾問題

1、緩存實(shí)時(shí)性和一致性問題：當(dāng)有了寫入后咋辦？

雖然使用了緩存，大家心里都有一個(gè)預(yù)期，就是實(shí)時(shí)性和一致性得不到完全的保證，畢竟數(shù)據(jù)保存了多份，數(shù)據(jù)庫(kù)一份，緩存中一份，當(dāng)數(shù)據(jù)庫(kù)中因?qū)懭攵a(chǎn)生了新的數(shù)據(jù)，往往緩存是不會(huì)和數(shù)據(jù)庫(kù)操作放在一個(gè)事務(wù)里面的，如何將新的數(shù)據(jù)更新到緩存里面，什么時(shí)候更新到緩存里面，不同的策略不一樣。

從用戶體驗(yàn)角度，當(dāng)然是越實(shí)時(shí)越好，用戶體驗(yàn)越流暢，完全從這個(gè)角度出發(fā)，就應(yīng)該有了寫入，馬上廢棄緩存，觸發(fā)一次數(shù)據(jù)庫(kù)的讀取，從而更新緩存。但是這和第三個(gè)問題，高并發(fā)就矛盾了，如果所有的都實(shí)時(shí)從數(shù)據(jù)庫(kù)里面讀取，高并發(fā)場(chǎng)景下，數(shù)據(jù)庫(kù)往往受不了。

2、緩存的穿透問題：當(dāng)沒有讀到咋辦？

為什么會(huì)出現(xiàn)緩存讀取不到的情況呢？

第一：可能讀取的是冷數(shù)據(jù)，原來(lái)從來(lái)沒有訪問過(guò)，所以需要到數(shù)據(jù)庫(kù)里面查詢一下，然后放入緩存，再返回給客戶。

第二：可能數(shù)據(jù)因?yàn)橛辛藢懭?，被?shí)時(shí)的從緩存中刪除了，就如第一個(gè)問題中描述的那樣，為了保證實(shí)時(shí)性，當(dāng)數(shù)據(jù)庫(kù)中的數(shù)據(jù)更新了之后，馬上刪除緩存中的數(shù)據(jù)，導(dǎo)致這個(gè)時(shí)候的讀取讀不到，需要到數(shù)據(jù)庫(kù)里面查詢后，放入緩存，再返回給客戶。

第三：可能是緩存實(shí)效了，每個(gè)緩存數(shù)據(jù)都會(huì)有實(shí)效時(shí)間，過(guò)了一段時(shí)間沒有被訪問，就會(huì)失效，這個(gè)時(shí)候數(shù)據(jù)就訪問不到了，需要訪問數(shù)據(jù)庫(kù)后，再放入緩存。

第四：數(shù)據(jù)被換出，由于緩存內(nèi)存是有限的，當(dāng)使用快滿了的時(shí)候，就會(huì)使用類似LRU策略，將不經(jīng)常使用的數(shù)據(jù)換出，所以也要訪問數(shù)據(jù)庫(kù)。

第五：后端確實(shí)也沒有，應(yīng)用訪問緩存沒有，于是查詢數(shù)據(jù)庫(kù)，結(jié)果數(shù)據(jù)庫(kù)里面也沒有，只好返回客戶為空，但是尷尬的是，每次出現(xiàn)這種情況的時(shí)候，都會(huì)面臨著一次數(shù)據(jù)庫(kù)的訪問，純屬浪費(fèi)資源，常用的方法是，講這個(gè)key對(duì)應(yīng)的結(jié)果為空的事實(shí)也進(jìn)行緩存，這樣緩存可以命中，但是命中后告訴客戶端沒有，減少了數(shù)據(jù)庫(kù)的壓力。

無(wú)論哪種原因?qū)е碌淖x取緩存讀不到的情況，該怎么辦？是個(gè)策略問題。

一種是同步訪問數(shù)據(jù)庫(kù)后，放入緩存，再返回給客戶，這樣實(shí)時(shí)性最好，但是給數(shù)據(jù)庫(kù)的壓力也最大。

另一種方式就是異步的訪問數(shù)據(jù)庫(kù)，暫且返回客戶一個(gè)fallback值，然后同時(shí)觸發(fā)一個(gè)異步更新，這樣下次就有了，這樣數(shù)據(jù)庫(kù)壓力小很多，但是用戶就訪問不到實(shí)時(shí)的數(shù)據(jù)了。

3、緩存對(duì)數(shù)據(jù)庫(kù)高并發(fā)訪問：都來(lái)訪問數(shù)據(jù)庫(kù)咋辦？

我們本來(lái)使用緩存，是來(lái)攔截直接訪問數(shù)據(jù)庫(kù)請(qǐng)求的，從而保證數(shù)據(jù)庫(kù)大本營(yíng)永遠(yuǎn)處于健康的狀態(tài)。但是如果一遇到不命中，就訪問數(shù)據(jù)庫(kù)的話，平時(shí)沒有什么問題，但是大促情況下，數(shù)據(jù)庫(kù)是受不了的。

一種情況是多個(gè)客戶端，并發(fā)狀態(tài)下，都不命中了，于是并發(fā)的都來(lái)訪問數(shù)據(jù)庫(kù)，其實(shí)只需要訪問一次就好，這種情況可以通過(guò)加鎖，只有一個(gè)到后端來(lái)實(shí)現(xiàn)。

另外就是即便采取了上述的策略，依然并發(fā)量非常大，后端的數(shù)據(jù)庫(kù)依然受不了，則需要通過(guò)降低實(shí)時(shí)性，將緩存攔在數(shù)據(jù)庫(kù)前面，暫且撐住，來(lái)解決。

六、解決緩存三大矛盾的刷新策略

1、實(shí)時(shí)策略

所謂的實(shí)時(shí)策略，是平時(shí)緩存使用的最常用的策略，也是保持實(shí)時(shí)性最好的策略。

讀取的過(guò)程，應(yīng)用程序先從cache取數(shù)據(jù)，沒有得到，則從數(shù)據(jù)庫(kù)中取數(shù)據(jù)，成功后，放到緩存中。如果命中，應(yīng)用程序從cache中取數(shù)據(jù)，取到后返回。

寫入的過(guò)程，把數(shù)據(jù)存到數(shù)據(jù)庫(kù)中，成功后，再讓緩存失效，失效后下次讀取的時(shí)候，會(huì)被寫入緩存。那為什么不直接寫緩存呢？因?yàn)槿绻麅蓚€(gè)線程同時(shí)更新數(shù)據(jù)庫(kù)，一個(gè)將數(shù)據(jù)庫(kù)改為10，一個(gè)將數(shù)據(jù)庫(kù)改為20，數(shù)據(jù)庫(kù)有自己的事務(wù)機(jī)制，可以保證如果20是后提交的，數(shù)據(jù)庫(kù)里面改為20，但是回過(guò)頭來(lái)寫入緩存的時(shí)候就沒有事務(wù)了，如果改為20的線程先更新緩存，改為10的線程后更新緩存，于是就會(huì)長(zhǎng)時(shí)間出現(xiàn)緩存中是10，但是數(shù)據(jù)庫(kù)中是20的現(xiàn)象。

這種方式實(shí)時(shí)性好，用戶體驗(yàn)好，是默認(rèn)應(yīng)該使用的策略。

2、異步策略

所謂異步策略，就是當(dāng)讀取的時(shí)候讀不到的時(shí)候，不直接訪問數(shù)據(jù)庫(kù)，而是返回一個(gè)fallback數(shù)據(jù)，然后往消息隊(duì)列里面放入一個(gè)數(shù)據(jù)加載的事件，在背后有一個(gè)任務(wù)，收到事件后，會(huì)異步的讀取數(shù)據(jù)庫(kù)，由于有隊(duì)列的作用，可以實(shí)現(xiàn)消峰，緩沖對(duì)數(shù)據(jù)庫(kù)的訪問，甚至可以將多個(gè)隊(duì)列中的任務(wù)合并請(qǐng)求，合并更新緩存，提高了效率。

當(dāng)更新的時(shí)候，異步策略總是先更新數(shù)據(jù)庫(kù)和緩存中的一個(gè)，然后異步的更新另一個(gè)。

一是先更新數(shù)據(jù)庫(kù)，然后異步更新緩存。當(dāng)數(shù)據(jù)庫(kù)更新后，同樣生成一個(gè)異步消息，放入消息隊(duì)列中，等待背后的任務(wù)通過(guò)消息進(jìn)行緩存更新，同樣可以實(shí)現(xiàn)消峰和任務(wù)合并。缺點(diǎn)就是實(shí)時(shí)性比較差，估計(jì)要過(guò)一段時(shí)間才能看到更新，好處是數(shù)據(jù)持久性可以得到保證。

一是先更新緩存，然后異步更新數(shù)據(jù)庫(kù)。這種方式讀取和寫入都用緩存，將緩存完全擋在了數(shù)據(jù)庫(kù)的前面，把緩存當(dāng)成了數(shù)據(jù)庫(kù)在用。所以一般會(huì)使用有持久化機(jī)制和主備的redis，但是仍然不能保證緩存不丟數(shù)據(jù)，所以這種情況適用于并發(fā)量大，但是數(shù)據(jù)沒有那么關(guān)鍵的情況，好處是實(shí)時(shí)性好。

在實(shí)時(shí)策略扛不住大促的時(shí)候，可以根據(jù)場(chǎng)景，切換到上面的兩種模式的一個(gè)，算是降級(jí)策略。

3、定時(shí)策略

如果并發(fā)量實(shí)在太大，數(shù)據(jù)量也大的情況，異步都難以滿足，可以降級(jí)為定時(shí)刷新的策略，這種情況下，應(yīng)用只訪問緩存，不訪問數(shù)據(jù)庫(kù)，更新頻率也不高，而且用戶要求也不高，例如詳情，評(píng)論等。

這種情況下，由于數(shù)據(jù)量比較大，建議將一整塊數(shù)據(jù)拆分成幾部分進(jìn)行緩存，而且區(qū)分更新頻繁的和不頻繁的，這樣不用每次更新的時(shí)候，所有的都更新，只更新一部分。并且緩存的時(shí)候，可以進(jìn)行數(shù)據(jù)的預(yù)整合，因?yàn)閷?shí)時(shí)性不高，讀取預(yù)整合的數(shù)據(jù)更快。
###最后
大家覺得不錯(cuò)可以點(diǎn)個(gè)贊在關(guān)注下，以后還會(huì)分享更多文章！

文章名稱：架構(gòu)成長(zhǎng)之路：分布式緩存架構(gòu)設(shè)計(jì)分析
本文路徑：http://muchs.cn/article2/ihshic.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網(wǎng)站、營(yíng)銷型網(wǎng)站建設(shè)、App開發(fā)、品牌網(wǎng)站制作、網(wǎng)站建設(shè)、軟件開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)