一：序
- 最近在對數據做緩存時候，會涉及到如何保證 數據庫/Redis 一致性問題。
- 剛好今天來總結下 一致性問題 產生的問題，和可能存在的解決方案。
二：（更新策略）- 先更新數據庫，后更新緩存
- 產生的問題
- 
- 由上面流程圖可知道，請求A更新緩存應該比請求B更新緩存早才對，但是因為網絡等原因，B卻比A更早更新了緩存。
- 這就導致了臟數據，因此不考慮 先更新數據庫，后更新緩存 這個更新策略。
三：（更新策略）- 先刪除緩存，在更新數據庫
- 產生的問題
- 
- 如果同時有一個請求A進行更新操作，另一個請求B進行查詢操作。
- 就會導致不一致的情形出現。而且，如果不采用給緩存設置過期時間策略，該數據永遠都是臟數據。
四：（更新策略）- 先更新數據庫，在刪除緩存
- FaceBook 也是采用這種方式。
- 當然，這種方式也會產生數據不一致問題。
- （1）緩存剛好失效
-（2）請求A查詢數據庫，得一個舊值
-（3）請求B將新值寫入數據庫
-（4）請求B刪除緩存
-（5）請求A將查到的舊值寫入緩存
- 前提是 寫操作耗時一定是低於 讀操作的，在一般的條件下，這時不可能得。
五：小結
- 這里只分析了平常可能想到的更新策略的分析。
- 其實，要解決數據一致性的問題，還是要根據具體業務來具體判斷。
- 強一致性的，那么就需要悲觀鎖，使得一致。
- 同時還有 延時雙寫/延時雙刪 等策略。其實都是為了根據自身業務來進行的操作。
- 知道了這些策略可能帶來的問題，也就可以在合適的業務下選擇合適的策略來滿足我們的需求。