redis如何保證與資料庫的資料一緻性

在實際操作redis的過程中，我們時常會遇到資料不一緻的問題，下面我列舉幾個場景：

主要是針對并發操作下導緻的一些線程不安全的問題

1、比如在删除操作的時候，先删除緩存，再删除資料庫資料。但是删除資料庫的操作還沒有執行成功，這時如果存在并發的問題，當另一個線程讀取該資料，發現緩存不存在，去資料庫查詢，查詢後将結果緩存到redis中。這時另一個線程的删除資料庫的操作執行完成，這是就存在資料庫沒有資料，緩存還保留着原有舊資料的不一緻性問題。

2，還有在執行更新商品庫存的操作的時候，商品庫存現在是100，更新資料庫為99，再更新緩存，但是這是資料庫更新成功之後，redis沒有更新成功，這時就出現資料庫是99，redis中還是100，這種情況也是資料不一緻性問題。（針對這種情況可以在更新之前先删除緩存，儲存每次更新後的資料都是從資料庫查出來的，保證資料一緻性）

針對的解決方案：

1,針對第一種操作出現的問題可以使用延時雙删政策。

即在删除完redis緩存後的過程中再執行一遍删除操作（不常用，不适用分布式系統）

2,還有一種通用的解決方案：異步更新緩存。(基于訂閱binlog的同步機制)

通過rabbitmq中間去實作。需要用到阿裡的技術元件canal。

cannal機制：

1、通過cannal模拟mysql slave互動協定，僞裝自己為mysql slave,向mysql master 發送dump協定。

2、mysql master收到dump請求，開始推送binarylog給slave，也就是cannal

3、canal解析binarylog對象

4、canal将解析後的對象資料推送給監聽的消息中間件

核心：通過消息隊列的有序的處理來保證資料的一緻性。

以上兩種解決方案的優缺點：

使用消息中間件之後，問題更複雜了，難以保證消息不丢失。

就算通過更新資料和删除緩存都沒有發生問題，消息的延遲也會帶來短暫的不一緻性，不過這個延遲相對是說是可以接受的，如果采用第二種方案則先更新資料庫，再删除緩存。