1. 緩存系統概述

如上圖，是一次最基本的網絡請求。用戶請求從界面（瀏覽器或 App 界面）到網絡轉發、應用服務再到存儲（數據庫或文件系統），然后返回到界面呈現內容。

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

image.png

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

2. 緩存架構演變

2.1. 無緩存架構

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

2.2. 引入分布式緩存數據庫

針對2.1無緩存架構的數據庫磁盤IO耗時，可添加了一道緩存數據庫例如 redis。借助緩存中間件，可消除數據庫的 IO 瓶頸。快速返回數據。如下圖：

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

2.2.1 為什么選擇redis？

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

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

2.3. 引入 JVM 本地緩存

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

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

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

• 需要在多臺 JVM 機器上冗余緩存，對內存要求高。
• 緩存在多臺 JVM 實例，數據一致性維護成本高。

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

• 業務訪問量 QPS
• 硬件資源內存是否充足
• 變更場景是否頻繁

常用本地緩存

• JDK MAP
• guavaCache
• Caffeine Cache

2.3.1 數據讀取流程

按優先級依次從本地、redis、DB 中讀取數據。實現了本地（一級緩存）、緩存數據庫（二級緩存）和 DB 的多級緩存架構。

3. 痛點和優化

3.1 數據一致性問題

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

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

3.1.1 同步緩存機制

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

優點：操作簡單

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

• 重新加載緩存

• 優點：提前設置緩存，查詢效率高

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

3.2. 熱點 key 監控

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

3.2.1 熱點 key 探測

引入緩存中間調度服務：熱點 key 探測中間服務器概念

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

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

詳情見：參考

4. 緩存注意事項

4.1 key 設計

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

4.1.1 value 設計

• 盡可能小，避免出現 big key

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

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

• 2、改少讀多

• 變更頻繁的數據不建議緩存，頻繁的數據變更會導致緩存實現和一致性同步問題，反而會損耗系統性能

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

4.1.2 緩存穿透

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

• 解決方案

• 緩存空值或默認對象（依據業務場景）
• 布隆過濾器

4.1.3 緩存擊穿

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

• 解決方案

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

4.1.4 緩存雪崩

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

• 解決方法

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

5. 實戰經驗

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

6. 踩坑記錄

6.1. 本地緩存被污染

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

• 解決

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

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

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

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

• 解決

• 將緩存結果由 Response，調整為實際的計算結果

6.3. 本地內存彪高，觸發頻繁 full GC

初次引入本地緩存（之前是 redis ）。將大量數據緩存在本地，導致 JVM 內存彪高。

• 解決

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

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

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

為優化 JVM 內存，將本地緩存降級到 redis。QPS 高場景，觸發大量序列化和young GC，導致系統 CPU 彪高。

• 解決

評估 QPS，考慮是否可降級

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

7. 總結

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

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