1、使用者消費的資料遠大于生産的資料（熱賣商品、熱點新聞、熱點評論、明星直播）。
在日常工作生活中一些突發的的事件，例如：雙十一期間某些熱門商品的降價促銷，當這其中的某一件商品被數萬次點選浏覽或者購買時，會形成一個較大的需求量，這種情況下就會造成熱點問題。
同理，被大量刊發、浏覽的熱點新聞、熱點評論、明星直播等，這些典型的讀多寫少的場景也會産生熱點問題。
2、請求分片集中，超過單 Server 的性能極限。
在服務端讀資料進行通路時，往往會對資料進行分片切分，此過程中會在某一主機 Server 上對相應的 Key 進行通路，當通路超過 Server 極限時，就會導緻熱點 Key 問題的産生。
二、熱點Key問題的危害
1、流量集中，達到實體網卡上限。
2、請求過多，緩存分片服務被打垮。
3、DB 擊穿，引起業務雪崩。
如前文講到的，當某一熱點 Key 的請求在某一主機上超過該主機網卡上限時，由于流量的過度集中，會導緻伺服器中其它服務無法進行。
如果熱點過于集中，熱點 Key 的緩存過多，超過目前的緩存容量時，就會導緻緩存分片服務被打垮現象的産生。
當緩存服務崩潰後，此時再有請求産生，會緩存到背景 DB 上，由于DB 本身性能較弱，在面臨大請求時很容易發生請求穿透現象，會進一步導緻雪崩現象，嚴重影響裝置的性能。
三、解決方案通常的解決方案主要集中在對用戶端和 Server 端進行相應的改造。
1、服務端緩存方案
首先 Client 會将請求發送至 Server 上，而 Server 又是一個多線程的服務，本地就具有一個基于 Cache LRU 政策的緩存空間。
當 Server 本身就擁堵時，Server 不會将請求進一步發送給 DB 而是直接傳回，隻有當 Server 本身暢通時才會将 Client 請求發送至 DB，并且将該資料重新寫入到緩存中。
此時就完成了緩存的通路跟重建。
但該方案也存在以下問題：
● 緩存失效，多線程建構緩存問題
● 緩存丢失，緩存建構問題
● 髒讀問題
2、使用 Memcache、Redis 方案
該方案通過在用戶端單獨部署緩存的方式來解決熱點 Key 問題。
使用過程中 Client 首先通路服務層，再對同一主機上的緩存層進行通路。
該種解決方案具有就近通路、速度快、沒有帶寬限制的優點，但是同時也存在以下問題：
● 記憶體資源浪費
3、使用本地緩存方案
使用本地緩存則存在以下問題：
● 需要提前獲知熱點
● 緩存容量有限
● 不一緻性時間增長
● 熱點 Key 遺漏
傳統的熱點解決方案都存在各種各樣的問題，那麼究竟該如何解決熱點問題呢？
4、讀寫分離方案解決熱讀
架構中各節點的作用如下：
● SLB 層做負載均衡
● Proxy 層做讀寫分離自動路由
● Master 負責寫請求
● ReadOnly 節點負責讀請求
● Slave 節點和 Master 節點做高可用
實際過程中 Client 将請求傳到 SLB，SLB 又将其分發至多個 Proxy 内，通過 Proxy 對請求的識别，将其進行分類發送。
例如，将同為 Write 的請求發送到 Master 子產品内，而将 Read 的請求發送至 ReadOnly 子產品。
而子產品中的隻讀節點可以進一步擴充，進而有效解決熱點讀的問題。
讀寫分離同時具有可以靈活擴容讀熱點能力、可以存儲大量熱點Key、對用戶端友好等優點。
5、熱點資料解決方案
該方案通過主動發現熱點并對其進行存儲來解決熱點 Key 的問題。
首先 Client 也會通路 SLB，并且通過 SLB 将各種請求分發至 Proxy 中，Proxy 會按照基于路由的方式将請求轉發至後端的 Redis 中。
在熱點 key 的解決上是采用在服務端增加緩存的方式進行。
具體來說就是在 Proxy 上增加本地緩存，本地緩存采用 LRU 算法來緩存熱點資料，後端 db 節點增加熱點資料計算子產品來傳回熱點資料。
● Proxy 架構的主要有以下優點：
● Proxy 本地緩存熱點，讀能力可水準擴充
● DB 節點定時計算熱點資料集合
● DB 回報 Proxy 熱點資料
● 對用戶端完全透明，不需做任何相容
四、熱點 key 處理1、熱點資料的讀取
在熱點 Key 的處理上主要分為寫入跟讀取兩種形式，在資料寫入過程當 SLB 收到資料 K1 并将其通過某一個 Proxy 寫入一個 Redis，完成資料的寫入。
假若經過後端熱點子產品計算發現 K1 成為熱點 key 後， Proxy 會将該熱點進行緩存，當下次用戶端再進行通路 K1 時，可以不經 Redis。
最後由于 proxy 是可以水準擴充的，是以可以任意增強熱點資料的通路能力。
2、熱點資料的發現
對于 db 上熱點資料的發現，首先會在一個周期内對 Key 進行請求統計，在達到請求量級後會對熱點 Key 進行熱點定位，并将所有的熱點 Key 放入一個小的 LRU 連結清單内，在通過 Proxy 請求進行通路時，若 Redis 發現待訪點是一個熱點，就會進入一個回報階段，同時對該資料進行标記。
DB 計算熱點時，主要運用的方法和優勢有：
1、基于統計閥值的熱點統計
2、基于統計周期的熱點統計
3、基于版本号實作的無需重置初值統計方法
4、DB 計算同時具有對性能影響極其微小、記憶體占用極其微小等優點
五、方案對比通過上述對比分析可以看出，在解決熱點 Key 上較傳統方法相比都有較大的提高，無論是基于讀寫分離方案還是熱點資料解決方案，在實際處理環境中都可以做靈活的水準能力擴充、都對用戶端透明、都有一定的資料不一緻性。
此外讀寫分離模式可以存儲更大量的熱點資料，而基于 Proxy 的模式有成本上的優勢。
原文釋出時間為：2018-11-27
本文作者：梁盼
本文來自雲栖社群合作夥伴“
Java後端技術”，了解相關資訊可以關注“
”。