如果數據同時存在redis和數據庫，此時要更新數據。不管刪除緩存和更新數據庫的先后順序如何，都可能出現數據不一致的情況。

如何解決數據不一致問題?（不能百分百保證一致性）

采用重試機制
可以把要刪除的緩存值或者是要更新的數據庫值暫存到消息隊列中（例如使用 Kafka 消息隊列）。當應用沒有能夠成功地刪除緩存值或者是更新數據庫值時，可以從消息隊列中重新讀取這些值，然后再次進行刪除或更新。
如果能夠成功地刪除或更新，我們就要把這些值從消息隊列中去除，以免重復操作，此時，我們也可以保證數據庫和緩存的數據一致了。否則的話，我們還需要再次進行重試。如果重試超過的一定次數，還是沒有成功，我們就需要向業務層發送報錯信息了。

為什么要借助MQ？
現實情況往往沒有想的這么簡單，失敗后立即重試的問題在于：立即重試很大概率「還會失敗」
重試次數設置多少才合理？：重試會一直「占用」這個線程資源，無法服務其它客戶端請求
如果你確實不想在應用中去寫消息隊列，是否有更簡單的方案，同時又可以保證一致性呢？
方案還是有的，這就是近幾年比較流行的解決方案：訂閱數據庫變更日志，再操作緩存。

想要保證數據庫和緩存一致性，推薦采用「先更新數據庫，再刪除緩存」方案，并配合「消息隊列」或「訂閱變更日志」的方式來做。

緩存延遲雙刪策略
1，在線程 A 刪除緩存、更新完數據庫之后，先「休眠一會」，再「刪除」一次緩存。
2，線程 A 可以生成一條「延時消息」，寫到消息隊列中，消費者延時「刪除」緩存。

這個時間在分布式和高并發場景下，其實是很難評估的。不建議

其實不用追求強一致性，我們引入緩存的目的是什么？沒錯，性能。一旦我們決定使用緩存，那必然要面臨一致性問題。性能和一致性就像天平的兩端，無法做到都滿足要求。

文章摘抄：緩存和數據庫一致性問題，看這篇就夠了