基於流式計算技術的緩存熱點自動發現
其實這裏關鍵的一點，就是對於這種熱點緩存，你的系統需要能夠在熱點緩存突然發生的時候，直接發現他，然後瞬間立馬實現毫秒級的自動負載均衡。
那麼我們就先來說說，你如何自動發現熱點緩存問題?首先你要知道，一般出現緩存熱點的時候，你的每秒併發肯定是很高的，可能每秒都幾十萬甚至上百萬的請求量過來，這都是有可能的。
所以，此時完全可以基於大數據領域的流式計算技術來進行實時數據訪問次數的統計，比如 Storm、Spark Streaming、Flink，這些技術都是可以的。
然後一旦在實時數據訪問次數統計的過程中，比如發現一秒之內，某條數據突然訪問次數超過了 1000，就直接立馬把這條數據判定爲是熱點數據，可以將這個發現出來的熱點數據寫入比如 Zookeeper 中。
我們自己的系統可以對 Zookeeper 指定的熱點緩存對應的 Znode 進行監聽，如果有變化他立馬就可以感知到了。
當然，你的系統如何判定熱點數據，可以根據自己的業務還有經驗值來就可以了。
大家看看下面這張圖，看看整個流程是如何進行的：
2、本地緩存
這個本地緩存，你用 Ehcache、Hashmap，在使用hashmap的時候，我們可能不斷的查詢，如果涉及到加鎖的操作，我們需要進行更加細粒化的操作，
最終我們通過分片細化了鎖的粒度，分散了鎖的衝突。
本地同時創建數百個 HashMap，當需要在某個 Key 上存取數據前通過 Hash 和取模找到其中一個 HashMap 然後進行操作，這樣將全局鎖分散到了數百個 HashMap 中，大大降低了操作衝突，也提升了整體的性能。
參考文章：
1、https://zhuanlan.zhihu.com/p/66807833?utm_source=tuicool&utm_medium=referral
2、http://developer.51cto.com/art/201905/596918.htm?utm_source=tuicool&utm_medium=referral
附原文：
爲什麼要用緩存集羣
啥叫熱 Key 和大 Value 呢?簡單來說，熱 Key，就是你的緩存集羣中的某個 Key 瞬間被數萬甚至十萬的併發請求打爆。
大 Value，就是你的某個 Key 對應的 Value 可能有 GB 級的大小，導致查詢 Value 的時候出現網絡相關的故障問題。
先來看看下面的一幅圖：
簡單來說，假設你手頭有個系統，他本身是集羣部署的，然後後面有一套緩存集羣，這個集羣不管你用 Redis Cluster，還是 Memcached，或者是公司自研緩存集羣，都可以。
那麼，這套系統用緩存集羣幹什麼呢?很簡單，在緩存裏放一些平時不怎麼變動的數據，然後用戶在查詢大量的平時不怎麼變動的數據的時候，不就可以直接從緩存裏走了嗎?
緩存集羣的併發能力是很強的，而且讀緩存的性能是很高的。舉個例子，假設你每秒有 2 萬請求，但是其中 90% 都是讀請求，那麼每秒 1.8 萬請求都是在讀一些不太變化的數據，而不是寫數據。
那此時你把數據都放在數據庫裏，然後每秒發送 2 萬請求到數據庫上讀寫數據，你覺得合適嗎?
當然不太合適了，如果你要用數據庫承載每秒 2 萬請求的話，那麼不好意思，你很可能就得搞分庫分表 + 讀寫分離。
比如你得分 3 個主庫，承載每秒 2000 的寫入請求，然後每個主庫掛 3 個從庫，一共 9 個從庫承載每秒 1.8 萬的讀請求。
這樣的話，你可能就需要一共是 12 臺高配置的數據庫服務器，這是很耗費錢的，成本非常高，而且很不合適。
大家看看下面的圖，來體會下這種情況：
所以，此時你完全就可以把平時不太變化的數據放在緩存集羣裏，緩存集羣可以採用 2 主 2 從，主節點用來寫入緩存，從節點用來讀緩存。
以緩存集羣的性能，2 個從節點完全可以用來承載每秒 1.8 萬的大量讀了，然後 3 個數據庫主庫就是承載每秒 2000 的寫請求和少量其他讀請求就可以了。
大家看看下面的圖，你耗費的機器瞬間變成了 4 臺緩存機器 + 3 臺數據庫機器 = 7 臺機器，是不是比之前的 12 臺機器減少了很大的資源開銷?
沒錯，緩存其實在系統架構裏是非常重要的組成部分。很多時候，對於那些很少變化但是大量高併發讀的數據，通過緩存集羣來抗高併發讀，是非常合適的。
這裏所有的機器數量、併發請求量都是一個示例，大家主要是體會一下這個意思就好，其目的主要是給一些不太熟悉緩存相關技術的同學一點背景性的闡述，讓這些同學能夠理解在系統裏用緩存集羣承載讀請求是什麼意思。
20 萬用戶同時訪問一個熱點緩存的問題
好了，背景是已經給大家解釋清楚了，那麼現在就可以給大家說說今天重點要討論的問題：熱點緩存。
我們來做一個假設，你現在有 10 個緩存節點來抗大量的讀請求。正常情況下，讀請求應該是均勻的落在 10 個緩存節點上的，對吧!
這 10 個緩存節點，每秒承載 1 萬請求是差不多的。然後我們再做一個假設，你一個節點承載 2 萬請求是極限，所以一般你就限制一個節點正常承載 1 萬請求就 OK 了，稍微留一點 Buffer 出來。
好，所謂的熱點緩存問題是什麼意思呢?很簡單，就是突然因爲莫名的原因，出現大量的用戶訪問同一條緩存數據。
舉個例子，某個明星突然宣佈跟某某結婚，這個時候是不是會引發可能短時間內每秒都是數十萬的用戶去查看這個明星跟某某結婚的那條新聞?
那麼假設那條新聞就是一個緩存，然後對應就是一個緩存 Key，就存在一臺緩存機器上，此時瞬時假設有 20 萬請求奔向那一臺機器上的一個 Key。
此時會如何?我們看看下面的圖，來體會一下這種絕望的感受：
這個時候很明顯了，我們剛纔假設的是一個緩存 Slave 節點最多每秒就是 2 萬的請求，當然實際緩存單機承載 5 萬~10 萬讀請求也是可能的，我們這裏就是一個假設。
結果此時，每秒突然奔過來 20 萬請求到這臺機器上，會怎麼樣?很簡單，上面圖裏那臺被 20 萬請求指向的緩存機器會過度操勞而宕機的。
那麼如果緩存集羣開始出現機器的宕機，此時會如何?接着，讀請求發現讀不到數據，會從數據庫裏提取原始數據，然後放入剩餘的其他緩存機器裏去。
但是接踵而來的每秒 20 萬請求，會再次壓垮其他的緩存機器。以此類推，最終導致緩存集羣全盤崩潰，引發系統整體宕機。
咱們看看下面的圖，再感受一下這個恐怖的現場：
基於流式計算技術的緩存熱點自動發現
其實這裏關鍵的一點，就是對於這種熱點緩存，你的系統需要能夠在熱點緩存突然發生的時候，直接發現他，然後瞬間立馬實現毫秒級的自動負載均衡。
那麼我們就先來說說，你如何自動發現熱點緩存問題?首先你要知道，一般出現緩存熱點的時候，你的每秒併發肯定是很高的，可能每秒都幾十萬甚至上百萬的請求量過來，這都是有可能的。
所以，此時完全可以基於大數據領域的流式計算技術來進行實時數據訪問次數的統計，比如 Storm、Spark Streaming、Flink，這些技術都是可以的。
然後一旦在實時數據訪問次數統計的過程中，比如發現一秒之內，某條數據突然訪問次數超過了 1000，就直接立馬把這條數據判定爲是熱點數據，可以將這個發現出來的熱點數據寫入比如 Zookeeper 中。
當然，你的系統如何判定熱點數據，可以根據自己的業務還有經驗值來就可以了。
大家看看下面這張圖，看看整個流程是如何進行的：
當然肯定有人會問，那你的流式計算系統在進行數據訪問次數統計的時候，會不會也存在說單臺機器被請求每秒幾十萬次的問題呢?
答案是否，因爲流式計算技術，尤其是 Storm 這種系統，他可以做到同一條數據的請求過來，先分散在很多機器裏進行本地計算，最後再彙總局部計算結果到一臺機器進行全局彙總。
所以幾十萬請求可以先分散在比如 100 臺機器上，每臺機器統計了這條數據的幾千次請求。
然後 100 條局部計算好的結果彙總到一臺機器做全局計算即可，所以基於流式計算技術來進行統計是不會有熱點問題的。
熱點緩存自動加載爲 JVM 本地緩存
我們自己的系統可以對 Zookeeper 指定的熱點緩存對應的 Znode 進行監聽，如果有變化他立馬就可以感知到了。
此時系統層就可以立馬把相關的緩存數據從數據庫加載出來，然後直接放在自己系統內部的本地緩存裏即可。
這個本地緩存，你用 Ehcache、Hashmap，其實都可以，一切都看自己的業務需求，主要說的就是將緩存集羣裏的集中式緩存，直接變成每個系統自己本地實現緩存即可，每個系統自己本地是無法緩存過多數據的。
因爲一般這種普通系統單實例部署機器可能就一個 4 核 8G 的機器，留給本地緩存的空間是很少的，所以用來放這種熱點數據的本地緩存是最合適的，剛剛好。
假設你的系統層集羣部署了 100 臺機器，那麼好了，此時你 100 臺機器瞬間在本地都會有一份熱點緩存的副本。
然後接下來對熱點緩存的讀操作，直接系統本地緩存讀出來就給返回了，不用再走緩存集羣了。
這樣的話，也不可能允許每秒 20 萬的讀請求到達緩存機器的一臺機器上讀一個熱點緩存了，而是變成 100 臺機器每臺機器承載數千請求，那麼那數千請求就直接從機器本地緩存返回數據了，這是沒有問題的。
我們再來畫一幅圖，一起來看看這個過程：
限流熔斷保護
除此之外，在每個系統內部，還應該專門加一個對熱點數據訪問的限流熔斷保護措施。
每個系統實例內部，都可以加一個熔斷保護機制，假設緩存集羣最多每秒承載4萬讀請求，那麼你一共有 100 個系統實例。
你自己就該限制好，每個系統實例每秒最多請求緩存集羣讀操作不超過 400 次，一超過就可以熔斷掉，不讓請求緩存集羣，直接返回一個空白信息，然後用戶稍後會自行再次重新刷新頁面之類的。
通過系統層自己直接加限流熔斷保護措施，可以很好的保護後面的緩存集羣、數據庫集羣之類的不要被打死，我們來看看下面的圖：
總結
具體要不要在系統裏實現這種複雜的緩存熱點優化架構呢?這個還要看你們自己的系統有沒有這種場景了。
如果你的系統有熱點緩存問題，那麼就要實現類似本文的複雜熱點緩存支撐架構。
但是如果沒有的話，那麼也別過度設計，其實你的系統可能根本不需要這麼複雜的架構。
如果是後者，那麼大夥兒就權當看看本文，來了解一下對應的架構思想好了。