《Redis Mysql 雙寫一致性問題》

一：序

　　- 最近在對數據作緩存時候，會涉及到如何保證 數據庫/Redis 一致性問題。

　　- 恰好今天來總結下 一致性問題 產生的問題，和可能存在的解決方案。

 

二：（更新策略）-  先更新數據庫，後更新緩存

　　- 產生的問題

　　　　- 

　　　　- 由上面流程圖可知道，請求A更新緩存應該比請求B更新緩存早纔對，可是由於網絡等緣由，B卻比A更早更新了緩存。

　　　　- 這就致使了髒數據，所以不考慮 先更新數據庫，後更新緩存 這個更新策略。

 

三：（更新策略）-  先刪除緩存，在更新數據庫

　　- 產生的問題

　　　　- 

　　　　- 若是同時有一個請求A進行更新操做，另外一個請求B進行查詢操做。

　　　　- 就會致使不一致的情形出現。並且，若是不採用給緩存設置過時時間策略，該數據永遠都是髒數據。

 

四：（更新策略）-  先更新數據庫，在刪除緩存

　　- FaceBook 也是採用這種方式。

　　- 固然，這種方式也會產生數據不一致問題。

　　　　- （1）緩存恰好失效

　　　　-（2）請求A查詢數據庫，得一箇舊值

　　　　-（3）請求B將新值寫入數據庫

　　　　-（4）請求B刪除緩存

　　　　-（5）請求A將查到的舊值寫入緩存

　　- 前提是 寫操做耗時必定是低於 讀操做的，在通常的條件下，這時不可能得。

 

五：小結

　　- 這裏只分析了日常可能想到的更新策略的分析。

　　- 其實，要解決數據一致性的問題，仍是要根據具體業務來具體判斷。

　　- 強一致性的，那麼就須要悲觀鎖，使得一致。

　　- 同時還有 延時雙寫/延時雙刪 等策略。其實都是爲了根據自身業務來進行的操做。

　　- 知道了這些策略可能帶來的問題，也就能夠在合適的業務下選擇合適的策略來知足咱們的需求。