1、問題：先存db還是先存redis？不管先存哪乙個都存在乙個存成功另乙個存失敗的情況，導致db與redis資料不一致。
解決辦法：
update: 刪除redis --> 更新db --> 下次查詢同步更新redis。
（1）刪redis失敗，不會更新db，資料一致。
（2）刪redis成功，更新db失敗，下次查詢將舊值更新到redis。
（3）刪redis成功，更新db成功，下次查詢更新新值到redis。
2、複雜情況：刪redis成功，但在update未提交的情況下，進來乙個查詢請求，將db舊值更新到了redis中。
解決辦法：非同步讀寫請求佇列。刪redis成功後，update請求入佇列，讀請求入佇列，update未提交前，讀請求被阻塞。當update提交後，執行查詢請求，更新新值到redis。
redis快取一致性問題
1 不一致產生的原因？我們在是使用redis過程中，通常會這樣做，先讀取快取，如果快取不存在，則讀取資料庫。不管是先寫庫，再刪除快取 還是先刪除快取，再寫庫，都有可能出現資料不一致的情況。因為寫和讀是併發的，沒法保證順序，如果刪除了快取，還沒有來得及寫庫，另乙個執行緒就來讀取，發現快取為空，則去資料...
Redis雙寫一致性問題
從理論上來說，給快取設定過期時間，是保證最終一致性的解決方案。這種方案下，我們可以對存入快取的資料設定過期時間，所有的寫操作以資料庫為準，對快取操作只是盡最大努力即可。也就是說如果資料庫寫成功，快取更新失敗，那麼只要到達過期時間，則後面的讀請求自然會從資料庫中讀取新值然後回填快取。因此，接下來討論的...
主從DB與cache一致性問題
為什麼會讀到髒資料，有這麼幾種情況 1 單庫情況下，服務層的併發讀寫，快取與資料庫的操作交叉進行 雖然只有乙個db，在上述詭異異常時序下，也可能髒資料入快取 1 請求a發起乙個寫操作，第一步淘汰了cache，然後這個請求因為各種原因在服務層卡住了 進行大量的業務邏輯計算，例如計算了1秒鐘 如上圖步驟...