數據庫與緩存數據一致性解決方案

2022 年 3 月 15 日
筆記
JAVA, Java EE, 數據庫, 緩存

一、序言

在分佈式並發系統中，數據庫與緩存數據一致性是一項富有挑戰性的技術難點。本文將討論數據庫與緩存數據一致性問題，並提供通用的解決方案。

假設有完善的工業級分佈式事務解決方案，那麼數據庫與緩存數據一致性便迎刃而解，實際上，目前分佈式事務不成熟。

二、不同的聲音

在數據庫與緩存數據一致解決方式中，有各種聲音。

先操作數據庫後緩存還是先緩存後數據庫
緩存是更新還是刪除

1、操作的先後順序

在並發系統中，數據庫與緩存雙寫場景下，為了追求更大的並發量，操作數據庫與緩存顯而易見不會同步進行。前者操作成功後者以異步的方式進行。

關係型數據庫作為成熟的工業級數據存儲方案，有完善的事務處理機制，數據一旦落盤，不考慮硬件故障，可以負責任的說數據不會丟失。

所謂緩存，無非是存儲在內存中的數據，服務一旦重啟，緩存數據全部丟失。既然稱之為緩存，那麼時刻做好了緩存數據丟失的準備。儘管Redis有持久化機制，是否能夠保證百分之百持久化？Redis將數據異步持久化到磁盤有不可，緩存是緩存，數據庫是數據庫，兩個不同的東西。把緩存當數據庫使用是一件極其危險的事情。

從數據安全的角度來講，先操作數據庫，然後以異步的方式操作緩存，響應用戶請求。

2、處理緩存的態度

緩存是更新還是刪除，對應懶漢式和飽漢式，從處理線程安全實踐來講，刪除緩存操作相對難度低一些。如果在刪除緩存的前提下滿足了查詢性能，那麼優先選擇刪除緩存。

更新緩存儘管能夠提高查詢效率，然後帶來的線程並發臟數據處理起來較麻煩，序言引入MQ等其它消息中間件，因此非必要不推薦。

三、線程並發分析

理解線程並發所帶來問題的關鍵是先理解系統中斷，操作系統在任務調度時，中斷隨時都在發生，這是線程數據不一致產生的根源。以4和8線程CPU為例，同一時刻最多處理8個線程，然而操作系統管理的線程遠遠超過8個，因此線程們以一種看似並行的方式進行。

（一）查詢數據

1、非並發環境

在非並發環境中，使用如下方式查詢數據並無不妥：先查詢緩存，如果緩存數據不存在，查詢數據庫，更新緩存，返回結果。

public BuOrder getOrder(Long orderId) {
    String key = ORDER_KEY_PREFIX + orderId;
    BuOrder buOrder = RedisUtils.getObject(key, BuOrder.class);
    if (buOrder != null) {
        return buOrder;
    }
    BuOrder order = getById(orderId);
    RedisUtils.setObject(key, order, 5, TimeUnit.MINUTES);
    return order;
}

如果在高並發環境中有一個嚴重缺陷：當緩存失效時，大量查詢請求湧入，瞬間全部打到DB上，輕則數據庫連接資源耗盡，用戶端響應500錯誤，重則數據庫壓力過大服務宕機。

2、並發環境

因此在並發環境中，需要對上述代碼進行修改，使用分佈式鎖。大量請求湧入時，獲得鎖的線程有機會訪問數據庫查詢數據，其餘線程阻塞。當查詢完數據並更新緩存，然後釋放鎖。等待的線程重新檢查緩存，發現能夠獲取到數據，直接將緩存數據響應。

這裡提到分佈式鎖，那麼使用表鎖還是行鎖呢？使用分佈式行鎖提高並發量；使用二次檢查機制，確保等待獲得鎖的線程能夠快速返回結果

@Override
public BuOrder getOrder(Long orderId) {
    /* 如果緩存不存在，則添加分佈式鎖更新緩存 */
    String key = ORDER_KEY_PREFIX + orderId;
    BuOrder order = RedisUtils.getObject(key, BuOrder.class);
    if (order != null) {
        return order;
    }
    String orderLock = ORDER_LOCK + orderId;
    RLock lock = redissonClient.getLock(orderLock);
    if (lock.tryLock()) {
        order = RedisUtils.getObject(key, BuOrder.class);
        if (order != null) {
            LockOptional.ofNullable(lock).ifLocked(RLock::unlock);
            return order;
        }
        BuOrder buOrder = getById(orderId);
        RedisUtils.setObject(key, buOrder, 5, TimeUnit.MINUTES);
        LockOptional.ofNullable(lock).ifLocked(RLock::unlock);
    }
    return RedisUtils.getObject(key, BuOrder.class);
}

（二）更新數據

1、非並發環境

非並發環境中，如下代碼儘管可能會產生數據不一致問題（數據被覆蓋）。儘管使用數據庫層面樂觀鎖能夠解決數據被覆蓋問題，然而無效更新流量依舊會流向數據庫。

public Boolean editOrder(BuOrder order) {
    /* 更新數據庫 */
    updateById(order);
    /* 刪除緩存 */
    RedisUtils.deleteObject(OrderServiceImpl.ORDER_KEY_PREFIX + order.getOrderId());
    return true;
}

2、並發環境

上面分析中使用數據庫樂觀鎖能夠解決並發更新中數據被覆蓋的問題，然而當同一行記錄被修改後，版本號發生改變，後續並發流向數據庫的請求為無效流量。減小數據庫壓力的首要策略是將無效流量攔截在數據庫之前。

使用分佈式鎖能夠保證並發流量有序訪問數據庫，考慮到數據庫層面已經使用了樂觀鎖，第二個及以後獲得鎖的線程操作數據庫為無效流量。

線程在獲得鎖時採用超時退出的策略，等待獲得鎖的線程超時快速退出，快速響應用戶請求，重試更新數據操作。

public Boolean editOrder(BuOrder order) {
    String orderLock = ORDER_LOCK + order.getOrderId();
    RLock lock = redissonClient.getLock(orderLock);
    try {
        /* 超時未獲取到鎖，快速失敗，用戶端重試 */
        if (lock.tryLock(1, TimeUnit.SECONDS)) {
            /* 更新數據庫 */
            updateById(order);
            /* 刪除緩存 */
            RedisUtils.deleteObject(OrderServiceImpl.ORDER_KEY_PREFIX + order.getOrderId());
            /* 釋放鎖 */
            LockOptional.ofNullable(lock).ifLocked(RLock::unlock);
            return true;
        }
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return false;
}

（三）依賴環境

上述代碼使用了封裝鎖的工具類。

<dependency>
  <groupId>xin.altitude.cms</groupId>
  <artifactId>ucode-cms-common</artifactId>
  <version>1.4.3.2</version>
</dependency>

LockOptional根據鎖的狀態執行後續操作。

四、先數據庫後緩存

（一）數據一致性

1、問題描述

接下來討論先更新數據庫，後刪除緩存是否存在並發問題。

（1）緩存剛好失效
（2）請求A查詢數據庫，得一個舊值
（3）請求B將新值寫入數據庫
（4）請求B刪除緩存
（5）請求A將查到的舊值寫入緩存

上述並發問題出現的關鍵是第5步比第3、4步後發生，由操作系統中斷不確定因素可知，此種情況卻有發生的可能。

2、解決方式

從實際情況來看，將數據寫入Redis遠比將數據寫入數據庫耗時要短，儘管發生的概率較低，但仍會發生。

（1）增加緩存過期時間

增加緩存過期時間允許一定時間範圍內臟數據存在，直到下一次並發更新出現，可能會出現臟數據。臟數據會周期性存在。

（2）更新和查詢共用一把行鎖

更新和查詢共用一把行分佈式鎖，上述問題不復存在。當讀請求獲取到鎖時，寫請求處於阻塞狀態（超時會快速失敗返回），能夠保證步驟5在步驟3之前進行。

（3）延遲刪除緩存

使用RabbitMQ延遲刪除緩存，去除步驟5的影響。使用異步的方式進行，幾乎不影響性能。

（二）特殊情況

數據庫有事務機制保證操作成功與否；Redis單條指令具有原子性，然後組合起來卻不具備原子特徵，具體來說是數據庫操作成功，然後應用異常掛掉，導致Redis緩存未刪除。Redis服務網絡連接超時出現此問題。

如果設置有緩存過期時間，那麼在緩存尚未過期前，臟數據一直存在。如果未設置過期時間，那麼直到下一次修改數據前，臟數據一直存在。（數據庫數據已經發生改變，緩存尚未更新）

解決方式

在操作數據庫前，向RabbitMQ寫入一條延遲刪除緩存的消息，然後執行數據庫操作，執行緩存刪除操作。不管代碼層面緩存是否刪除成功，MQ刪除緩存作為保底操作。

五、小結

上述方式提供的數據庫與緩存數據一致性解決方式，屬於耦合版，當然還有訂閱binlog日誌的解耦版。解耦版由於增加了訂閱binlog組件，對系統穩定性提出更高的要求。

數據庫與緩存一致性問題看似是解決數據問題，實質上解決並發問題：在儘可能保證更多並發量的前提下，在保證數據庫安全的前提下，保證數據庫與緩存數據一致。

Tags: JAVA Java EE 數據庫緩存