下面這篇文章帶大家了解一下Redis中的熱點Key，介紹一下熱點Key產生的原因、發現熱點key的方式、熱點Key的解決方案，希望對大家有幫助！
#1、用戶消費的資料遠大於生產的資料
熱key問題就是某個瞬間有大量的請求去訪問redis上某個固定的key，導致緩存擊穿，請求都打到了DB上，壓垮了緩存服務和DB服務，進而影響應用程式服務可用的可用性。 【相關推薦：Redis影片教學】
最常見的就是微博的熱搜，像是XX明星結婚/出軌。那麼關於XX明星的Key就會瞬間增大，就會出現熱數據問題。微博也時不時的來個崩潰。
同理，被大量刊物、瀏覽的熱門新聞、熱門評論、明星直播等，這些典型的讀多寫少的場景也會產生熱門議題。
2、請求分片集中，超過單一Server的效能極限
在服務端讀取資料進行存取時，往往會對數據進行分片切分，此過程中會在某一主機Server上對相應的Key進行訪問，當訪問超過Server極限時，就會導致熱點Key問題的產生。
#1、流量集中，達到實體網路卡上限。
當某一熱點 Key 的請求在某一主機上超過該主機網卡上限時，由於流量的過度集中，會導致伺服器中其它服務無法進行。
2、請求過多，快取分片服務被打垮。
如果熱點太集中，熱點 Key 的快取過多，超過目前的快取容量時，就會導致快取分片服務被打垮現象的產生。
3、DB 擊穿，引起業務雪崩。
當快取服務崩潰後，此時再有請求產生，會快取到後台DB 上，由於DB 本身效能較弱，在面臨大請求時很容易發生請求穿透現象，會進一步導致雪崩現象，嚴重影響設備的性能。
1、憑藉業務經驗，進行預估哪些是熱key
#其實這個方法還蠻有可行性的。例如某商品在做秒殺，那這個商品的key就可以判斷出是熱key。缺點很明顯，並非所有業務都能預估出哪些key是熱key。
2、在客戶端進行收集
這個方式就是在操作redis之前，加入一行程式碼進行資料統計。那麼這個資料統計的方式有很多種，也可以是傳送一個通知訊息給外部的通訊系統。缺點就是對客戶端程式碼造成入侵。
3、在Proxy層做收集
有些叢集架構是下面這樣的，Proxy可以是Twemproxy，是統一的入口。可以在Proxy層做收集上報，但缺點很明顯，並非所有的redis叢集架構都有proxy。
4、用redis自帶指令
redis-faina。但該指令在高並發的條件下，有記憶體增暴的隱患，還會降低redis的效能。 –hotkeys選項即可。但是該參數在執行的時候，如果key比較多，執行起來比較慢。 5、自己抓包評估
Redis客戶端使用TCP協定與服務端進行交互，通訊協定採用的是RESP。自己寫程式監聽端口，依照RESP協定規則解析數據，進行分析。缺點就是開發成本高，維修困難，有丟包可能性。
以上五種方案，各有優缺點。根據自己業務場景進行抉擇即可。
1、利用二級快取
例如利用ehcache、spring cache，甚至是一個HashMap都可以。在你發現熱key以後，把熱key載入到系統的JVM中。
針對這種熱key請求，會直接從jvm中取，而不會走到redis層。
假設此時有十萬個針對同一個key的請求過來,如果沒有本地緩存，這十萬個請求就直接懟到同一台redis上了。
現在假設，你的應用層有50台機器，OK，你也有jvm快取了。這十萬個請求平均分散開來，每台機器有2000個請求，會從JVM中取到value值，然後回傳資料。避免了十萬個請求懟到同一台redis上的情形。
2、讀寫分離
讀寫分離就是將同為Write 的請求傳送到 Master 模組內，而將Read 的請求傳送至ReadOnly 模組。
而模組中的唯讀節點還可以進一步擴充，把這個key，在多個redis上都存一份不。有熱key請求進來的時候，我們就在有備份的redis上隨機選取一台，進行存取取值，回傳資料。從而有效解決熱點讀取的問題。
讀寫分離同時具有可以靈活擴容讀熱點能力、可以儲存大量熱點Key、對客戶端友善等優點。
更多程式相關知識，請造訪：程式設計影片！ ！
以上是Redis中熱點Key是怎麼產生的？如何解決？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
