講了幾天的資料庫系列的文章，大家一定看煩了，其實還沒講完。。。(以下省略一萬字)。
今天我們換換口味，來寫redis方面的內容，談談熱key問題如何解決。
其實熱key問題說來也很簡單，就是瞬間有幾十萬的請求去訪問redis上某個固定的key，從而壓垮快取服務的情情況。
其實生活中也是有不少這樣的例子。比如xx明星結婚。那麼關於xx明星的key就會瞬間增大，就會出現熱資料問題。
ps:hot key和big key問題，大家一定要有所了解。
本文預計分為如下幾個部分
上面提到，所謂熱key問題就是，突然有幾十萬的請求去訪問redis上的某個特定key。那麼，這樣會造成流量過於集中，達到物理網絡卡上限，從而導致這台redis的伺服器宕機。
那接下來這個key的請求，就會直接懟到你的資料庫上，導致你的服務不可用。
方法一:憑藉業務經驗，進行預估哪些是熱key
其實這個方法還是挺有可行性的。比如某商品在做秒殺，那這個商品的key就可以判斷出是熱key。缺點很明顯，並非所有業務都能預估出哪些key是熱key。
方法二:在客戶端進行收集
這個方式就是在操作redis之前，加入一行**進行資料統計。那麼這個資料統計的方式有很多種，也可以是給外部的通訊系統傳送乙個通知資訊。缺點就是對客戶端**造成入侵。
方法三:在proxy層做收集
有些集群架構是下面這樣的，proxy可以是twemproxy，是統一的入口。可以在proxy層做收集上報，但是缺點很明顯，並非所有的redis集群架構都有proxy。
方法四:用redis自帶命令
(1)monitor命令，該命令可以實時抓取出redis伺服器接收到的命令，然後寫**統計出熱key是啥。當然，也有現成的分析工具可以給你使用，比如redis-faina。但是該命令在高併發的條件下，有記憶體增暴增的隱患，還會降低redis的效能。
(2)hotkeys引數，redis 4.0.3提供了redis-cli的熱點key發現功能，執行redis-cli時加上–hotkeys選項即可。但是該引數在執行的時候，如果key比較多，執行起來比較慢。
方法五:自己抓包評估
redis客戶端使用tcp協議與服務端進行互動，通訊協議採用的是resp。自己寫程式監聽埠，按照resp協議規則解析資料，進行分析。缺點就是開發成本高，維護困難，有丟包可能性。
以上五種方案，各有優缺點。根據自己業務場景進行抉擇即可。那麼發現熱key後，如何解決呢？
目前業內的方案有兩種
(1)利用二級快取
比如利用ehcache，或者乙個hashmap都可以。在你發現熱key以後，把熱key載入到系統的jvm中。
針對這種熱key請求，會直接從jvm中取，而不會走到redis層。
假設此時有十萬個針對同乙個key的請求過來,如果沒有本地快取，這十萬個請求就直接懟到同一臺redis上了。
現在假設，你的應用層有50臺機器，ok，你也有jvm快取了。這十萬個請求平均分散開來，每個機器有2000個請求，會從jvm中取到value值，然後返回資料。避免了十萬個請求懟到同一臺redis上的情形。
(2)備份熱key
這個方案也很簡單。不要讓key走到同一臺redis上不就行了。我們把這個key，在多個redis上都存乙份不就好了。接下來，有熱key請求進來的時候，我們就在有備份的redis上隨機選取一台，進行訪問取值，返回資料。
假設redis的集群數量為n，步驟如下圖所示
注:不一定是2n，你想取3n，4n都可以，看要求。
偽**如下
const m = n * 2
//生成隨機數
random = genrandom(0, m)
//構造備份新key
bakhotkey = hotkey + 「_」 + random
data = redis.get(bakhotkey)
if data == null
煙哥，有辦法在專案執行過程中，自動發現熱key，然後程式自動處理麼？嗯，好問題，那我們來講講業內怎麼做的。其實只有兩步
(1)監控熱key
(2)通知系統做處理
正巧，前幾天有讚出了一篇《有讚透明多級快取解決方案（tmc）》，裡頭也有提到熱點key問題，我們剛好藉此說明
(1)監控熱key
在監控熱key方面，有讚用的是方式二：在客戶端進行收集。
在《有讚透明多級快取解決方案（tmc）》中有一句話提到
tmc 對原生jedis包的jedispool和jedis類做了改造，在jedispool初始化過程中整合tmc「熱點發現」+「本地快取」功能hermes-sdk包的初始化邏輯。也就說人家改寫了jedis原生的jar包，加入了hermes-sdk包。
那hermes-sdk包用來幹嘛？
ok，就是做熱點發現和本地快取。
從監控的角度看，該包對於jedis-client的每次key值訪問請求，hermes-sdk 都會通過其通訊模組將key訪問事件非同步上報給hermes服務端集群，以便其根據上報資料進行「熱點探測」。
當然，這只是其中一種方式，有的公司在監控方面用的是方式五:自己抓包評估。
具體是這麼做的，先利用flink搭建一套流式計算系統。然後自己寫乙個抓包程式抓redis監聽埠的資料，抓到資料後往kafka裡丟。
接下來，流式計算系統消費kafka裡的資料，進行資料統計即可，也能達到監控熱key的目的。
(2)通知系統做處理
在這個角度，有讚用的是上面的解決方案一:利用二級快取進行處理。
有讚在監控到熱key後，hermes服務端集群會通過各種手段通知各業務系統裡的hermes-sdk，告訴他們:"老弟，這個key是熱key，記得做本地快取。"
於是hermes-sdk就會將該key快取在本地，對於後面的請求。hermes-sdk發現這個是乙個熱key，直接從本地中拿，而不會去訪問集群。
除了這種通知方式以外。我們也可以這麼做，比如你的流式計算系統監控到熱key了，往zookeeper裡頭的某個節點裡寫。然後你的業務系統監聽該節點，發現節點資料變化了，就代表發現熱key。最後往本地快取裡寫，也是可以的。
redis的大key和熱key問題
redis的大key和熱key實際上就是經常被訪問的key或者占用空間比較大的key。有什麼影響？舉個栗子，比如說某個明星出軌了，這個明星的搜尋量就會暴增，對redis造成很大的衝擊。redis檢視大key命令 redis cli bigkeys redis檢視熱key命令 redis cli ho...
Redis中大key問題，熱key問題的解決方案
遇到大key 熱key問題，主要是去拆分 大key問題 業務場景中經常會有各種大key的情況，比如 1.單個簡單的key儲存的value很大 例如排行榜資訊，key是固定的，value排行榜幾十萬的資料 2.hash set zset list中儲存過多的元素 以萬為單位 由於redis是單執行緒執...
Redis為什麼快，熱key解決
redis的速度非常的快，單機的redis就可以支撐每秒10幾萬的併發，相對於mysql來說，效能是mysql的幾十倍。速度快的原因主要有幾點 完全基於記憶體操作 c語言實現，優化過的資料結構，基於幾種基礎的資料結構，redis做了大量的優化，效能極高 使用單執行緒，無上下文的切換成本 基於非阻塞的...