這個開發實際開發中還是常見的

方案一：新增過期時間，不過還是有延遲的，有校時間內還會讀取，無法一致性。

方案二：定時的Task把資料查詢結果，提前寫入快取，但是即使這樣還是有延遲。

方案三：在任何資料操作，增刪改查前，清理快取，同時重新快取最新的副本。

最終方案：方案出二和方案三組合使用。

1 不建議快取和資料庫強一致

(1) 在快取作為提升系統性能手段的背景下，不需要保證資料庫和快取的強一致性。如果非要保證二者的強一致性，會增大系統的複雜度

(2) 如果更新資料庫成功，再更新快取。此時存在兩種情況：更新快取成功則萬事大吉。更新快取失敗，沒有關係，等待快取失效，此處要合理設定失效時間

(3) 如果更新資料庫失敗，則操作失敗，重試或者等待使用者重新發起

(4) 資料庫是持久化資料，是操作成功還是失敗的判斷依據。快取是提升效能的手段，允許短時間和資料庫的不一致

(5) 在網際網路架構中，很少追求強一致性，一般都是追求最終一致性

2 問題本質

如果非要保證快取和資料庫的一致性，本質上是在解決分散式一致性問題。

分散式一致性問題解決方案有很多，可以選擇比如兩階段提交，TCC，本地訊息表，MQ事務性訊息等方案。

先舉兩個例子，都是我做過的專案，應用場景都非常簡單：

曾經做過的一個保費試算的專案，業務場景是根據使用者基本資訊+費率做計算，得到一個保費值，如果不瞭解這個業務場景的話，可以看做【使用者輸入】+【資料庫資料】+【一定的計算】=【結果】；這些資料複雜而且多，使用頻繁，但是每個產品的費率資料，幾乎是不會改變的（新增修改刪除都不會有）：這些資料被我們放在Redis中，而且設定成永不失效；因為資料不會修改，那麼資料庫和快取中的資料肯定是一樣的。

現在做的專案中的一個功能，簡單描述業務場景：系統從N個業務系統中抽取資料，並做加工整合，加工完成後更新到資料庫中；這個場景也比較有特點，資料時效性要求很低（資料加工到資料庫已經晚了一天），資料變化的時間固定且唯一（批處理每天固定時間進行，只有一個批處理執行緒在跑）；於是我們採用了一個比較保守的策略，就是設定資料在Redis中的過期時間；等資料過期後，當查詢的時候發現數據不在快取中，再從資料庫中查詢出來後放入快取。

現在想一想Redis中資料的更新策略有哪些（或者說快取更新策略）？

給快取設定過期時間，是我認為比較好的方式（這裡不討論快取雪崩的問題），這個【比較好】是在實現難度和資料一致性之間找到了一個平衡點；實現起來非常簡單，但是可能在資料變化後，快取失效前的這段時間，資料庫和快取之間的資料是不一致的（但最終會一致）。

先更新資料庫，再更新快取：有兩個比較大的問題，一是多執行緒的時候，可能會造成資料庫和快取資料的不一致，而且這個不一致可能會是長期的。二是如果更新操作比較多的話，會頻繁地更新快取。

A執行緒：set 資料庫 key=1；B執行緒：set 資料庫 key=100；B執行緒：set 快取 key=100；A執行緒：set 快取 key=1；（實際上，應該等於100，這樣就造成了快取和資料庫中的資料不一致，並且如果資料不再更新，那麼會使長期不一致）

先更新資料庫，再刪快取：一樣的道理，大家可以自己想一想這個過程。

有些人可能覺得這個機率很小，怎麼可能有這麼巧的事情，恰好都是A做到一半，B插進來把全部的事情做完，A再去做後一半的操作；但是機率小，也是可能發生的，不得不考慮。

不過我認為，架構越複雜也越容易出錯，還不如根據實際的場景和團隊的開發水平，合理選擇快取的使用，並給快取設定合理的過期時間。