這篇文章，咱們來聊聊熱點緩存的架構(gòu)優(yōu)化問題。使用緩存集群的時候，最怕的就是熱 Key、大 Value 這兩種情況。

為什么要用緩存集群

啥叫熱 Key 和大 Value 呢?簡單來說，熱 Key，就是你的緩存集群中的某個 Key 瞬間被數(shù)萬甚至十萬的并發(fā)請求打爆。

大 Value，就是你的某個 Key 對應的 Value 可能有 GB 級的大小，導致查詢 Value 的時候出現(xiàn)網(wǎng)絡相關(guān)的故障問題。

先來看看下面的一幅圖：

簡單來說，假設你手頭有個系統(tǒng)，他本身是集群部署的，然后后面有一套緩存集群，這個集群不管你用 Redis Cluster，還是 Memcached，或者是公司自研緩存集群，都可以。

那么，這套系統(tǒng)用緩存集群干什么呢?很簡單，在緩存里放一些平時不怎么變動的數(shù)據(jù)，然后用戶在查詢大量的平時不怎么變動的數(shù)據(jù)的時候，不就可以直接從緩存里走了嗎?

緩存集群的并發(fā)能力是很強的，而且讀緩存的性能是很高的。舉個例子，假設你每秒有 2 萬請求，但是其中 90% 都是讀請求，那么每秒 1.8 萬請求都是在讀一些不太變化的數(shù)據(jù)，而不是寫數(shù)據(jù)。

那此時你把數(shù)據(jù)都放在數(shù)據(jù)庫里，然后每秒發(fā)送 2 萬請求到數(shù)據(jù)庫上讀寫數(shù)據(jù)，你覺得合適嗎?

當然不太合適了，如果你要用數(shù)據(jù)庫承載每秒 2 萬請求的話，那么不好意思，你很可能就得搞分庫分表 + 讀寫分離。

比如你得分 3 個主庫，承載每秒 2000 的寫入請求，然后每個主庫掛 3 個從庫，一共 9 個從庫承載每秒 1.8 萬的讀請求。

這樣的話，你可能就需要一共是 12 臺高配置的數(shù)據(jù)庫服務器，這是很耗費錢的，成本非常高，而且很不合適。

大家看看下面的圖，來體會下這種情況：

所以，此時你完全就可以把平時不太變化的數(shù)據(jù)放在緩存集群里，緩存集群可以采用 2 主 2 從，主節(jié)點用來寫入緩存，從節(jié)點用來讀緩存。

以緩存集群的性能，2 個從節(jié)點完全可以用來承載每秒 1.8 萬的大量讀了，然后 3 個數(shù)據(jù)庫主庫就是承載每秒 2000 的寫請求和少量其他讀請求就可以了。

大家看看下面的圖，你耗費的機器瞬間變成了 4 臺緩存機器 + 3 臺數(shù)據(jù)庫機器 = 7 臺機器，是不是比之前的 12 臺機器減少了很大的資源開銷?

沒錯，緩存其實在系統(tǒng)架構(gòu)里是非常重要的組成部分。很多時候，對于那些很少變化但是大量高并發(fā)讀的數(shù)據(jù)，通過緩存集群來抗高并發(fā)讀，是非常合適的。

這里所有的機器數(shù)量、并發(fā)請求量都是一個示例，大家主要是體會一下這個意思就好，其目的主要是給一些不太熟悉緩存相關(guān)技術(shù)的同學一點背景性的闡述，讓這些同學能夠理解在系統(tǒng)里用緩存集群承載讀請求是什么意思。

20 萬用戶同時訪問一個熱點緩存的問題

好了，背景是已經(jīng)給大家解釋清楚了，那么現(xiàn)在就可以給大家說說今天重點要討論的問題：熱點緩存。

我們來做一個假設，你現(xiàn)在有 10 個緩存節(jié)點來抗大量的讀請求。正常情況下，讀請求應該是均勻的落在 10 個緩存節(jié)點上的，對吧!

這 10 個緩存節(jié)點，每秒承載 1 萬請求是差不多的。然后我們再做一個假設，你一個節(jié)點承載 2 萬請求是極限，所以一般你就限制一個節(jié)點正常承載 1 萬請求就 OK 了，稍微留一點 Buffer 出來。

好，所謂的熱點緩存問題是什么意思呢?很簡單，就是突然因為莫名的原因，出現(xiàn)大量的用戶訪問同一條緩存數(shù)據(jù)。

舉個例子，某個明星突然宣布跟某某結(jié)婚，這個時候是不是會引發(fā)可能短時間內(nèi)每秒都是數(shù)十萬的用戶去查看這個明星跟某某結(jié)婚的那條新聞?

那么假設那條新聞就是一個緩存，然后對應就是一個緩存 Key，就存在一臺緩存機器上，此時瞬時假設有 20 萬請求奔向那一臺機器上的一個 Key。

此時會如何?我們看看下面的圖，來體會一下這種絕望的感受：

這個時候很明顯了，我們剛才假設的是一個緩存 Slave 節(jié)點最多每秒就是 2 萬的請求，當然實際緩存單機承載 5 萬~10 萬讀請求也是可能的，我們這里就是一個假設。

結(jié)果此時，每秒突然奔過來 20 萬請求到這臺機器上，會怎么樣?很簡單，上面圖里那臺被 20 萬請求指向的緩存機器會過度操勞而宕機的。

那么如果緩存集群開始出現(xiàn)機器的宕機，此時會如何?接著，讀請求發(fā)現(xiàn)讀不到數(shù)據(jù)，會從數(shù)據(jù)庫里提取原始數(shù)據(jù)，然后放入剩余的其他緩存機器里去。

但是接踵而來的每秒 20 萬請求，會再次壓垮其他的緩存機器。以此類推，最終導致緩存集群全盤崩潰，引發(fā)系統(tǒng)整體宕機。

咱們看看下面的圖，再感受一下這個恐怖的現(xiàn)場：

基于流式計算技術(shù)的緩存熱點自動發(fā)現(xiàn)

其實這里關(guān)鍵的一點，就是對于這種熱點緩存，你的系統(tǒng)需要能夠在熱點緩存突然發(fā)生的時候，直接發(fā)現(xiàn)他，然后瞬間立馬實現(xiàn)毫秒級的自動負載均衡。

那么我們就先來說說，你如何自動發(fā)現(xiàn)熱點緩存問題?首先你要知道，一般出現(xiàn)緩存熱點的時候，你的每秒并發(fā)肯定是很高的，可能每秒都幾十萬甚至上百萬的請求量過來，這都是有可能的。

所以，此時完全可以基于大數(shù)據(jù)領(lǐng)域的流式計算技術(shù)來進行實時數(shù)據(jù)訪問次數(shù)的統(tǒng)計，比如 Storm、Spark Streaming、Flink，這些技術(shù)都是可以的。

然后一旦在實時數(shù)據(jù)訪問次數(shù)統(tǒng)計的過程中，比如發(fā)現(xiàn)一秒之內(nèi)，某條數(shù)據(jù)突然訪問次數(shù)超過了 1000，就直接立馬把這條數(shù)據(jù)判定為是熱點數(shù)據(jù)，可以將這個發(fā)現(xiàn)出來的熱點數(shù)據(jù)寫入比如 Zookeeper 中。

當然，你的系統(tǒng)如何判定熱點數(shù)據(jù)，可以根據(jù)自己的業(yè)務還有經(jīng)驗值來就可以了。

大家看看下面這張圖，看看整個流程是如何進行的：

當然肯定有人會問，那你的流式計算系統(tǒng)在進行數(shù)據(jù)訪問次數(shù)統(tǒng)計的時候，會不會也存在說單臺機器被請求每秒幾十萬次的問題呢?

答案是否，因為流式計算技術(shù)，尤其是 Storm 這種系統(tǒng)，他可以做到同一條數(shù)據(jù)的請求過來，先分散在很多機器里進行本地計算，***再匯總局部計算結(jié)果到一臺機器進行全局匯總。

所以幾十萬請求可以先分散在比如 100 臺機器上，每臺機器統(tǒng)計了這條數(shù)據(jù)的幾千次請求。

然后 100 條局部計算好的結(jié)果匯總到一臺機器做全局計算即可，所以基于流式計算技術(shù)來進行統(tǒng)計是不會有熱點問題的。

熱點緩存自動加載為 JVM 本地緩存

我們自己的系統(tǒng)可以對 Zookeeper 指定的熱點緩存對應的 Znode 進行監(jiān)聽，如果有變化他立馬就可以感知到了。

此時系統(tǒng)層就可以立馬把相關(guān)的緩存數(shù)據(jù)從數(shù)據(jù)庫加載出來，然后直接放在自己系統(tǒng)內(nèi)部的本地緩存里即可。

這個本地緩存，你用 Ehcache、Hashmap，其實都可以，一切都看自己的業(yè)務需求，主要說的就是將緩存集群里的集中式緩存，直接變成每個系統(tǒng)自己本地實現(xiàn)緩存即可，每個系統(tǒng)自己本地是無法緩存過多數(shù)據(jù)的。

因為一般這種普通系統(tǒng)單實例部署機器可能就一個 4 核 8G 的機器，留給本地緩存的空間是很少的，所以用來放這種熱點數(shù)據(jù)的本地緩存是最合適的，剛剛好。

假設你的系統(tǒng)層集群部署了 100 臺機器，那么好了，此時你 100 臺機器瞬間在本地都會有一份熱點緩存的副本。

然后接下來對熱點緩存的讀操作，直接系統(tǒng)本地緩存讀出來就給返回了，不用再走緩存集群了。

這樣的話，也不可能允許每秒 20 萬的讀請求到達緩存機器的一臺機器上讀一個熱點緩存了，而是變成 100 臺機器每臺機器承載數(shù)千請求，那么那數(shù)千請求就直接從機器本地緩存返回數(shù)據(jù)了，這是沒有問題的。

我們再來畫一幅圖，一起來看看這個過程：

限流熔斷保護

除此之外，在每個系統(tǒng)內(nèi)部，還應該專門加一個對熱點數(shù)據(jù)訪問的限流熔斷保護措施。

每個系統(tǒng)實例內(nèi)部，都可以加一個熔斷保護機制，假設緩存集群最多每秒承載4萬讀請求，那么你一共有 100 個系統(tǒng)實例。

你自己就該限制好，每個系統(tǒng)實例每秒最多請求緩存集群讀操作不超過 400 次，一超過就可以熔斷掉，不讓請求緩存集群，直接返回一個空白信息，然后用戶稍后會自行再次重新刷新頁面之類的。

通過系統(tǒng)層自己直接加限流熔斷保護措施，可以很好的保護后面的緩存集群、數(shù)據(jù)庫集群之類的不要被打死，我們來看看下面的圖：

總結(jié)

具體要不要在系統(tǒng)里實現(xiàn)這種復雜的緩存熱點優(yōu)化架構(gòu)呢?這個還要看你們自己的系統(tǒng)有沒有這種場景了。

如果你的系統(tǒng)有熱點緩存問題，那么就要實現(xiàn)類似本文的復雜熱點緩存支撐架構(gòu)。

但是如果沒有的話，那么也別過度設計，其實你的系統(tǒng)可能根本不需要這么復雜的架構(gòu)。

如果是后者，那么大伙兒就權(quán)當看看本文，來了解一下對應的架構(gòu)思想好了。

作者：中華石杉

中華石杉：十余年 BAT 架構(gòu)經(jīng)驗，一線互聯(lián)網(wǎng)公司技術(shù)總監(jiān)。帶領(lǐng)上百人團隊開發(fā)過多個億級流量高并發(fā)系統(tǒng)?，F(xiàn)將多年工作中積累下的研究手稿、經(jīng)驗總結(jié)整理成文，傾囊相授。微信公眾號：石杉的架構(gòu)筆記(ID：shishan100)。