緩存一致性探討(雙刪法及其改進方案)

　　提到緩存，作為服務端的開發人員並不陌生，無論是本地緩存還是分散式緩存，其目的都是為了提高系統響應速度的同時減輕資料庫的查詢壓力；在緩存開發中有個問題必需要解決，那就是“緩存一致性問題”！ 

 緩存一致性

 　　軟體開發中的緩存一致性是指緩存中的數據要和資料庫(或者數據提供方)的數據保持一致

關於緩存

　　我們必需要明白一點，並不是所有的場景下都適合加入緩存，當數據量較小時合理利用資料庫的索引來加快查詢速度來的更加方便。除非

1. 1. 數據量比較大單純資料庫查詢性能無法滿足性能要求  
   2. 數據的查詢比較頻繁且更新頻率不高
   3. 業務上必需能夠容忍短暫的數據不一致的情況，如果是類似於銀行金額等要求必須實時一直的情況，請慎用緩存

緩存一致性方案探討 

     你是否被問過這個問題：當數據發生變更時，是先更新緩存還是先更新資料庫？

  這是一個在面試中經常被問到的問題，一般來講，這個時候無論你回答先更新哪個答案都是錯誤的。

• •   先更新緩存，那萬一更新完緩存，資料庫更新失敗了怎麼辦？
  •   先更新資料庫，如果更新資料庫成功，更新緩存失敗了怎麼辦？

  無論上述兩種情況任何一種出現，都會導致緩存和資料庫的數據不一致的情況

為瞭解決上述問題，我們一般會想到 

  “先刪除緩存，然後再更新資料庫，這樣即使更新失敗了，緩存也不會出現臟數據”真的是這樣嗎？

在單線程操作的情況下確實是這樣的，但是實際應用中我們沒法控制客戶端請求是線性運行的，所以先刪除緩存在更新資料庫的方案是不可行的，容易產生臟數據。如圖 

　　 緩存雙刪

    為了保證緩存和資料庫的數據一致

　　　　先刪除緩存--->更新資料庫--->再次刪除緩存數據

　　如上圖所示，雙刪也可能會存在問題，比如T5時刻刪除了緩存，T6時刻卻將T3時刻讀取的數據更新到了緩存，從而導致緩存數據與資料庫數據不一致； 

針對上面存在的問題，我們可以採取如下方案

改進方案

　　一.鎖加延時刪除

 　　流程說明：

• 上圖鎖並不能解決線程安全問題，而是為了減少查詢線程查詢資料庫後更新緩存的次數（鎖驗證），若考慮到操作的便利性也可以去掉流程中的鎖相關環節；
• 為了提高更新線程的併發效率，上圖中的鎖可以使用累加鎖標記。預設是0（無鎖），以後每一個更新線程獲取鎖時都對鎖計數+1，更新線程釋放鎖的時候鎖計數-1；
• 多個更新線程的併發及順序問題可以交給資料庫來控制也可以在業務中額外增加分散式鎖或者有序隊列來實現
• 查詢線程中的獲取鎖可以理解為判斷當前鎖標記的計數是否等於0；
• 更新線程中先獲取 鎖再刪除是考慮到如果先刪除緩存的話在獲取 鎖之前，查詢線程會額外增加一次線程更新操作；
• 在釋放鎖之後再次延時刪除緩存是為了避免在查詢線程在查詢完資料庫後，更新線程更新了資料庫的值，此時查詢線程將剛剛查詢到的舊數據維護進緩存；
• 在更新和查詢都比較頻繁的情況下，更新的時候，根據數據的唯一標識，將操作添加進有序隊列中進行處理。讀取數據的時候，如果發現數據不在緩存中，那麼將重新讀取數據+更新緩存的操作，根據唯一標識也發送一個有序隊列中，但是要考慮到請求效率和超時問題。

寫在最後，鑒於筆者能力有限，上述方案獲取存在著不足，如果您發現有不足的地方，歡迎留言討論