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

蟬沐風發表於2022-02-14

在資料讀多寫少的情況下作為快取來使用,恐怕是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. 延時雙刪的方法為什麼要休眠一段時間呢?

歡迎大家評論區留言。


推薦閱讀

相關文章