Redis和資料庫的數據一致性問題

在數據讀多寫少的情況下作為快取來使用,恐怕是Redis使用最普遍的場景了。當使用Redis作為快取的時候,一般流程是這樣的。

  • 如果快取在Redis中存在,即快取命中,則直接返回數據

image.png

  • 如果Redis中沒有對應快取,則需要直接查詢資料庫,然後存入Redis,最後把數據返回

image_1.png

通常情況下,我們會為某個快取設置一個key值,並針對key值設置一個過期時間,如果被查詢的數據對應的key過期了,則直接查詢資料庫,並將查詢得到的數據存入Redis,然後重置過期時間,最後將數據返回,偽程式碼如下:

/**
 * 根據用戶名獲取用戶詳細資訊
 * @author 公眾號【蟬沐風】
 */
public User getUserInfo(String userName) {
      User user = redisCache.getName("user:" + userName);
      if (user != null) {
          return user;
      }

      // 從資料庫中直接搜索
      user = selectUserByUserName(userName);
      // 將數據寫入Redis,並設置過期時間
      redisCache.set("user:" + userName, user, 30000);
      // 返回數據
      return user;
}

一致性問題

但是,在Redis的key值未過期的情況下,用戶修改了個人資訊,我們此時既要操作資料庫數據,也要操作Redis數據。現在我們面臨了兩種選擇:

  1. 先操作Redis的數據,再操作資料庫的數據
  2. 先操作資料庫的數據,再操作Redis的數據

如論選擇哪種方法,最理想的情況下,兩個操作要麼同時成功,要麼同時失敗,否則就會出現Redis和資料庫數據不一致的情況。

遺憾的是,目前沒有什麼框架能夠保證Redis的數據和資料庫的數據的完全一致性。我們只能根據場景和所需要付出的程式碼來採取一定的措施降低數據不一致出現的概率,在一致性和性能之間取得一個折中。

下面我們來討論一下關於Redis和資料庫質檢數據一致性的一些方案。

方案選擇

是刪除快取還是更新快取?

當資料庫數據發生變化的時候,Redis的數據也需要進行相應的操作,那麼這個「操作」到底是用「更新」還是用「刪除」呢?

「更新」的話調用Redis的set方法,新值替換舊值;「刪除」直接刪除原來的快取,下次查詢的時候重新讀取資料庫,然後再更新Redis。

結論:推薦直接使用「刪除」操作

因為使用「更新」操作的話,你會面臨兩種選擇

  1. 先更新快取,再更新資料庫
  2. 先更新資料庫,再更新快取

第1種不用考慮了,下面討論一下「先更新資料庫,再更新快取」這種方案。

image_2.png

如果執行緒1和執行緒2同時進行更新操作,但是每個執行緒的執行順序如上圖所示,此時就會導致數據不一致,因此從這個角度上我們推薦直接使用刪除快取的方式。

此外,推薦使用「刪除快取」還有兩點原因。

  1. 如果寫資料庫的場景比讀數據場景多,採用這種方案就會導致快取就被頻繁寫入,浪費性能;
  2. 如果快取要經過一系列複雜的計算才能得到,那麼每次寫入資料庫後,都再次計算寫入的快取無疑也是浪費性能的。

明確這個問題之後,擺在我們面前的就只有兩個選擇了:

  • 先更新資料庫,再刪除快取
  • 先刪除快取,再更新資料庫

先更新資料庫,再刪除快取

這種方式可能存在以下兩種異常情況

  1. 更新資料庫失敗,這時可以通過程式捕獲異常,直接返回結果,不再繼續刪除快取,所以不會出現數據不一致的問題
  2. 更新資料庫成功,刪除快取失敗。導致資料庫是最新數據,快取中的是舊數據,數據不一致

第2種情況應該怎麼辦呢?我們有兩種方式:失敗重試非同步更新

失敗重試

如果刪除快取失敗,我們可以捕獲這個異常,把需要刪除的 key 發送到消息隊列。自己創建一個消費者消費,嘗試再次刪除這個 key,直到刪除成功為止。

image_3.png

這種方式有個缺點,首先會對業務程式碼造成入侵,其次引入了消息隊列,增加了系統的不確定性。

非同步更新快取

因為更新資料庫時會往 binlog 中寫入日誌,所以我們可以啟動一個監聽 binlog變化的服務(比如使用阿里的 canal開源組件),然後在客戶端完成刪除 key 的操作。如果刪除失敗的話,再發送到消息隊列。

總結

總之,對於刪除快取失敗的情況,我們的做法是不斷地重試刪除操作,直到成功。無論是重試還是非同步刪除,都是最終一致性的思想。

先刪除快取,再更新資料庫

這種方式可能存在以下兩種異常情況

  1. 刪除快取失敗,這時可以通過程式捕獲異常,直接返回結果,不再繼續更新資料庫,所以不會出現數據不一致的問題
  2. 刪除快取成功,更新資料庫失敗。在多執行緒下可能會出現數據不一致的問題

image_4.png

這時,Redis中存儲的舊數據,資料庫的值是新數據,導致數據不一致。這時我們可以採用延時雙刪的策略,即更新資料庫數據之後,再刪除一次快取。

image_5.png

用偽程式碼表示就是:

/**
 * 延時雙刪
 * @author 公眾號【蟬沐風】
 */
public void update(String key, Object data) {
    // 首先刪除快取
    redisCache.delKey(key);
    // 更新資料庫
    db.updateData(data);
    // 休眠一段時間,時間依據數據的讀取耗費的時間而定
    Thread.sleep(500);
    // 再次刪除快取
    redisCache.delKey(key);
}

最後給讀者留下兩個思考題:

  1. 為什麼先更新快取,再更新資料庫行不通?
  2. 延時雙刪的方法為什麼要休眠一段時間呢?

歡迎大家評論區留言。


推薦閱讀

Tags: