資料讀取的時候：
先查快取，快取查不到查資料庫，然後把查到的結果放到快取中。這些都基本上沒有爭議。
但是資料更新的時候：
到底是先更新資料庫，還是再更新（or刪除）快取
or 先更新（or刪除）快取，再更新資料庫。
一直存在很大的爭議。幾種實現方式都會出現資料一致性問題。
我就說說目前我們系統是怎麼做的：
0、先確認快取命中率。不要動不動就上快取，有些快取命中率根本毫無意義，比如涉及到和賬戶相關的資產、訂單等資訊，就算放入快取中，只有使用者自己會去查自己的資訊，命中率極低。
一般是把與賬戶無關，且查詢量較大的放入快取中。
1、快取設定過期時間，保證最終一致性。
2、先更新資料庫，再刪除快取。
可能會出現更新資料庫後，刪除快取失敗，導致快取是舊資料，資料庫是新資料，出現不一致性。
但是這種概率非常低。
而且刪除快取失敗後，我們也可以做一些處理。
為什麼是刪除快取，而不是更新快取。
因為快取不一定直接是資料庫中的內容，有可能是多個字段計算出來的，如果每次更新都去寫快取，會導致效能消耗。
為什麼不是先刪除快取，再更新資料庫。
因為先刪除快取，如果在更新操作還沒commit的時候，另外乙個執行緒進來讀取資料，快取查不到，查資料庫並放入快取。然後第乙個更新操作commit了。
導致快取是舊資料，而資料庫是新資料。且不會像前面提到的刪除快取失敗那樣方便做處理。
如果業務要求強一致性，則盡可能不用快取。
併發一致性問題
常見併發併發一致性問題包括 丟失的修改 不可重複讀 讀髒資料 幻影讀 幻影讀在一些資料中往往與不可重複讀歸為一類 2.2.1.1 丟失修改 下面我們先來看乙個例子，說明併發操作帶來的資料的不一致性問題。考慮飛機訂票系統中的乙個活動序列 甲售票點 甲事務 讀出某航班的機票餘額a,設a 16.乙售票點 ...
快取一致性問題討論
在資料庫與快取之間的一致性問題?最好的是 先寫資料庫,再刪除快取.原因 寫資料庫之後證明寫成功了,順便把快取刪除了.寫成功之後拿到的資料就是最新的.寫資料庫失敗了,快取沒刪除,還是原來的資料,無傷大雅,寫失敗了,刪除快取成功了?這種事情不會發生的,即使發生了,也沒有問題,查庫,還是原來的資料.問題來...
redis快取一致性問題
1 不一致產生的原因？我們在是使用redis過程中，通常會這樣做，先讀取快取，如果快取不存在，則讀取資料庫。不管是先寫庫，再刪除快取 還是先刪除快取，再寫庫，都有可能出現資料不一致的情況。因為寫和讀是併發的，沒法保證順序，如果刪除了快取，還沒有來得及寫庫，另乙個執行緒就來讀取，發現快取為空，則去資料...