前言

緩存技術(shù)存在于應(yīng)用場景的方方面面。從瀏覽器請求，到反向代理服務(wù)器，從進(jìn)程內(nèi)緩存到分布式緩存。其中緩存策略，算法也是層出不窮，今天就帶大家走進(jìn)緩存。緩存對于每個(gè)開發(fā)者來說是相當(dāng)熟悉了，為了提高程序的性能我們會去加緩存，但是在什么地方加緩存，如何加緩存呢？

假設(shè)一個(gè)網(wǎng)站，需要提高性能，緩存可以放在瀏覽器，可以放在反向代理服務(wù)器，還可以放在應(yīng)用程序進(jìn)程內(nèi)，同時(shí)可以放在分布式緩存系統(tǒng)中。

從用戶請求數(shù)據(jù)到數(shù)據(jù)返回，數(shù)據(jù)經(jīng)過了瀏覽器，CDN，代理服務(wù)器，應(yīng)用服務(wù)器，以及數(shù)據(jù)庫各個(gè)環(huán)節(jié)。每個(gè)環(huán)節(jié)都可以運(yùn)用緩存技術(shù)。

從瀏覽器/客戶端開始請求數(shù)據(jù)，通過 HTTP 配合 CDN 獲取數(shù)據(jù)的變更情況，到達(dá)代理服務(wù)器（Nginx）可以通過反向代理獲取靜態(tài)資源。

再往下來到應(yīng)用服務(wù)器可以通過進(jìn)程內(nèi)（堆內(nèi)）緩存，分布式緩存等遞進(jìn)的方式獲取數(shù)據(jù)。如果以上所有緩存都沒有命中數(shù)據(jù)，才會回源到數(shù)據(jù)庫。

緩存的請求順序是：用戶請求 → HTTP 緩存 → CDN 緩存 → 代理服務(wù)器緩存 → 進(jìn)程內(nèi)緩存 → 分布式緩存 → 數(shù)據(jù)庫。

看來在技術(shù)的架構(gòu)每個(gè)環(huán)節(jié)都可以加入緩存，看看每個(gè)環(huán)節(jié)是如何應(yīng)用緩存技術(shù)的。

1. HTTP緩存

當(dāng)用戶通過瀏覽器請求服務(wù)器的時(shí)候，會發(fā)起 HTTP 請求，如果對每次 HTTP 請求進(jìn)行緩存，那么可以減少應(yīng)用服務(wù)器的壓力。

當(dāng)?shù)谝淮握埱蟮臅r(shí)候，瀏覽器本地緩存庫沒有緩存數(shù)據(jù)，會從服務(wù)器取數(shù)據(jù)，并且放到瀏覽器的緩存庫中，下次再進(jìn)行請求的時(shí)候會根據(jù)緩存的策略來讀取本地或者服務(wù)的信息。

一般信息的傳遞通過 HTTP 請求頭 Header 來傳遞。目前比較常見的緩存方式有兩種，分別是：

強(qiáng)制緩存

對比緩存

1.1. 強(qiáng)制緩存

當(dāng)瀏覽器本地緩存庫保存了緩存信息，在緩存數(shù)據(jù)未失效的情況下，可以直接使用緩存數(shù)據(jù)。否則就需要重新獲取數(shù)據(jù)。

這種緩存機(jī)制看上去比較直接，那么如何判斷緩存數(shù)據(jù)是否失效呢？這里需要關(guān)注 HTTP Header 中的兩個(gè)字段 Expires 和 Cache-Control。

Expires 為服務(wù)端返回的過期時(shí)間，客戶端第一次請求服務(wù)器，服務(wù)器會返回資源的過期時(shí)間。如果客戶端再次請求服務(wù)器，會把請求時(shí)間與過期時(shí)間做比較。

如果請求時(shí)間小于過期時(shí)間，那么說明緩存沒有過期，則可以直接使用本地緩存庫的信息。

反之，說明數(shù)據(jù)已經(jīng)過期，必須從服務(wù)器重新獲取信息，獲取完畢又會更新最新的過期時(shí)間。

這種方式在 HTTP 1.0 用的比較多，到了 HTTP 1.1 會使用 Cache-Control 替代。

Cache-Control 中有個(gè) max-age 屬性，單位是秒，用來表示緩存內(nèi)容在客戶端的過期時(shí)間。

例如：max-age 是 60 秒，當(dāng)前緩存沒有數(shù)據(jù)，客戶端第一次請求完后，將數(shù)據(jù)放入本地緩存。

那么在 60 秒以內(nèi)客戶端再發(fā)送請求，都不會請求應(yīng)用服務(wù)器，而是從本地緩存中直接返回?cái)?shù)據(jù)。如果兩次請求相隔時(shí)間超過了 60 秒，那么就需要通過服務(wù)器獲取數(shù)據(jù)。

1.2. 對比緩存

需要對比前后兩次的緩存標(biāo)志來判斷是否使用緩存。瀏覽器第一次請求時(shí)，服務(wù)器會將緩存標(biāo)識與數(shù)據(jù)一起返回，瀏覽器將二者備份至本地緩存庫中。瀏覽器再次請求時(shí)，將備份的緩存標(biāo)識發(fā)送給服務(wù)器。

服務(wù)器根據(jù)緩存標(biāo)識進(jìn)行判斷，如果判斷數(shù)據(jù)沒有發(fā)生變化，把判斷成功的 304 狀態(tài)碼發(fā)給瀏覽器。

這時(shí)瀏覽器就可以使用緩存的數(shù)據(jù)來。服務(wù)器返回的就只是 Header，不包含 Body。

下面介紹兩種標(biāo)識規(guī)則：

1.2.1. Last-Modified/If-Modified-Since 規(guī)則

在客戶端第一次請求的時(shí)候，服務(wù)器會返回資源最后的修改時(shí)間，記作 Last-Modified?？蛻舳藢⑦@個(gè)字段連同資源緩存起來。

Last-Modified 被保存以后，在下次請求時(shí)會以 Last-Modified-Since 字段被發(fā)送。

當(dāng)客戶端再次請求服務(wù)器時(shí)，會把 Last-Modified 連同請求的資源一起發(fā)給服務(wù)器，這時(shí) Last-Modified 會被命名為 If-Modified-Since，存放的內(nèi)容都是一樣的。

服務(wù)器收到請求，會把 If-Modified-Since 字段與服務(wù)器上保存的 Last-Modified 字段作比較：

若服務(wù)器上的 Last-Modified 最后修改時(shí)間大于請求的 If-Modified-Since，說明資源被改動過，就會把資源（包括 Header+Body）重新返回給瀏覽器，同時(shí)返回狀態(tài)碼 200。

若資源的最后修改時(shí)間小于或等于 If-Modified-Since，說明資源沒有改動過，只會返回 Header，并且返回狀態(tài)碼 304。瀏覽器接受到這個(gè)消息就可以使用本地緩存庫的數(shù)據(jù)。

注意：Last-Modified 和 If-Modified-Since 指的是同一個(gè)值，只是在客戶端和服務(wù)器端的叫法不同。

1.2.2. ETag / If-None-Match 規(guī)則

客戶端第一次請求的時(shí)候，服務(wù)器會給每個(gè)資源生成一個(gè) ETag 標(biāo)記。這個(gè) ETag 是根據(jù)每個(gè)資源生成的唯一 Hash 串，資源如何發(fā)生變化 ETag 隨之更改，之后將這個(gè) ETag 返回給客戶端，客戶端把請求的資源和 ETag 都緩存到本地。

ETag 被保存以后，在下次請求時(shí)會當(dāng)作 If-None-Match 字段被發(fā)送出去。

在瀏覽器第二次請求服務(wù)器相同資源時(shí)，會把資源對應(yīng)的 ETag 一并發(fā)送給服務(wù)器。在請求時(shí) ETag 轉(zhuǎn)化成 If-None-Match，但其內(nèi)容不變。

服務(wù)器收到請求后，會把 If-None-Match 與服務(wù)器上資源的 ETag 進(jìn)行比較：

如果不一致，說明資源被改動過，則返回資源（Header+Body），返回狀態(tài)碼 200。

如果一致，說明資源沒有被改過，則返回 Header，返回狀態(tài)碼 304。瀏覽器接受到這個(gè)消息就可以使用本地緩存庫的數(shù)據(jù)。

注意：ETag 和 If-None-Match 指的是同一個(gè)值，只是在客戶端和服務(wù)器端的叫法不同。

2. CDN 緩存

HTTP 緩存主要是對靜態(tài)數(shù)據(jù)進(jìn)行緩存，把從服務(wù)器拿到的數(shù)據(jù)緩存到客戶端/瀏覽器。

如果在客戶端和服務(wù)器之間再加上一層 CDN，可以讓 CDN 為應(yīng)用服務(wù)器提供緩存，如果在 CDN 上緩存，就不用再請求應(yīng)用服務(wù)器了。并且 HTTP 緩存提到的兩種策略同樣可以在 CDN 服務(wù)器執(zhí)行。

CDN 的全稱是 Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。

讓我們來看看它是如何工作的吧：

客戶端發(fā)送 URL 給 DNS 服務(wù)器。

DNS 通過域名解析，把請求指向 CDN 網(wǎng)絡(luò)中的 DNS 負(fù)載均衡器。

DNS 負(fù)載均衡器將最近 CDN 節(jié)點(diǎn)的 IP 告訴 DNS，DNS 告之客戶端最新 CDN 節(jié)點(diǎn)的 IP。

客戶端請求最近的 CDN 節(jié)點(diǎn)。

CDN 節(jié)點(diǎn)從應(yīng)用服務(wù)器獲取資源返回給客戶端，同時(shí)將靜態(tài)信息緩存。注意：客戶端下次互動的對象就是 CDN 緩存了，CDN 可以和應(yīng)用服務(wù)器同步緩存信息。

CDN 接受客戶端的請求，它就是離客戶端最近的服務(wù)器，它后面會鏈接多臺服務(wù)器，起到了緩存和負(fù)載均衡的作用。

3. 負(fù)載均衡緩存

說完客戶端（HTTP）緩存和 CDN 緩存，我們離應(yīng)用服務(wù)越來越近了，在到達(dá)應(yīng)用服務(wù)之前，請求還要經(jīng)過負(fù)載均衡器。

雖說它的主要工作是對應(yīng)用服務(wù)器進(jìn)行負(fù)載均衡，但是它也可以作緩存?？梢园岩恍┬薷念l率不高的數(shù)據(jù)緩存在這里，例如：用戶信息，配置信息。通過服務(wù)定期刷新這個(gè)緩存就行了。

以 Nginx 為例，我們看看它是如何工作的：

用戶請求在達(dá)到應(yīng)用服務(wù)器之前，會先訪問 Nginx 負(fù)載均衡器，如果發(fā)現(xiàn)有緩存信息，直接返回給用戶。

如果沒有發(fā)現(xiàn)緩存信息，Nginx 回源到應(yīng)用服務(wù)器獲取信息。

另外，有一個(gè)緩存更新服務(wù)，定期把應(yīng)用服務(wù)器中相對穩(wěn)定的信息更新到 Nginx 本地緩存中。

4. 進(jìn)程內(nèi)緩存

通過了客戶端，CDN，負(fù)載均衡器，我們終于來到了應(yīng)用服務(wù)器。應(yīng)用服務(wù)器上部署著一個(gè)個(gè)應(yīng)用，這些應(yīng)用以進(jìn)程的方式運(yùn)行著，那么在進(jìn)程中的緩存是怎樣的呢？

進(jìn)程內(nèi)緩存又叫托管堆緩存，以 Java 為例，這部分緩存放在 JVM 的托管堆上面，同時(shí)會受到托管堆回收算法的影響。

由于其運(yùn)行在內(nèi)存中，對數(shù)據(jù)的響應(yīng)速度很快，通常我們會把熱點(diǎn)數(shù)據(jù)放在這里。

在進(jìn)程內(nèi)緩存沒有命中的時(shí)候，我們會去搜索進(jìn)程外的緩存或者分布式緩存。這種緩存的好處是沒有序列化和反序列化，是最快的緩存。缺點(diǎn)是緩存的空間不能太大，對垃圾回收器的性能有影響。

目前比較流行的實(shí)現(xiàn)有 Ehcache、GuavaCache、Caffeine。這些架構(gòu)可以很方便的把一些熱點(diǎn)數(shù)據(jù)放到進(jìn)程內(nèi)的緩存中。

這里我們需要關(guān)注幾個(gè)緩存的回收策略，具體的實(shí)現(xiàn)架構(gòu)的回收策略會有所不同，但大致的思路都是一致的：

FIFO（First In First Out）：先進(jìn)先出算法，最先放入緩存的數(shù)據(jù)最先被移除。

LRU（Least Recently Used）：最近最少使用算法，把最久沒有使用過的數(shù)據(jù)移除緩存。

LFU（Least Frequently Used）：最不常用算法，在一段時(shí)間內(nèi)使用頻率最小的數(shù)據(jù)被移除緩存。

在分布式架構(gòu)的今天，多應(yīng)用中如果采用進(jìn)程內(nèi)緩存會存在數(shù)據(jù)一致性的問題。

這里推薦兩個(gè)方案：

消息隊(duì)列修改方案

Timer 修改方案

4.1. 消息隊(duì)列修改方案

應(yīng)用在修改完自身緩存數(shù)據(jù)和數(shù)據(jù)庫數(shù)據(jù)之后，給消息隊(duì)列發(fā)送數(shù)據(jù)變化通知，其他應(yīng)用訂閱了消息通知，在收到通知的時(shí)候修改緩存數(shù)據(jù)。

4.2. Timer 修改方案

為了避免耦合，降低復(fù)雜性，對“實(shí)時(shí)一致性”不敏感的情況下。每個(gè)應(yīng)用都會啟動一個(gè) Timer，定時(shí)從數(shù)據(jù)庫拉取最新的數(shù)據(jù)，更新緩存。

不過在有的應(yīng)用更新數(shù)據(jù)庫后，其他節(jié)點(diǎn)通過 Timer 獲取數(shù)據(jù)之間，會讀到臟數(shù)據(jù)。這里需要控制好 Timer 的頻率，以及應(yīng)用與對實(shí)時(shí)性要求不高的場景。

進(jìn)程內(nèi)緩存有哪些使用場景呢？

場景一：只讀數(shù)據(jù)，可以考慮在進(jìn)程啟動時(shí)加載到內(nèi)存。當(dāng)然，把數(shù)據(jù)加載到類似 Redis 這樣的進(jìn)程外緩存服務(wù)也能解決這類問題。

場景二：高并發(fā)，可以考慮使用進(jìn)程內(nèi)緩存，例如：秒殺。

5. 分布式緩存

說完進(jìn)程內(nèi)緩存，自然就過度到進(jìn)程外緩存了。與進(jìn)程內(nèi)緩存不同，進(jìn)程外緩存在應(yīng)用運(yùn)行的進(jìn)程之外，它擁有更大的緩存容量，并且可以部署到不同的物理節(jié)點(diǎn)，通常會用分布式緩存的方式實(shí)現(xiàn)。

分布式緩存是與應(yīng)用分離的緩存服務(wù)，最大的特點(diǎn)是，自身是一個(gè)獨(dú)立的應(yīng)用/服務(wù)，與本地應(yīng)用隔離，多個(gè)應(yīng)用可直接共享一個(gè)或者多個(gè)緩存應(yīng)用/服務(wù)。

既然是分布式緩存，緩存的數(shù)據(jù)會分布到不同的緩存節(jié)點(diǎn)上，每個(gè)緩存節(jié)點(diǎn)緩存的數(shù)據(jù)大小通常也是有限制的。

數(shù)據(jù)被緩存到不同的節(jié)點(diǎn)，為了能方便的訪問這些節(jié)點(diǎn)，需要引入緩存代理，類似 Twemproxy。他會幫助請求找到對應(yīng)的緩存節(jié)點(diǎn)。

同時(shí)如果緩存節(jié)點(diǎn)增加了，這個(gè)代理也會只能識別并且把新的緩存數(shù)據(jù)分片到新的節(jié)點(diǎn)，做橫向的擴(kuò)展。

為了提高緩存的可用性，會在原有的緩存節(jié)點(diǎn)上加入 Master/Slave 的設(shè)計(jì)。當(dāng)緩存數(shù)據(jù)寫入 Master 節(jié)點(diǎn)的時(shí)候，會同時(shí)同步一份到 Slave 節(jié)點(diǎn)。

一旦 Master 節(jié)點(diǎn)失效，可以通過代理直接切換到 Slave 節(jié)點(diǎn)，這時(shí) Slave 節(jié)點(diǎn)就變成了 Master 節(jié)點(diǎn)，保證緩存的正常工作。

每個(gè)緩存節(jié)點(diǎn)還會提供緩存過期的機(jī)制，并且會把緩存內(nèi)容定期以快照的方式保存到文件上，方便緩存崩潰之后啟動預(yù)熱加載。

5.1. 高性能

當(dāng)緩存做成分布式的時(shí)候，數(shù)據(jù)會根據(jù)一定的規(guī)律分配到每個(gè)緩存應(yīng)用/服務(wù)上。

如果我們把這些緩存應(yīng)用/服務(wù)叫做緩存節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)一般都可以緩存一定容量的數(shù)據(jù)，例如：Redis 一個(gè)節(jié)點(diǎn)可以緩存 2G 的數(shù)據(jù)。

如果需要緩存的數(shù)據(jù)量比較大就需要擴(kuò)展多個(gè)緩存節(jié)點(diǎn)來實(shí)現(xiàn)，這么多的緩存節(jié)點(diǎn)，客戶端的請求不知道訪問哪個(gè)節(jié)點(diǎn)怎么辦？緩存的數(shù)據(jù)又如何放到這些節(jié)點(diǎn)上？

緩存代理服務(wù)已經(jīng)幫我們解決這些問題了，例如：Twemproxy 不但可以幫助緩存路由，同時(shí)可以管理緩存節(jié)點(diǎn)。

這里有介紹三種緩存數(shù)據(jù)分片的算法，有了這些算法緩存代理就可以方便的找到分片的數(shù)據(jù)了。

5.1.1. 哈希算法

Hash 表是最常見的數(shù)據(jù)結(jié)構(gòu)，實(shí)現(xiàn)方式是，對數(shù)據(jù)記錄的關(guān)鍵值進(jìn)行 Hash，然后再對需要分片的緩存節(jié)點(diǎn)個(gè)數(shù)進(jìn)行取模得到的余數(shù)進(jìn)行數(shù)據(jù)分配。

例如：有三條記錄數(shù)據(jù)分別是 R1，R2，R3。他們的 ID 分別是 01，02，03，假設(shè)對這三個(gè)記錄的 ID 作為關(guān)鍵值進(jìn)行 Hash 算法之后的結(jié)果依舊是 01，02，03。

我們想把這三條數(shù)據(jù)放到三個(gè)緩存節(jié)點(diǎn)中，可以把這個(gè)結(jié)果分別對 3 這個(gè)數(shù)字取模得到余數(shù)，這個(gè)余數(shù)就是這三條記錄分別放置的緩存節(jié)點(diǎn)。

Hash 算法是某種程度上的平均放置，策略比較簡單，如果要增加緩存節(jié)點(diǎn)，對已經(jīng)存在的數(shù)據(jù)會有較大的變動。

5.1.2. 一致性哈希算法

一致性 Hash 是將數(shù)據(jù)按照特征值映射到一個(gè)首尾相接的 Hash 環(huán)上，同時(shí)也將緩存節(jié)點(diǎn)映射到這個(gè)環(huán)上。

如果要緩存數(shù)據(jù)，通過數(shù)據(jù)的關(guān)鍵值（Key）在環(huán)上找到自己存放的位置。這些數(shù)據(jù)按照自身的 ID 取 Hash 之后得到的值按照順序在環(huán)上排列。

如果這個(gè)時(shí)候要插入一條新的數(shù)據(jù)其 ID 是 115，那么就應(yīng)該插入到如下圖的位置。

同理如果要增加一個(gè)緩存節(jié)點(diǎn) N4 150，也可以放到如下圖的位置。

這種算法對于增加緩存數(shù)據(jù)，和緩存節(jié)點(diǎn)的開銷相對比較小。

5.1.3. Range Based 算法

這種方式是按照關(guān)鍵值（例如 ID）將數(shù)據(jù)劃分成不同的區(qū)間，每個(gè)緩存節(jié)點(diǎn)負(fù)責(zé)一個(gè)或者多個(gè)區(qū)間。跟一致性哈希有點(diǎn)像。

例如：存在三個(gè)緩存節(jié)點(diǎn)分別是 N1，N2，N3。他們用來存放數(shù)據(jù)的區(qū)間分別是，N1(0, 100]， N2(100, 200]， N3(300, 400]。

那么數(shù)據(jù)根據(jù)自己 ID 作為關(guān)鍵字做 Hash 以后的結(jié)果就會分別對應(yīng)放到這幾個(gè)區(qū)域里面了。

5.2. 可用性

根據(jù)事物的兩面性，在分布式緩存帶來高性能的同時(shí)，我們也需要重視它的可用性。那么哪些潛在的風(fēng)險(xiǎn)是我們需要防范的呢？

5.2.1. 緩存雪崩

當(dāng)緩存失效，緩存過期被清除，緩存更新的時(shí)候。請求是無法命中緩存的，這個(gè)時(shí)候請求會直接回源到數(shù)據(jù)庫。

如果上述情況頻繁發(fā)生或者同時(shí)發(fā)生的時(shí)候，就會造成大面積的請求直接到數(shù)據(jù)庫，造成數(shù)據(jù)庫訪問瓶頸。我們稱這種情況為緩存雪崩。

從如下兩方面來思考解決方案：

緩存方面：

避免緩存同時(shí)失效，不同的 key 設(shè)置不同的超時(shí)時(shí)間。

增加互斥鎖，對緩存的更新操作進(jìn)行加鎖保護(hù)，保證只有一個(gè)線程進(jìn)行緩存更新。緩存一旦失效可以通過緩存快照的方式迅速重建緩存。對緩存節(jié)點(diǎn)增加主備機(jī)制，當(dāng)主緩存失效以后切換到備用緩存繼續(xù)工作。

設(shè)計(jì)方面，這里給出了幾點(diǎn)建議供大家參考：

熔斷機(jī)制：某個(gè)緩存節(jié)點(diǎn)不能工作的時(shí)候，需要通知緩存代理不要把請求路由到該節(jié)點(diǎn)，減少用戶等待和請求時(shí)長。

限流機(jī)制：在接入層和代理層可以做限流，當(dāng)緩存服務(wù)無法支持高并發(fā)的時(shí)候，前端可以把無法響應(yīng)的請求放入到隊(duì)列或者丟棄。

隔離機(jī)制：緩存無法提供服務(wù)或者正在預(yù)熱重建的時(shí)候，把該請求放入隊(duì)列中，這樣該請求因?yàn)楸桓綦x就不會被路由到其他的緩存節(jié)點(diǎn)。

如此就不會因?yàn)檫@個(gè)節(jié)點(diǎn)的問題影響到其他節(jié)點(diǎn)。當(dāng)緩存重建以后，再從隊(duì)列中取出請求依次處理。

5.2.2. 緩存穿透

緩存一般是 Key，Value 方式存在，一個(gè) Key 對應(yīng)的 Value 不存在時(shí)，請求會回源到數(shù)據(jù)庫。

假如對應(yīng)的 Value 一直不存在，則會頻繁的請求數(shù)據(jù)庫，對數(shù)據(jù)庫造成訪問壓力。如果有人利用這個(gè)漏洞攻擊，就麻煩了。

解決方法：如果一個(gè) Key 對應(yīng)的 Value 查詢返回為空，我們?nèi)匀话堰@個(gè)空結(jié)果緩存起來，如果這個(gè)值沒有變化下次查詢就不會請求數(shù)據(jù)庫了。

將所有可能存在的數(shù)據(jù)哈希到一個(gè)足夠大的 Bitmap 中，那么不存在的數(shù)據(jù)會被這個(gè) Bitmap 過濾器攔截掉，避免對數(shù)據(jù)庫的查詢壓力。

5.2.3. 緩存擊穿

在數(shù)據(jù)請求的時(shí)候，某一個(gè)緩存剛好失效或者正在寫入緩存，同時(shí)這個(gè)緩存數(shù)據(jù)可能會在這個(gè)時(shí)間點(diǎn)被超高并發(fā)請求，成為“熱點(diǎn)”數(shù)據(jù)。

這就是緩存擊穿問題，這個(gè)和緩存雪崩的區(qū)別在于，這里是針對某一個(gè)緩存，前者是針對多個(gè)緩存。

解決方案：導(dǎo)致問題的原因是在同一時(shí)間讀/寫緩存，所以只有保證同一時(shí)間只有一個(gè)線程寫，寫完成以后，其他的請求再使用緩存就可以了。

比較常用的做法是使用 mutex（互斥鎖）。在緩存失效的時(shí)候，不是立即寫入緩存，而是先設(shè)置一個(gè) mutex（互斥鎖）。當(dāng)緩存被寫入完成以后，再放開這個(gè)鎖讓請求進(jìn)行訪問。

總結(jié)：

緩存設(shè)計(jì)有五大策略，從用戶請求開始依次是：

HTTP 緩存

CDN 緩存

負(fù)載均衡緩存

進(jìn)程內(nèi)緩存

分布式緩存

其中，前兩種緩存靜態(tài)數(shù)據(jù)，后三種緩存動態(tài)數(shù)據(jù)：

HTTP 緩存包括強(qiáng)制緩存和對比緩存。

CDN 緩存和 HTTP 緩存是好搭檔。

負(fù)載均衡器緩存相對穩(wěn)定資源，需要服務(wù)協(xié)助工作。

進(jìn)程內(nèi)緩存，效率高，但容量有限制，有兩個(gè)方案可以應(yīng)對緩存同步的問題。

分布式緩存容量大，能力強(qiáng)，牢記三個(gè)性能算法并且防范三個(gè)緩存風(fēng)險(xiǎn)。