超級面試題：如何優(yōu)化緩存中百萬級并發(fā)的KEY

這個問題實際上就是熱點key問題，其實熱點key問題說來也很簡單，就是瞬間有幾十萬上百萬，甚至更大的請求去訪問redis上某個固定的key，從而壓垮緩存服務(wù)的情情況。
其實生活中也是有不少這樣的例子，比如XX明星結(jié)婚。那么關(guān)于XX明星的Key就會瞬間增大，就會出現(xiàn)熱點數(shù)據(jù)問題。
PS:hot key和big key問題，大家一定要有所了解，非常重要。

本文預(yù)計分為如下幾個部分：

• 熱點key問題

• 如何發(fā)現(xiàn)

• 業(yè)內(nèi)方案

正文

熱點Key問題

上面提到，所謂熱點key問題就是，突然有幾十萬甚至更大的請求去訪問redis上的某個特定key。那么，這樣會造成流量過于集中，達到Redis單實例瓶頸（一般是10W OPS級別），或者物理網(wǎng)卡上限，從而導(dǎo)致這臺redis的服務(wù)器Hold不住。
那接下來這個key的請求，就會壓垮你的服務(wù)。

怎么發(fā)現(xiàn)熱key

方法一:憑借業(yè)務(wù)經(jīng)驗，進行預(yù)估哪些是熱key
其實這個方法還是挺有可行性的。比如某商品在做秒殺，那這個商品的key就可以判斷出是熱key。缺點很明顯，并非所有業(yè)務(wù)都能預(yù)估出哪些key是熱key。

方法二:在客戶端進行收集
這個方式就是在操作redis之前，加入一行代碼進行數(shù)據(jù)統(tǒng)計。那么這個數(shù)據(jù)統(tǒng)計的方式有很多種，也可以是給外部的通訊系統(tǒng)發(fā)送一個通知信息。缺點就是對客戶端代碼造成入侵。

方法三:在Proxy層做收集
有些集群架構(gòu)是下面這樣的，Proxy可以是Twemproxy，是統(tǒng)一的入口?？梢栽赑roxy層做收集上報，但是缺點很明顯，并非所有的redis集群架構(gòu)都有proxy。

以上五種方案，各有優(yōu)缺點。根據(jù)自己業(yè)務(wù)場景進行抉擇即可。那么發(fā)現(xiàn)熱key后，如何解決呢？

如何解決

目前業(yè)內(nèi)的方案有兩種：

(1)二級緩存（推薦）
比如利用ehcache，或者guava-cache，或者一個HashMap或者List都可以。在你發(fā)現(xiàn)熱key以后，把熱key加載到JVM中（可以是堆內(nèi)，也可以是堆外）。針對這種熱key請求，會直接從JVM中取，而不會走到redis層。
假設(shè)此時有十萬個針對同一個key的請求過來,如果沒有本地緩存，這十萬個請求就直接懟到同一臺redis上了?，F(xiàn)在假設(shè)，你的應(yīng)用層有10臺機器，OK，你也有jvm緩存了。這十萬個請求平均分散開來，每個機器有10000個請求，會從JVM中取到value值，然后返回數(shù)據(jù)。避免了十萬個請求懟到同一臺redis上的情形。

(2)備份熱點key
這個方案也很簡單。不要讓key走到同一臺redis上不就行了。我們把這個key，在多個redis上都存一份不就好了。接下來，有熱key請求進來的時候，我們就在有備份的redis上隨機選取一臺，進行訪問取值，返回數(shù)據(jù)。
假設(shè)redis的集群數(shù)量為N，步驟如下圖所示：

const?M?=?N?*?2
//生成隨機數(shù)
random?=?GenRandom(0,?M)
//構(gòu)造備份新key
bakHotKey?=?hotKey?+?“_”?+?random
data?=?redis.GET(bakHotKey)
if?data?==?NULL?{
????data?=?GetFromDB()
????redis.SET(bakHotKey,?expireTime?+?GenRandom(0,5))
}

說明：這種方案有一個很明顯的缺點，就是緩存的維護代價非常大。假設(shè)有100個備份KEY，那么在刪除或者更新時，也需要更新100個KEY，所以這種方案不是很推薦。

業(yè)內(nèi)方案

OK，其實看完上面的內(nèi)容，大家可能會有一個疑問。

有辦法在項目運行過程中，自動發(fā)現(xiàn)熱點key，然后程序自動處理么？

嗯，好問題，那我們來講講業(yè)內(nèi)怎么做的。其實只有兩步：

1. 監(jiān)控?zé)狳ckey

2. 通知系統(tǒng)做處理

正巧，前幾天有贊出了一篇《有贊透明多級緩存解決方案（TMC）》，里頭也有提到熱點key問題，我們剛好借此說明。

(1) 監(jiān)控?zé)狳ckey
在監(jiān)控?zé)狳ckey方面，有贊用的是方式二：在客戶端進行收集。
在《有贊透明多級緩存解決方案（TMC）》中有一句話提到

TMC 對原生jedis包的JedisPool和Jedis類做了改造，在JedisPool初始化過程中集成TMC“熱點發(fā)現(xiàn)”+“本地緩存”功能Hermes-SDK包的初始化邏輯。

也就說人家改寫了jedis原生的jar包，加入了Hermes-SDK包。
那Hermes-SDK包用來干嘛？
OK，就是做熱點發(fā)現(xiàn)和本地緩存。
從監(jiān)控的角度看，該包對于Jedis-Client的每次key值訪問請求，Hermes-SDK 都會通過其通信模塊將key訪問事件異步上報給Hermes服務(wù)端集群，以便其根據(jù)上報數(shù)據(jù)進行“熱點探測”。

當(dāng)然，這只是其中一種方式，有的公司在監(jiān)控方面用的是方式五:?自己抓包評估。具體是這么做的，先利用flink搭建一套流式計算系統(tǒng)。然后自己寫一個抓包程序抓redis監(jiān)聽端口的數(shù)據(jù)，抓到數(shù)據(jù)后往kafka里丟。
接下來，流式計算系統(tǒng)消費kafka里的數(shù)據(jù)，進行數(shù)據(jù)統(tǒng)計即可，也能達到監(jiān)控?zé)醟ey的目的。

(2) 通知系統(tǒng)做處理
在這個角度，有贊用的是上面的解決方案一:利用二級緩存進行處理。
有贊在監(jiān)控到熱key后，Hermes服務(wù)端集群會通過各種手段通知各業(yè)務(wù)系統(tǒng)里的Hermes-SDK，告訴他們:"老弟，這個key是熱key，記得做本地緩存。"
于是Hermes-SDK就會將該key緩存在本地，對于后面的請求。Hermes-SDK發(fā)現(xiàn)這個是一個熱key，直接從本地中拿，而不會去訪問集群。

除了這種通知方式以外。我們也可以這么做，比如你的流式計算系統(tǒng)監(jiān)控到熱key了，往zookeeper里頭的某個節(jié)點里寫。然后你的業(yè)務(wù)系統(tǒng)監(jiān)聽該節(jié)點，發(fā)現(xiàn)節(jié)點數(shù)據(jù)變化了，就代表發(fā)現(xiàn)熱key。最后往本地緩存里寫，也是可以的。

通知方式各種各樣，大家可以自由發(fā)揮。本文只是提供一個思路。

總結(jié)

希望通過本文，大家明白如何處理生產(chǎn)上遇到的熱key問題。