先更新資料庫，再刪除快取
redis 快取常見問題 ：快取雪崩，快取擊穿，快取穿透，快取預熱
在之前的部落格中，我介紹了redis快取的一些常見問題，如：快取雪崩、快取擊穿、快取穿透等。這次就來介紹一下redis的快取一致性的問題。
對於快取和資料庫的更新操作，主要分為以下兩種
首先可能會帶來疑惑的點是，為什麼這裡是刪除快取而不是更新快取？按照常理來說，更新的效率通常都會比刪除高，因為我們在刪除了快取後當有讀操作到來時，當其查詢快取不存在時，就會去查詢資料庫，並將讀取到的值寫入到快取中，這樣的效率明顯比更新低。
但是我們還需要考慮乙個問題，即快取的使用率問題。如果在短時間內對資料庫進行了10000次更新操作，那麼快取也必定會進行10000次的更新操作，那這個快取它真的有用到那麼多次嗎？如果它僅僅是乙個冷門資料，可能在這期間內只進行了僅僅幾次的查詢操作，那我們的這些更新操作不是會顯得很多餘嗎？
所以，我們才會去使用刪除。因為在我們刪除快取後，只有在其真正使用到這個資料的時候，才會將其寫入快取，因此我們就不用每次都對快取進行更新操作，從而保證效率。
對於這種情況，能夠保證快取的一致性嗎？
答案肯定是否定的，例如下面這種情景
執行緒a寫入資料，此時先刪除快取
執行緒b讀取資料，查詢快取不存在，直接去查詢資料庫
執行緒b將查詢到的舊值寫入至快取中
執行緒a將新資料更新至資料庫中
那麼這個問題如何解決呢？這時候就需要引入延時雙刪的機制
為了避免在更新資料庫的時候，其他的執行緒讀取到了資料庫中的舊值並將其寫入快取這種情況，我們會在資料庫更新完後等待一段時間，再次刪除快取，來保證下乙個到來的執行緒能夠將正確的快取更新回去。
流程如下
執行緒a寫入資料，此時先刪除快取
執行緒b讀取資料，查詢快取不存在，直接去查詢資料庫
執行緒b將查詢到的舊值寫入至快取中
執行緒a將新資料更新至資料庫中，休眠一段時間
執行緒a將快取再次刪除，來確保快取的一致性
其他執行緒查詢資料庫，將正確的值更新至快取中
那麼，為了保證我們能夠將錯誤的快取刪除，所以我們的sleep時間只需要大於執行緒讀寫快取的時間即可
那麼如果我們先更新資料庫，再更新快取呢？
對於這種操作，快取不一致的情況就更加明顯了。由於磁碟i/o速度慢，在更新資料庫、刪除快取這段操作之前，其他執行緒讀取到的都是原本快取中的舊值。甚至可能會由於快取刪除失敗(如快取服務當前不可用的情況)從而導致嚴重的快取不一致問題。
那麼如何解決這個問題呢？可以使用以下幾種方法
這是解決這個問題最簡單的方法，同時也是治標不治本的方法。
我們可以將快取過期時間變短，使其每隔一段時間就會去資料庫中載入資料，對於更新不頻繁的資料來說，就可以很好的解決不一致的問題，但若是更新特別頻繁的熱點資料，這個方法則失去了作用。
由於這個方法的適用面小，且實時性和一致性不高，所以我們通常都會選擇使用訊息佇列來解決這個問題。
我們可以引入乙個訊息佇列來解決這個問題，在更新資料庫後，我們往訊息佇列中寫入資料，等到消費者從訊息佇列中取出資料時，再將快取刪除。借助訊息佇列的訊息重試機制來保證我們一定能夠成功刪除快取，從而確保快取的一致性。
但是這種方法也存在幾個問題
引入訊息佇列後可能會因為訊息的處理導致一定程度的延遲，從而引起短期內的訊息不一致
引入訊息佇列後導致問題整體複雜化
所以我們只有在對實時性和一致性要求不高的情況下才會選擇這種做法
Redis快取常見問題
這是決定在使用快取時就該考慮的問題。快取的資料在資料來源發生變更時需要對快取進行更新，資料來源可能是 db，也可能是遠端服務。更新的方式可以是主動更新。資料來源是 db 時，可以在更新完 db 後就直接更新快取。當資料來源不是 db 而是其他遠端服務，可能無法及時主動感知資料變更，這種情況下一般會選...
Redis快取雪崩 快取穿透 快取一致性問題
一 快取雪崩 1 快取失效時間相同導致大量快取同時失效 2 快取系統故障 事後 快取資料持久化，在故障後快速恢復快取系統 二 快取穿透 1 訪問不存在資料從而繞過快取，直接讀取資料庫 三 快取一致性 1 常規流程是 讀操作 命中快取則返回，無快取則讀資料庫並寫快取 寫操作 先刪除快取，再更新資料庫。...
redis快取一致性問題
1 不一致產生的原因？我們在是使用redis過程中，通常會這樣做，先讀取快取，如果快取不存在，則讀取資料庫。不管是先寫庫，再刪除快取 還是先刪除快取，再寫庫，都有可能出現資料不一致的情況。因為寫和讀是併發的，沒法保證順序，如果刪除了快取，還沒有來得及寫庫，另乙個執行緒就來讀取，發現快取為空，則去資料...