1. 緩存系統(tǒng)概述

如上圖，是一次最基本的網(wǎng)絡(luò)請(qǐng)求。用戶請(qǐng)求從界面（瀏覽器或 App 界面）到網(wǎng)絡(luò)轉(zhuǎn)發(fā)、應(yīng)用服務(wù)再到存儲(chǔ)（數(shù)據(jù)庫(kù)或文件系統(tǒng)），然后返回到界面呈現(xiàn)內(nèi)容。

隨著互聯(lián)網(wǎng)的普及，內(nèi)容信息越來越復(fù)雜，用戶數(shù)和訪問量越來越大，我們的應(yīng)用需要支撐更多的并發(fā)量，同時(shí)我們的應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器所做的計(jì)算也越來越多。但是往往我們的應(yīng)用服務(wù)器資源是有限的，數(shù)據(jù)庫(kù)每秒能接受的請(qǐng)求次數(shù)也是有限的。如何能夠有效利用有限的資源來提供盡可能大的吞吐量？是每個(gè)開發(fā)同學(xué)繞不開的課題。一個(gè)有效的辦法就是引入緩存，打破標(biāo)準(zhǔn)流程，如下圖1到4每個(gè)環(huán)節(jié)中請(qǐng)求可以從緩存中直接獲取目標(biāo)數(shù)據(jù)并返回，從而減少計(jì)算量，有效提升響應(yīng)速度，讓有限的資源服務(wù)更多的用戶。

image.png

緩存可以應(yīng)用上圖1到4個(gè)的各個(gè)環(huán)節(jié)中，且不同環(huán)節(jié)緩存策略略有不同。本文將主要從3和4點(diǎn)講解緩存的使用。

2. 緩存架構(gòu)演變

2.1. 無緩存架構(gòu)

如上圖，是一次最基本的網(wǎng)絡(luò)請(qǐng)求。請(qǐng)求從網(wǎng)絡(luò)層直接請(qǐng)求到 DB。此時(shí)請(qǐng)求耗時(shí)最大卡點(diǎn)在數(shù)據(jù)庫(kù)的磁盤 IO 上。

2.2. 引入分布式緩存數(shù)據(jù)庫(kù)

針對(duì)2.1無緩存架構(gòu)的數(shù)據(jù)庫(kù)磁盤IO耗時(shí)，可添加了一道緩存數(shù)據(jù)庫(kù)例如 redis。借助緩存中間件，可消除數(shù)據(jù)庫(kù)的 IO 瓶頸?？焖俜祷?cái)?shù)據(jù)。如下圖：

通過緩存數(shù)據(jù)庫(kù)1、可防止流量直接打到數(shù)據(jù)庫(kù)層，減緩數(shù)據(jù)庫(kù)壓力。2、緩存快速返回，可提高請(qǐng)求查詢速率。

2.2.1 為什么選擇redis？

• 純內(nèi)存操作，無磁盤 IO 耗時(shí)
• key-value 數(shù)據(jù)庫(kù)，時(shí)間復(fù)雜度 O(1),相比數(shù)據(jù)庫(kù)的 O(Log n)，訪問速度更快
• IO 多路復(fù)用線程模型，IO 階段無阻塞

此時(shí)系統(tǒng)卡點(diǎn)在緩存數(shù)據(jù)庫(kù)的網(wǎng)絡(luò)通信上。即使緩存數(shù)據(jù)庫(kù)讀取數(shù)據(jù)很快，但是和應(yīng)用服務(wù)間仍然隔著一層網(wǎng)絡(luò)通信。

2.3. 引入 JVM 本地緩存

針對(duì)2.2緩存數(shù)據(jù)庫(kù)架構(gòu)，訪問緩存數(shù)據(jù)庫(kù)的網(wǎng)絡(luò)通信問題，可在 JVM 應(yīng)用層添加本地緩存，解決網(wǎng)絡(luò) IO 問題。如下圖

在應(yīng)用內(nèi)部新增本地緩存，使流量在應(yīng)用層直接返回。避免進(jìn)一步訪問到 redis。

本架構(gòu)雖然可大大提高數(shù)據(jù)讀取速率，但其成本也是更高的。

• 需要在多臺(tái) JVM 機(jī)器上冗余緩存，對(duì)內(nèi)存要求高。
• 緩存在多臺(tái) JVM 實(shí)例，數(shù)據(jù)一致性維護(hù)成本高。

建議根據(jù)自身業(yè)務(wù)場(chǎng)景，從以下3方面考量是否才有本地緩存。

• 業(yè)務(wù)訪問量 QPS
• 硬件資源內(nèi)存是否充足
• 變更場(chǎng)景是否頻繁

常用本地緩存

• JDK MAP
• guavaCache
• Caffeine Cache

2.3.1 數(shù)據(jù)讀取流程

按優(yōu)先級(jí)依次從本地、redis、DB 中讀取數(shù)據(jù)。實(shí)現(xiàn)了本地（一級(jí)緩存）、緩存數(shù)據(jù)庫(kù)（二級(jí)緩存）和 DB 的多級(jí)緩存架構(gòu)。

3. 痛點(diǎn)和優(yōu)化

3.1 數(shù)據(jù)一致性問題

存在多級(jí)緩存，雖然大大提高了數(shù)據(jù)的讀取速率。但是數(shù)據(jù)散落在各個(gè)不同的區(qū)域，數(shù)據(jù)一致性就是一個(gè)繞不過去的問題。特別是針對(duì)本地緩存，同時(shí)散落在多個(gè)多臺(tái) JVM 實(shí)例中。數(shù)據(jù)變更時(shí)，必須同步修改redis、本地緩存和DB。以下是基于canal + 廣播消息實(shí)現(xiàn)的一致性異步處理方案。

• DB 修改數(shù)據(jù)
• 通過監(jiān)聽 canal 消息，觸發(fā)緩存的更新
• 針對(duì) redis 緩存中，因?yàn)榧褐兄还蚕硪环?，直接同步緩存即?/li>
• 針對(duì)本地緩存，因?yàn)榧褐写嬖诙喾?，且分散在不同?JVM 實(shí)例中。故再借助廣播 MQ 機(jī)制，通知到各個(gè)業(yè)務(wù)實(shí)例。同步本地緩存

3.1.1 同步緩存機(jī)制

• 直接刪除緩存，查詢時(shí)直接加載

優(yōu)點(diǎn)：操作簡(jiǎn)單

缺點(diǎn)：未命中緩存時(shí)，取重新加載。此次查詢請(qǐng)求慢。

• 重新加載緩存

• 優(yōu)點(diǎn)：提前設(shè)置緩存，查詢效率高

**注意:**此方案同步緩存，為先 DB 操作、后異步同步緩存。會(huì)存在短暫 DB 和緩存不一致場(chǎng)景。需根據(jù)自身業(yè)務(wù)場(chǎng)景考量，如有必要，可前置刪除緩存，再 DB 操作。

3.2. 熱點(diǎn) key 監(jiān)控

以上架構(gòu)，系統(tǒng)緩存只能被動(dòng)加載。只有 key 被訪問后，系統(tǒng)才能觸發(fā)加載。在高并發(fā)的情況下，如一直出現(xiàn)緩存穿透，大量流量請(qǐng)求到數(shù)據(jù)庫(kù)，對(duì)數(shù)據(jù)庫(kù)還是很大的考驗(yàn)。所以優(yōu)秀的緩存系統(tǒng)，應(yīng)該能自動(dòng)識(shí)別出熱點(diǎn) key。前置將數(shù)據(jù)緩存下來。

3.2.1 熱點(diǎn) key 探測(cè)

引入緩存中間調(diào)度服務(wù)：熱點(diǎn) key 探測(cè)中間服務(wù)器概念

• 1、業(yè)務(wù)實(shí)例匯總 key 訪問情況并將上報(bào)到“熱點(diǎn) key 探測(cè)中間服務(wù)器”。
• 2、“熱點(diǎn) key 探測(cè)中間服務(wù)器”根據(jù)各業(yè)務(wù)實(shí)例上報(bào)的信息，識(shí)別該 key 是否為熱點(diǎn)。
• 3、“熱點(diǎn) key 探測(cè)中間服務(wù)器”將識(shí)別結(jié)果通知到各業(yè)務(wù)實(shí)例。

• 如若為熱點(diǎn) key：業(yè)務(wù)實(shí)例自動(dòng)預(yù)熱緩存，等待流量訪問。
• 如若非熱點(diǎn) key：業(yè)務(wù)實(shí)例釋放該熱點(diǎn) key，釋放內(nèi)存占用。

詳情見：參考

4. 緩存注意事項(xiàng)

4.1 key 設(shè)計(jì)

• 長(zhǎng)度短：redis key 越短，占用內(nèi)存越小
• 高命中率：命中率不高，緩存意義不大

4.1.1 value 設(shè)計(jì)

• 盡可能小，避免出現(xiàn) big key

redis 是單線程機(jī)制，big key 會(huì)阻塞后續(xù)請(qǐng)求。

僅緩存必要的字段，不必要字段，及時(shí)瘦身

• 2、改少讀多

• 變更頻繁的數(shù)據(jù)不建議緩存，頻繁的數(shù)據(jù)變更會(huì)導(dǎo)致緩存實(shí)現(xiàn)和一致性同步問題，反而會(huì)損耗系統(tǒng)性能

• 3、計(jì)算邏輯復(fù)雜的結(jié)果

4.1.2 緩存穿透

訪問一個(gè)不存在的 key。由于實(shí)際上并不存在，所以每次都會(huì)訪 DB

• 解決方案

• 緩存空值或默認(rèn)對(duì)象（依據(jù)業(yè)務(wù)場(chǎng)景）
• 布隆過濾器

4.1.3 緩存擊穿

某個(gè) key 瞬間訪問量過大，但突然過期，導(dǎo)致大部分流量打到了 DB

• 解決方案

• histrix 保護(hù)，對(duì) DB 的訪問限流
• 只有獲得鎖的線程才能去 DB 讀取數(shù)據(jù)，并填充到緩存中
• 1.使用互斥鎖
• 2.永不過期
• 3.資源保護(hù)

4.1.4 緩存雪崩

由于大部分 key 設(shè)置了相同的失效時(shí)間，某一時(shí)間大量緩存同時(shí)失效，導(dǎo)致大部分流量瞬間打到 DB，導(dǎo)致 DB 壓力過大。

• 解決方法

• key 使用不同的過期時(shí)間，或者加一個(gè)隨機(jī)時(shí)間

5. 實(shí)戰(zhàn)經(jīng)驗(yàn)

• 評(píng)估預(yù)計(jì)占用的緩存大小，避免占滿 redis 集群和 JVM 內(nèi)存
• 評(píng)估預(yù)計(jì) QPS，如2.2架構(gòu)。大量從 redis 中獲取對(duì)象，會(huì)涉及平凡的對(duì)象反序列化操作，此處存在耗 CPU 操作。
• 嚴(yán)格禁止 bigKey。redis的單線程模型，出現(xiàn) bigKey 會(huì)嚴(yán)重降低 redis 服務(wù)吞吐量。
• 必須設(shè)置過期時(shí)間

6. 踩坑記錄

6.1. 本地緩存被污染

由于緩存在 JVM 內(nèi)部，且保存在老年代。業(yè)務(wù)方拿去使用的時(shí)候，直接修改了緩存的數(shù)據(jù)，導(dǎo)致緩存數(shù)據(jù)不正確。

• 解決

取對(duì)象時(shí)，直接 copy 一份。（復(fù)制對(duì)象耗 CPU，不推薦）

將緩存對(duì)象設(shè)置成不可編輯。（推薦）

6.2. 緩存計(jì)算結(jié)果，而不是響應(yīng)結(jié)果

緩存的 value 是 Response 對(duì)象，首次請(qǐng)求失敗，導(dǎo)致緩存的數(shù)據(jù)為response.success=false。后續(xù)所有命中均操作失敗。

• 解決

• 將緩存結(jié)果由 Response，調(diào)整為實(shí)際的計(jì)算結(jié)果

6.3. 本地內(nèi)存彪高，觸發(fā)頻繁 full GC

初次引入本地緩存（之前是 redis ）。將大量數(shù)據(jù)緩存在本地，導(dǎo)致 JVM 內(nèi)存彪高。

• 解決

引入本地緩存前考慮預(yù)計(jì)內(nèi)存，進(jìn)而考慮是否值得接入本地緩存。

僅緩存熱點(diǎn) key，非熱點(diǎn) key 不緩存在本地

6.4. 降級(jí)到 redis 緩存，CPU 彪高

為優(yōu)化 JVM 內(nèi)存，將本地緩存降級(jí)到 redis。QPS 高場(chǎng)景，觸發(fā)大量序列化和young GC，導(dǎo)致系統(tǒng) CPU 彪高。

• 解決

評(píng)估 QPS，考慮是否可降級(jí)

僅緩存熱點(diǎn) key，非熱點(diǎn) key 不緩存在本地

7. 總結(jié)

在計(jì)算機(jī)世界里，緩存無處不在。但不管緩存系統(tǒng)如何設(shè)計(jì)，其本質(zhì)都是空間換時(shí)間。也就是提升數(shù)據(jù)的獲取速率。

緩存系統(tǒng)的設(shè)計(jì)各有千秋、各有優(yōu)劣。沒有最優(yōu)秀的架構(gòu)，只有最適合的架構(gòu)。應(yīng)該根據(jù)自身實(shí)際業(yè)務(wù)情況考慮緩存架構(gòu)的設(shè)計(jì)。并從緩存命中率、數(shù)據(jù)庫(kù)壓力、數(shù)據(jù)一致性、系統(tǒng)吞吐量等綜合評(píng)估設(shè)計(jì)的合理性。