寫請求來了，要更新資料庫和快取，一前一後更新，就可能導致快取和db中的資料在一段時間內不一致。
你只要用快取，就可能會涉及到快取與資料庫雙儲存雙寫，你只要是雙寫，就一定會有資料一致性的問題，那麼你如何解決一致性問題？
一般來說，就是如果你的系統不是嚴格要求快取+資料庫必須一致性的話，快取可以稍微的跟資料庫偶爾有不一致的情況，
如果是強一致性，讀請求和寫請求序列化，串到乙個記憶體佇列裡去，這樣就可以保證一定不會出現不一致的情況（效率極低。）
序列化之後，就會導致系統的吞吐量會大幅度的降低，用比正常情況下多幾倍的機器去支撐線上的乙個請求。
還有一種方式就是可能會暫時產生不一致的情況，但是發生的機率特別小，就是先更新資料庫，然後再刪除快取。
這種情況不存在併發問題麼？
不是的。假設這會有兩個請求，乙個請求a做查詢操作，乙個請求b做更新操作，那麼會有如下情形產生
（1）快取剛好失效
（2）請求a查詢資料庫，得乙個舊值
（3）請求b將新值寫入資料庫
（4）請求b刪除快取
（5）請求a將查到的舊值寫入快取
ok，如果發生上述情況，確實是會發生髒資料。
然而，發生這種情況的概率又有多少呢？
發生上述情況有乙個先天性條件，就是步驟（3）的寫資料庫操作比步驟（2）的讀資料庫操作耗時更短，才有可能使得步驟（4）先於步驟（5）。可是，大家想想，資料庫的讀操作的速度遠快於寫操作的（不然做讀寫分離幹嘛，做讀寫分離的意義就是因為讀操作比較快，耗資源少），因此步驟（3）耗時比步驟（2）更短，這一情形很難出現。
如何解決上述併發問題？
首先，給快取設有效時間是一種方案。其次，採用非同步延時刪除策略，保證讀請求完成以後，再進行刪除操作。
Redis如何保證快取與資料庫的雙寫一致性？
原創 只要用快取，就可能會涉及到快取與資料庫雙儲存雙寫，你只要是雙寫，就一定會有資料一致性的問題 那麼，如何解決一致性問題？一般來說，如果允許快取可以稍微的跟資料庫偶爾有不一致的情況，也就是說如果你的系統不是嚴格要求快取 資料庫必須保持一致性的話，最好不要做這個方案。即 讀請求和寫請求序列化，串到乙...
redis如何保證快取與資料庫的一致性
redis怎麼保證快取與資料庫的一致性 為啥會不一致 先操作快取，在寫資料庫成功之前，如果有讀請求發生，可能導致舊資料入快取，引發資料不一致。資料庫有資料，快取沒有資料 資料庫有資料，快取也有資料，資料不相等 資料庫沒有資料，快取有資料。首先嘗試從快取讀取，讀到資料則直接返回 如果讀不到，就讀資料庫...
redis快取如何同步資料庫
redis快取如何同步資料庫 redis mysql模式 讀 服務程式先從快取中讀取資料，如果命中，則將資料讀出。如果未命中，則在資料庫中讀取資料，然後將資料寫入到快取中去。更新資料 常見的模式是先到資料庫中寫入，然後刪除快取中的資料。產生的不一致 讀 只是讀資料一般不會有不一致出現。更新 1 資料...