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

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

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

image.png

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

2. 緩存架構演變

2.1. 無緩存架構

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

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

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

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

2.2.1 為什么選擇redis？

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

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

2.3. 引入 JVM 本地緩存

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

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

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

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

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

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

常用本地緩存

• JDK MAP
• guavaCache
• Caffeine Cache

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

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

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

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

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

• DB 修改數(shù)據(jù)
• 通過監(jiān)聽 canal 消息，觸發(fā)緩存的更新
• 針對 redis 緩存中，因為集群中只共享一份，直接同步緩存即可
• 針對本地緩存，因為集群中存在多分，且分散在不同的 JVM 實例中。故再借助廣播 MQ 機制，通知到各個業(yè)務實例。同步本地緩存

3.1.1 同步緩存機制

• 直接刪除緩存，查詢時直接加載

優(yōu)點：操作簡單

缺點：未命中緩存時，取重新加載。此次查詢請求慢。

• 重新加載緩存

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

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

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

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

3.2.1 熱點 key 探測

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

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

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

詳情見：參考

4. 緩存注意事項

4.1 key 設計

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

4.1.1 value 設計

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

redis 是單線程機制，big key 會阻塞后續(xù)請求。

僅緩存必要的字段，不必要字段，及時瘦身

• 2、改少讀多

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

• 3、計算邏輯復雜的結果

4.1.2 緩存穿透

訪問一個不存在的 key。由于實際上并不存在，所以每次都會訪 DB

• 解決方案

• 緩存空值或默認對象（依據(jù)業(yè)務場景）
• 布隆過濾器

4.1.3 緩存擊穿

某個 key 瞬間訪問量過大，但突然過期，導致大部分流量打到了 DB

• 解決方案

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

4.1.4 緩存雪崩

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

• 解決方法

• key 使用不同的過期時間，或者加一個隨機時間

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

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

6. 踩坑記錄

6.1. 本地緩存被污染

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

• 解決

取對象時，直接 copy 一份。（復制對象耗 CPU，不推薦）

將緩存對象設置成不可編輯。（推薦）

6.2. 緩存計算結果，而不是響應結果

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

• 解決

• 將緩存結果由 Response，調(diào)整為實際的計算結果

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

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

• 解決

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

僅緩存熱點 key，非熱點 key 不緩存在本地

6.4. 降級到 redis 緩存，CPU 彪高

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

• 解決

評估 QPS，考慮是否可降級

僅緩存熱點 key，非熱點 key 不緩存在本地

7. 總結

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

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