文章目錄

• 場景
• 思考與方案

場景

營銷系統中經常會有重構一個活動的需求，有時需要推翻原來的方案重新制定新的策略，就需要考慮新舊資料的相容，若存在快取的話，也需要考慮快取的更新，尤其是對於使用者流量比較大的活動，下面是一個細化的場景：

舊活動A有著很大的使用者流量，QPS經常輕易達到900，新的需求是把舊活動A重構成活動B，同時新增了一部分功能，下面是技術方案的簡化點：

• 舊錶tab需要新加一個欄位field來適應新的活動B，同時要做到舊活動A對field欄位的相容
• 業務中需要增加新的快取替代已有快取內容
• 為了保證舊請求能在部署過程中正常請求，所以需要對所有介面增加V2版本介面

思考與方案

先說一下發布流程，便很容易發現具體的問題

上面的技術方案本質上考慮了以下三點：

1. 新業務需要相容舊資料，同時釋出過程中舊的請求可以相容新的資料

2. DB與快取的一致性保證

   • 快取更新

     由於新業務與舊業務邏輯相差較大，所以在原有快取的基礎上新增加了快取，但由於老活動在快取中，而新的pc端進行修改，只會清新的快取不會清老的快取，這樣會導致老快取資訊不對，所以必須在清新的快取之前清除老的快取內容

   • 快取擊穿與快取雪崩

     程式碼業務中需要考慮快取擊穿，為了克服快取雪崩，本專案選擇時間視窗在凌晨進行釋出就有了一定的過渡，不會對DB產生較大的壓力

   • 併發可能導致的DB與快取不一致性

     本專案採用的是先刪快取，再更更新資料庫的方式，這樣就會有執行緒安全問題，如：

     （1）請求A進⾏行行寫操作，刪除快取

     （2）請求B查詢發現快取不存在

     （3）請求B去資料庫查詢得到舊值

     （4）請求B將舊值寫入快取

     （5）請求A將新值寫入資料庫

     解決方式是延時雙刪

3. 索引與併發的考慮