首先我們需要明白，什么是一個多級緩存系統，它有什么用。所謂多級緩存系統，就是指在一個系統 的不同的架構層級進行數據緩存，以提升訪問效率。

我們都知道，一個緩存系統，它面臨著許多問題，比如緩存擊穿，緩存穿透，緩存雪崩，緩存熱點等等問題，那么，對于一個多級緩存系統，它有什么問題呢?

緩存熱點：多級緩存系統大多應用在高并發場景下，所以我們需要解決熱點Key問題，如何探測熱點key?

[[272411]]

數據一致性：各層緩存之間的數據一致性問題，如應用層緩存和分布式緩存之前的數據一致性問題。

緩存過期：緩存數據可以分為兩大類，過期緩存和不過期緩存?如何設計，如何設計過期緩存?

在這之前，我們先看看一個簡單的多級緩存系統的架構圖：

整個多級緩存系統被分為三層，應用層nginx緩存，分布式redis緩存集群，tomcat堆內緩存。整個架構流程如下：

當接收到一個請求時，首先會分發到nginx集群中，這里可以采用nginx的負載均衡算法分發給某一臺機器，使用輪詢可以降低負載，或者采用一致性hash算法來提升緩存命中率。

當nginx層沒有緩存數據時，會繼續向下請求，在分布式緩存集群中查找數據，如果緩存命中，直接返回(并且寫入nginx應用緩存中)，如果未命中，則回源到tomcat集群中查詢堆內緩存。

在分布式緩存中查詢不到數據，將會去tomcat集群中查詢堆內緩存，查詢成功直接返回(并寫入分redis主集群中)，查詢失敗請求數據庫;堆內緩存。

如果以上緩存中都沒有命中，則直接請求數據庫，返回結果，同步數據到分布式緩存中。

在簡單了解了多級緩存的基本架構之后，我們就該思考如何解決上面提到的一系列問題。

緩存熱點

緩存熱點，是一個很常見的問題，比如“某某明星宣布結婚”等等，都可能產生大量請求訪問的問題，一個最麻煩也是最容易讓人忽視的事情就是如何探測到熱點key，在緩存系統中，除了一些常用的熱點key外，在某些特殊場合下也會出現大量的熱點key，我們該如何發現呢?有以下策略：

數據調研。可以分析歷史數據以及針對不同的場合去預測出熱點key，這種方式雖然不能百分百使得緩存命中，但是卻是一種最簡單和節省成本的方案。

實時計算。可以使用現有的實時計算框架，比如storm、spark streaming、flink等框架統計一個時間段內的請求量，從而判斷熱點key。或者也可以自己實現定時任務去統計請求量。

這里我們著重討論一下第二種解決方案，對于熱點key問題，當緩存系統中沒有發現緩存時，需要去數據庫中讀取數據，當大量請求來的時候，一個請求獲取鎖去請求數據庫，其他阻塞，接著全部去訪問緩存，這樣可能因為一臺服務器撐不住從而宕機，比如正常一臺服務器并發量為5w左右，產生熱點key的時候達到了10w甚至20w，這樣服務器肯定會崩。所以我們在發現熱點key之后還需要做到如何自動負載均衡。

結合以上問題我們重新設計架構，如下圖所示：

我們將整個應用架構分為應用層，分布式緩存、系統層以及數據層。

在應用層，我們采用nginx集群，并且對接實時計算鏈路，通過flume監控nginx日志，將數據傳輸到kafka集群中，然后flink集群消費數據進行統計，如果統計 結果為熱點key，則將數據寫入zookeeper的節點中，而應用系統通過監控znode節點，讀取熱點key數據，去數據庫中加載數據到緩存中并且做到負載均衡。

實際上，對于應用系統中的每一臺服務器，還需要一層防護機制，限流熔斷，這樣做的目的是為了防止單臺機器請求量過高，使得服務器負載過高，不至于服務器宕機或者大量請求訪問數據庫。簡單思路就是為每一臺服務器設計一個閥值，當請求量大于該值就直接返回用戶空白頁面或者提示用戶幾秒后刷新重新訪問。

數據一致性

數據一致性問題主要體現在緩存更新的時候，如何更新緩存，保證數據庫與緩存以及各層緩存層之間的一致性。

對于緩存更新問題，先寫緩存還是先寫數據庫，這里省略若干字。之前的文章介紹過，有興趣的讀者可以翻閱。

在單層緩存系統中，我們可以先刪除緩存然后更新數據庫的方案來解決其數據一致性問題，那么對于多級緩存呢?如果使用這種方案，我們需要考慮，如果先刪除緩存，那么需要逐層去做刪除操作，那么這一系列操作對系統帶來的耗時也是和可觀的。

如果我們使用分布式事務機制，就需要考慮該不該將寫緩存放入事務當中，因為我們更新分布式緩存，需要走網絡通信，大量的請求將導致網路抖動甚至阻塞，增加了系統的延遲，導致系統短時間內不可用。如果我們不將寫緩存這一操作放入事務當中，那么可能引起短時間內數據不一致。這也就是分布式系統的CAP理論，我們不能同時達到高可用和一致性。那么該如何抉擇呢?

這里我們選擇保證系統的可用性，就一個秒殺系統來講，短暫的不一致性問題對用戶的體驗影響并不大(當然，這里不涉及支付系統)，而可用性對用戶來說卻很重要，一個活動可能在很短的時間內結束，而用戶需要在這段時間內搶到自己心儀的商品，所以可用性更重要一些(這里需要根據具體場景進行權衡)。

在保證了系統的可用性的基礎上，我們該如何實現呢?如果實時性要求不是很高，我們可以采用全量+增量同步的方式進行。首先，我們可以按照預計的熱點key對系統進行緩存預熱，全量同步數據到緩存系統。接著，在需要更新緩存的時候，我們可以采用增量同步的方式更新緩存。比如我們可以使用阿里Canal框架同步binlog的方式進行數據的同步。

緩存過期

緩存系統中的所有數據，根據數據的使用頻率以及場景，我們可以分為過期key以及不過期key，那么對齊過期緩存我們該如何淘汰呢?下面有常用的幾種方案：

FIFO：使用FIFO算法來淘汰過期緩存。

LFU：使用LFU算法來淘汰過期緩存。

LRU：使用LRU算法來淘汰過期緩存。

以上幾種方案是在緩存達到最大緩存大小的時候的淘汰策略，如果沒有達到最大緩存大小，我們有下面幾種方式：

定時刪除策略：設置一個定時任務，在規定時間內檢查并且刪除過期key。

定期刪除策略：這種策略需要設置刪除的周期以及時長，如何設置，需要根據具體場合來計算。

惰性刪除策略：在使用時檢查是否過期，如果過期直接去更新緩存，否則直接返回。