一、熱點key問題
1、商品秒殺、熱點新聞、熱點評論等讀多寫少的場景，可能會造成一個較大的請求Redis量，這種情況下就會造成熱點Key問題。
2、請求分片集中，超過單臺Redis伺服器的效能極限。
手動分片或者custer分片切分，剛好一致性hash落入同一臺redis伺服器，資料傾斜，如果瞬間訪問量過大，超過機器瓶頸。快取擊穿，壓垮redis伺服器，導致大量請求直接發往後端服務，進一步導致後端服務雪崩。
二、識別熱Key
1、憑藉個人經驗，結合業務場景，判斷哪些是熱Key。
比如華為新機發售，那麼我們可以判斷華為手機這個sku就是熱Key。
2、架構或者redis封裝，程式碼記錄上報ELK。
架構層負責上報，定時把收集到的資料上報到統一的服務進行聚合計算，這樣我們就可以找到那些熱點Key。
3、服務代理層上報。
如果是在redis前面有一個代理層，那麼我們可以在代理層進行收集上報，也是可以找到熱點Key。
4、使用redis自帶的命令。
例如monitor、redis-cli加上--hotkeys選項等，不過這種方式執行起來很慢，可能會降低redis的處理請求的效能，慎用。
monitor命令：可以實時抓取出redis伺服器接收到的命令，然後寫程式碼統計出熱Key，也有現成的分析工具可以使用。
5、redis節點抓包分析。
抓包redis的埠和協議，然後寫程式碼進行上報統計。
三、如何解決熱Key問題？
1、Redis叢集擴容：增加分片副本，分攤客戶端發過來的讀請求；資料傾斜則需要重新設計key。
2、使用二級快取，即JVM本地快取，減少Redis的讀請求。
例如使用Caffeine+redis 實現二級快取，先從本地快取中取，取不到再去redis中去取。當然也可以使用其它框架，如ehcache、甚至一個HashMap都可以。
四、大key問題