redis(十一:數據不一致)

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


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

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

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

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

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

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

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

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

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容