一：序
- 最近在對資料做快取時候，會涉及到如何保證 資料庫/redis 一致性問題。
- 剛好今天來總結下 一致性問題 產生的問題，和可能存在的解決方案。
二：（更新策略）- 先更新資料庫，後更新快取
- 產生的問題
- 由上面流程圖可知道，請求a更新快取應該比請求b更新快取早才對，但是因為網路等原因，b卻比a更早更新了快取。
- 這就導致了髒資料，因此不考慮 先更新資料庫，後更新快取 這個更新策略。
三：（更新策略）- 先刪除快取，在更新資料庫
- 產生的問題
- 如果同時有乙個請求a進行更新操作，另乙個請求b進行查詢操作。
- 就會導致不一致的情形出現。而且，如果不採用給快取設定過期時間策略，該資料永遠都是髒資料。
四：（更新策略）- 先更新資料庫，在刪除快取
- facebook 也是採用這種方式。
- 當然，這種方式也會產生資料不一致問題。
- （1）快取剛好失效
-（2）請求a查詢資料庫，得乙個舊值
-（3）請求b將新值寫入資料庫
-（4）請求b刪除快取
-（5）請求a將查到的舊值寫入快取
- 前提是寫操作耗時一定是低於 讀操作的，在一般的條件下，這時不可能得。
五：小結
- 這裡只分析了平常可能想到的更新策略的分析。
- 其實，要解決資料一致性的問題，還是要根據具體業務來具體判斷。
- 強一致性的，那麼就需要悲觀鎖，使得一致。
- 同時還有延時雙寫/延時雙刪 等策略。其實都是為了根據自身業務來進行的操作。
- 知道了這些策略可能帶來的問題，也就可以在合適的業務下選擇合適的策略來滿足我們的需求。
redis 雙寫一致性
首先，快取由於其高併發和高效能的特性，已經在專案中被廣泛使用。在讀取快取方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作。但是在更新快取方面，對於更新完資料庫，是更新快取呢，還是刪除快取。又或者是先刪除快取，再更新資料庫，其實大家存在很大的爭議。目前沒有一篇全面的部落格，對這幾種方案進行解析。於...
Redis 雙寫一致性
首先，快取由於其高併發和高效能的特性，已經在專案中被廣泛使用。在讀取快取方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作。但是在更新快取方面，對於更新完資料庫，是更新快取呢，還是刪除快取。又或者是先刪除快取，再更新資料庫，其實大家存在很大的爭議。目前沒有一篇全面的部落格，對這幾種方案進行解析。於...
快取雙寫一致性方案
首先，快取由於其高併發和高效能的特性，已經在專案中被廣泛使用。在讀取快取方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作。但是在更新快取方面，對於更新完資料庫，是更新快取呢，還是刪除快取。又或者是先刪除快取，再更新資料庫，其實大家存在很大的爭議。目前沒有一篇全面的部落格，對這幾種方案進行解析。於...