【開發】專案釋出引起的思考與總結
阿新 • • 發佈:2018-12-30
文章目錄
場景
營銷系統中經常會有重構一個活動的需求,有時需要推翻原來的方案重新制定新的策略,就需要考慮新舊資料的相容,若存在快取的話,也需要考慮快取的更新,尤其是對於使用者流量比較大的活動,下面是一個細化的場景:
舊活動A有著很大的使用者流量,QPS經常輕易達到900,新的需求是把舊活動A重構成活動B,同時新增了一部分功能,下面是技術方案的簡化點:
- 舊錶tab需要新加一個欄位field來適應新的活動B,同時要做到舊活動A對field欄位的相容
- 業務中需要增加新的快取替代已有快取內容
- 為了保證舊請求能在部署過程中正常請求,所以需要對所有介面增加V2版本介面
思考與方案
先說一下發布流程,便很容易發現具體的問題
上面的技術方案本質上考慮了以下三點:
-
新業務需要相容舊資料,同時釋出過程中舊的請求可以相容新的資料
-
DB與快取的一致性保證
-
快取更新
由於新業務與舊業務邏輯相差較大,所以在原有快取的基礎上新增加了快取,但由於老活動在快取中,而新的pc端進行修改,只會清新的快取不會清老的快取,這樣會導致老快取資訊不對,所以必須在清新的快取之前清除老的快取內容
-
快取擊穿與快取雪崩
程式碼業務中需要考慮快取擊穿,為了克服快取雪崩,本專案選擇時間視窗在凌晨進行釋出就有了一定的過渡,不會對DB產生較大的壓力
-
併發可能導致的DB與快取不一致性
本專案採用的是先刪快取,再更更新資料庫的方式,這樣就會有執行緒安全問題,如:
(1)請求A進⾏行行寫操作,刪除快取
(2)請求B查詢發現快取不存在
(3)請求B去資料庫查詢得到舊值
(4)請求B將舊值寫入快取
(5)請求A將新值寫入資料庫
解決方式是延時雙刪
-
-
索引與併發的考慮