背景

電商場景促銷活動的會場頁由於經常集中在某個時間點進行“秒殺”促銷，這些頁面的QPS（伺服器每秒可以處理的請求量）往往特別高，資料庫通常無法直接支撐如此高QPS的請求，常見的解決方案是讓大部分相同資訊的請求都儘可能地壓在快取（cache）上來緩解資料庫（DB）的壓力，從而儘可能地去滿足高併發訪問的訴求（如圖2-1所示）。

在一次業務促銷過程中，運營給一大批使用者集中推送了一條訊息：10點鐘準時搶購一批遠低於市場價而且數量有限的促銷活動商品。由於確實物美價廉，使用者收到訊息之後10點鐘準時進入手機客戶端的會場頁進行瘋搶。幾分鐘內很多使用者進入會場頁，最終導致頁面異常，伺服器瘋狂報警。報警資訊顯示很多關於快取的異常，由於快取拿不到資料轉而會轉向資料庫去查詢資料，這樣資料庫更加難以支撐，整個業務叢集處於雪崩狀態（如圖2-2所示）。

此時快取到底發生了什麼問題？關注哪些方面可以有效地預防快取被擊穿導致雪崩的發生呢？

快取問題分析與解決過程

1. 首先檢視快取詳細日誌，發現有很多帶有“CacheOverflow”字樣的日誌，初步懷疑是觸發了快取限流。但是計算了快取的整體能力和當前訪問量情況：快取的機器數×單機能夠承受的QPS > 當前使用者訪問的最大QPS值，此時使用者訪問QPS並沒有超過快取之前的預算，怎麼也會觸發限流呢？
2. 進一步分析日誌，發現所有伺服器上限流日誌中快取機器IP貌似都是同一臺，說明大流量並沒有按預想平均分散在不同的快取機器上。回想前面提到的案例實際現象，發現確實有部分資料使用者的訪問請求都會觸發對快取中同一個key（熱點key）進行訪問，使用者訪問QPS有多大，則這個key的併發數就會有多大，而其他快取機器完全沒有分擔任何請求壓力，如圖2-3所示。
3. 然後緊急梳理出存在“熱點請求”的key，並快速接入“熱點本地快取”方案，然後迅速在下一場秒殺活動中進一步進行驗證，此時發現之前異常大幅度減少。不過還是有少量“CacheOverflow”字樣異常日誌。熱點key的請求都被“本地快取”攔截掉了，此時發現遠端QPS限流異常已經基本沒有了，這又是什麼原因呢？ 
   
   圖2-3 熱點key觸發單點限流
   仔細檢視快取單臺機器的網路流量監控，發現偶爾有網路流量過大超過單臺快取機器的情況（如圖2-4所示）。 
   
   圖2-4 網路流量監控
   說明快取中有某些key對應的value資料過大，導致儘管QPS不是很高，但是網路流量（QPS×單個value的大小）還是過大，觸發了快取單臺機器的網路流量限流。
4. 緊急梳理出存在“大value”的key，發現這些“大value”部分是可以精簡，部分是可以直接放入記憶體不用每次都遠端獲取的，經過一番梳理和優化之後，下次“秒殺”場景終於風平浪靜了。至此問題初步得到解決。

預防“快取被擊穿”總結

1. 評估快取是否滿足具體業務場景的請求流量，不是簡單地對預估訪問流量除以單臺快取的最大服務能力。
2. 如果使用的快取機制是按key的hash值雜湊到同一臺機器，則必須梳理出當前業務場景中被高併發訪問的那些key，看看這些key的併發訪問量是否會超過單臺機器的服務能力，如果超過則必須採取更多措施進行規避。
3. 除了關注key的併發訪問量外，還要關注key對應value的大小，如果key的併發訪問量×value大小 > 單臺快取機器的網路流量限制，則也需要採取更多措施進行資料精簡。

更多思考

1. 單個key的請求量不超過單臺快取機器的服務能力，但是如果多個key正好雜湊到同一臺機器，而且這幾個key的流量之和超過單臺機器的服務能力，我們該如何處理呢？
2. 單個key的併發訪問量×對應value大小 < 單臺快取機器的網路流量限制，但是如果多個key的併發訪問量×各自對應value大小 >單臺快取機器的網路流量限制，又該如何處理呢？

針對上述兩個問題，首先要做的是做好快取中元素key的訪問監控，一旦發現快取有QPS限流或者網路大小限流時，能夠迅速定位哪些key併發訪問量過大，或者哪些key返回的value大小較大，再結合快取的雜湊演算法，通過一定規則動態修改key值來自動將這些可疑的key平均雜湊到各臺快取機器上去，這樣就可以充分地利用所有快取機器來分攤壓力，保證快取叢集的最大可用能力，從而減少快取被擊穿的風險。