資料庫中的資料和快取中的資料不一致
如果我們只是讀操作，肯定不會存在快取和資料庫雙寫一致性問題。但是如果更新或者刪除操作呢？
我們知道執行乙個更新操作花費的時間遠遠大於乙個讀操作花費的時間。更新操作，我們是先更新資料庫呢還是先更新快取呢？
如果兩步操作符合原子性，要麼同時成功，要麼同時失敗,則不存在一致性的問題，如果原子操作被破壞了，則會發生資料庫和快取雙寫一致性問題。
這兩步操作並沒有誰先誰後是沒關係的，破壞原子性可能會存在以下四種情況。
運算元據庫成功，操作快取失敗。
操作快取成功，運算元據庫失敗。
運算元據庫失敗，操作快取成功。
操作快取失敗，運算元據庫成功。
無論是先運算元據庫還是先操作快取，如果第一步失敗了（第3,4 種情況），直接報異常，第二步也就不執行了，所以我們完全可以忽略第3，4 種情況。
補充：對於操作快取，有更新和刪除兩種，少使用更新操作，有時候更新乙個key所對應的value，這個vaule 值是經過多個表聯查計算得出的結果，這個操作是非常慢的，頻繁更新，更影響效能，其次該key單位時間內被讀取的次數比較少。與其每次更新快取，倒不如在需要讀的時候，直接刪除快取，訪問的快取沒有，此時就會訪問資料庫，然後重新計算一次即可。所以後面講述的時候，更新操作統稱刪除操作。（用的時候再去查最新的值，這是一種懶載入的計算思想）
更新資料庫成功，更新快取失敗，此時快取中的資料為舊資料。
併發場景下可能會出現一下問題：
上述雙寫一致性問題發生的概率較小，既要剛好快取失效，還併發這寫操作。且讀操作在寫操作之前，又必須比更新快取操作晚。
如何避免刪除快取失敗呢？
併發場景下可能存在以下情況：
解決： 採用訊息佇列，將 刪除快取，修改資料庫，讀快取三步操作放入佇列，實現序列化。
先更新資料庫，在刪快取，高併發請求下，可以緩解資料庫壓力，效能好，但是拿到的資料時舊資料。
先刪快取，後更新資料庫，高併發請求下，訪問資料庫，資料庫壓力大，效能差，但是拿到的資料時新資料。
分布式之資料庫和快取雙寫一致性方案解析
如何保證Redis快取和資料庫的雙寫一致性？
在資料庫 快取模式下，當資料庫中的資料需要更新時，快取裡的資料怎麼處理？如何保證快取和資料庫中資料的一致性？常用的解決方案有兩種 其他渣渣的方案這裡不討論 1 先刪除快取，再更新資料庫 2 先更新資料庫，再刪除快取 下面我們就來看一下這兩種方案，看看它們是怎麼保證資料一致性的？理想的流程是這樣的 先...
Redis快取和資料庫雙寫一致性問題
資料庫與快取讀寫模式策略 寫完資料庫後是否需要馬上更新快取還是直接刪除快取？1 如果寫資料庫的值與更新到快取值是一樣的，不需要經過任何的計算，可以馬上更新快取，但是如果對於那種寫資料頻繁而讀資料少的場景並不合適這種解決方案，因為也許還沒有查詢就被刪除或修改了，這樣會浪費時間和資源 2 如果寫資料庫的...
redis 14 快取和資料庫雙寫一致性問題詳解
如果我們的資料在快取裡邊有，那麼就直接取快取的。如果快取裡沒有我們想要的資料，我們會先去查詢資料庫，然後 將資料庫查出來的資料寫到快取中。最後將資料返回給請求。如果僅僅查詢的話，快取的資料和資料庫的資料是沒問題的。但是，當我們要更新時候呢？各種情況很可能就造成資料庫 和 快取的資料不一致了。從理論上...