緩存擊穿這個詞語在很多程序開發者來講是再熟悉不過了。當下互聯網大流量的環境下，緩存幾乎可以說是在當前軟件開發應用中必不可少的一點了。
先簡單介紹下業務場景，在渠道引流的過程中，下放引流利益點聲明，引流之後針對完成任務的有效用戶進行之前承諾利益點的發放，承諾有效期自然周有效。 以此引流拉新業務爲目標，程序上分爲四大模塊，分別是 承諾聲明利益點的展示模塊、千人千面實時分析模塊、分析結果業務管理模塊、利益點發放模塊。
此次事件發生在業務管理模塊， 按業務聲明訴求，當用戶實時訪問合作方系統時，會實時展示出渠道引流利益點，引導用戶進入我們系統，轉換成我司的有效用戶。利益點承諾本週有效。服務系統內部流程大體如圖：
此次事件發生在日常期間，因爲結果自然周有效緩存key設計爲PRE_userId_yyyy_第N周，當自然週末凌晨，緩存key大批量失效，流程直接打到數據庫，數據庫查詢和寫入量激增，幾十萬的寫入直接把庫壓死，直接導致數據庫連接瞬間打滿數據庫不可用。
解決方案大部分在上圖已經標記了，包括業務的降級和限流等相關措施，另外還有一點很重要的是緩存大批量到期問題沒有在上圖說明，關於緩存到期問題，我們採用的是緩存雙週記錄法，也就是寫緩存的時候同步寫入當月緩存之後，在提交MQ發送結果的task任務中自降級實現另一份緩存的寫入 ，希入key爲當前周+1，緩存有效期按當週剩餘時間+用戶哈希取模%分段閾值*步長（分段閾值和步長均可動態運行時覆蓋調整，視具體業務週期而定）
下面說下之前跟朋友聊的時候有的一些問題如果你也有類似想法可以考慮下下面的建議
緩存擊穿這種問題我也遇到過，但是我怎麼沒有你這麼多的問題呢，我那啥事也沒有啊。對於有此類想法的朋友，我建議你把你現在的業務系統結構整理一下，然後按流量放大10倍甚至是1000倍之後再考慮下這個問題。我們這個系統 日常流量大概在QPS大概在2-5W之間，大規模促銷引流的時候，峯值大概在140W左右。
另外可能有人沒有看明白我們這個系統的主要作用在哪，其實很簡單，它屬於千人千面輸出的一個最上層，對接千人千面進行分析，然後保存分析結果，直接業務有效期結束之前要儘可能的保證查詢結果的冪等性。按上面的業務就是承諾的和最後下發的利益點要相同
個人感受：大流量就像是放大鏡一樣，在放大到我們發現問題太多的時候 ，基本上也就是你的系統達到瓶頸的時候了。不同的流量階段會有不同的設計方案，如果我們想了解我們系統的閾值的話。大流量或許是一個很好的手段。
公衆號同步推送：大流量放大鏡下看緩存擊穿事件