此文已由作者劉超授權(quán)網(wǎng)易云社區(qū)發(fā)布。

歡迎訪問網(wǎng)易云社區(qū)，了解更多網(wǎng)易技術(shù)產(chǎn)品運(yùn)營經(jīng)驗(yàn)。

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

一、為什么要使用緩存

為什么要使用緩存呢？源于人類的一個(gè)夢想，就是多快好省的建設(shè)社會(huì)主義。

多快好省？很多客戶都這么要求，但是作為具體做技術(shù)的你，當(dāng)然知道，好就不能快，多就沒法省。

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

這個(gè)能不能便宜一點(diǎn)，你咋這么貴呀，你看人家都很便宜的。(您好，這種打折的房間比較靠里，是不能面向大海的)

你們的性能怎么這么差啊，用你這個(gè)系統(tǒng)跑的這么慢，你看人家廣告中說速度能達(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í)間都吃普通的餐館，而朋友來了，就去高級(jí)飯店里面搓一頓。

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

?

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

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

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

二、都有哪些類型的緩存

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

?

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

然而數(shù)據(jù)庫相當(dāng)于我們應(yīng)用的中軍大帳，是我們整個(gè)架構(gòu)中最最關(guān)鍵的一部分，也是最不能掛，也最不能會(huì)被攻破的一部分，因而所有對(duì)數(shù)據(jù)庫的訪問都需要一道屏障來進(jìn)行保護(hù)，常用的就是緩存。

我們以Tomcat為分界線，之外我們稱為接入層，接入層當(dāng)然應(yīng)該有緩存，還有CDN，這個(gè)在這篇文章中有詳細(xì)的描述，微服務(wù)的接入層設(shè)計(jì)與動(dòng)靜資源隔離

Tomcat之后，我們稱為應(yīng)用層，應(yīng)用層也應(yīng)該有緩存，這是我們這一節(jié)討論的重點(diǎ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適合做簡單的key-value存儲(chǔ)，內(nèi)存使用率比較高，而且由于是多核處理，對(duì)于比較大的數(shù)據(jù)，性能較好。

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

所以可以看出Memcached真的是設(shè)計(jì)出來，簡簡單單為了做一個(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ù)庫，因?yàn)樗囊恍┨匦砸呀?jīng)有了數(shù)據(jù)庫的影子。

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

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

?

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

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

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

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

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

1、多層次

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

2、分場景

到底要解決什么問題，可以選擇不同的緩存。是要存儲(chǔ)大的無格式的數(shù)據(jù)，還是要存儲(chǔ)小的有格式的數(shù)據(jù)，還是要存儲(chǔ)一定需要持久化的數(shù)據(jù)。具體的場景下一節(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的方式，分片的算法往往都是哈希取模，或者一致性哈希。

四、緩存的使用場景

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

場景1：和數(shù)據(jù)庫中的數(shù)據(jù)結(jié)構(gòu)保持一致，原樣緩存

這種場景是最常見的場景，也是很多架構(gòu)使用緩存的適合，最先涉及到的場景。

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

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

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

場景2：列表排序分頁場景的緩存

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

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

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

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

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

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

如果已經(jīng)排好序，放在Redis里面，那取出列表，翻頁就非常快了。

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

場景3：計(jì)數(shù)緩存

計(jì)數(shù)對(duì)于數(shù)據(jù)庫來講，是一個(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ù)，而非通過異步數(shù)據(jù)庫count來更新緩存。

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

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

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

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

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

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

場景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ù)庫一份，緩存中一份，當(dāng)數(shù)據(jù)庫中因?qū)懭攵a(chǎn)生了新的數(shù)據(jù)，往往緩存是不會(huì)和數(shù)據(jù)庫操作放在一個(gè)事務(wù)里面的，如何將新的數(shù)據(jù)更新到緩存里面，什么時(shí)候更新到緩存里面，不同的策略不一樣。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2、異步策略

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

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

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

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

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

3、定時(shí)策略

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

這種情況下，由于數(shù)據(jù)量比較大，建議將一整塊數(shù)據(jù)拆分成幾部分進(jìn)行緩存，而且區(qū)分更新頻繁的和不頻繁的，這樣不用每次更新的時(shí)候，所有的都更新，只更新一部分。并且緩存的時(shí)候，可以進(jìn)行數(shù)據(jù)的預(yù)整合，因?yàn)閷?shí)時(shí)性不高，讀取預(yù)整合的數(shù)據(jù)更快。

網(wǎng)易云計(jì)算基礎(chǔ)服務(wù)深度整合了 IaaS、PaaS 及容器技術(shù)，提供彈性計(jì)算、DevOps 工具鏈及微服務(wù)基礎(chǔ)設(shè)施等服務(wù)，幫助企業(yè)解決 IT、架構(gòu)及運(yùn)維等問題，使企業(yè)更聚焦于業(yè)務(wù)，是新一代的云計(jì)算平臺(tái)，點(diǎn)擊可免費(fèi)試用。

免費(fèi)體驗(yàn)云安全(易盾)內(nèi)容安全、驗(yàn)證碼等服務(wù)

更多網(wǎng)易技術(shù)、產(chǎn)品、運(yùn)營經(jīng)驗(yàn)分享請(qǐng)點(diǎn)擊。

相關(guān)文章：
【推薦】?Google準(zhǔn)實(shí)時(shí)數(shù)據(jù)倉庫Mesa（一）

總結(jié)

以上是生活随笔為你收集整理的微服务化之缓存的设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。