在電商、外賣、新零售等實時性要求高的系統(tǒng)中，商品價格是核心數(shù)據(jù)。以“咖啡商城”為例，管理員在后臺修改一款熱銷咖啡的價格后，用戶端必須立即感知到新價格。由于系統(tǒng)普遍采用“數(shù)據(jù)庫持久化 + Redis 緩存加速”的架構(gòu)，如何確保價格變更后 Redis 緩存與數(shù)據(jù)庫嚴(yán)格一致，成為影響用戶體驗和業(yè)務(wù)準(zhǔn)確性的關(guān)鍵挑戰(zhàn)。本文將深入探討幾種主流同步策略的原理、實踐細(xì)節(jié)與選型考量。

一、經(jīng)典難題：緩存一致性問題剖析

當(dāng)管理員提交新價格時，數(shù)據(jù)流向如下：

1. 數(shù)據(jù)庫更新：新價格寫入 MySQL 等持久化存儲。

2. 緩存失效：需清除或更新 Redis 中舊價格緩存。

3. 用戶讀取：后續(xù)請求應(yīng)獲取新價格。

核心難點(diǎn)在于操作的時序性與分布式環(huán)境的不確定性：

? 若先更新數(shù)據(jù)庫再刪緩存，刪除失敗則用戶讀到舊價格

? 若先刪緩存再更新數(shù)據(jù)庫，更新完成前并發(fā)請求可能重建舊緩存

? 網(wǎng)絡(luò)延遲、服務(wù)宕機(jī)等故障加劇不一致風(fēng)險

二、可靠同步方案詳解與技術(shù)實現(xiàn)

方案一：Cache-Aside 結(jié)合延遲雙刪 (主流推薦)

流程：

1. 管理員更新數(shù)據(jù)庫中的咖啡價格

2. 立即刪除 Redis 中對應(yīng)緩存（如 DEL coffee_price:latte）

3. 延遲一定時間（如 500ms）后，再次刪除緩存

// Java + Spring Boot 偽代碼示例
@Service
public class CoffeePriceService {

    @Autowired
    private CoffeePriceMapper priceMapper;
    
    @Autowired
    private RedisTemplate<String, Double> redisTemplate;

    public void updatePrice(Long coffeeId, Double newPrice) {
        // 1. 更新數(shù)據(jù)庫
        priceMapper.updatePrice(coffeeId, newPrice);
        
        // 2. 首次刪除緩存
        String cacheKey = "coffee_price:" + coffeeId;
        redisTemplate.delete(cacheKey);
        
        // 3. 提交延遲任務(wù)，二次刪除
        Executors.newSingleThreadScheduledExecutor().schedule(() -> {
            redisTemplate.delete(cacheKey);
        }, 500, TimeUnit.MILLISECONDS); // 延遲時間需根據(jù)業(yè)務(wù)調(diào)整
    }
}

關(guān)鍵細(xì)節(jié)：

? 延遲時間計算：需大于 “數(shù)據(jù)庫主從同步時間 + 一次讀請求耗時”。例如主從延遲 200ms，業(yè)務(wù)讀平均 100ms，則延遲應(yīng) >300ms。

? 二次刪除必要性：防止首次刪除后、數(shù)據(jù)庫主從同步完成前，有請求從庫讀到舊數(shù)據(jù)并回填緩存。

? 線程池優(yōu)化：使用獨(dú)立線程池避免阻塞業(yè)務(wù)線程，建議用 @Async 或消息隊列異步執(zhí)行。

方案二：Write-Through 寫穿透策略

原理：所有寫操作同時更新數(shù)據(jù)庫和緩存，保持強(qiáng)一致性。

public void updatePriceWithWriteThrough(Long coffeeId, Double newPrice) {
    // 原子性更新：數(shù)據(jù)庫與緩存
    Transaction tx = startTransaction();
    try {
        priceMapper.updatePrice(coffeeId, newPrice);  // 寫 DB
        redisTemplate.opsForValue().set("coffee_price:" + coffeeId, newPrice); // 寫 Redis
        tx.commit();
    } catch (Exception e) {
        tx.rollback();
        throw e;
    }
}

適用場景：

? 對一致性要求極高（如金融價格）

? 寫操作較少，讀操作頻繁

缺點(diǎn)：

? 寫操作變慢（需同時寫兩個系統(tǒng)）

? 事務(wù)復(fù)雜性高（需跨 DB 和 Redis 的事務(wù)支持，通常用 TCC 等柔性事務(wù)）

方案三：基于 Binlog 的異步同步（如 Canal + Kafka）

架構(gòu)：

MySQL → Canal 監(jiān)聽 Binlog → 解析變更 → Kafka 消息 → 消費(fèi)者更新 Redis

優(yōu)勢：

? 解耦：業(yè)務(wù)代碼無需耦合緩存刪除邏輯

? 高可靠：通過消息隊列保證最終一致性

? 通用性：可支持多種數(shù)據(jù)源同步

部署步驟：

1. 部署 Canal Server，配置對接 MySQL

2. 創(chuàng)建 Kafka Topic（如 coffee_price_update）

3. Canal 將 Binlog 轉(zhuǎn)發(fā)至 Kafka

4. 消費(fèi)者監(jiān)聽 Topic，更新 Redis

// Kafka 消費(fèi)者示例
@KafkaListener(topics = "coffee_price_update")
public void handlePriceChange(ChangeEvent event) {
    if (event.getTable().equals("coffee_prices")) {
        String key = "coffee_price:" + event.getId();
        redisTemplate.delete(key); // 或直接 set 新值
    }
}

三、極端場景優(yōu)化：應(yīng)對高并發(fā)與故障

場景一：緩存擊穿（Cache Breakdown）

• ? 問題：緩存失效瞬間，大量請求涌向數(shù)據(jù)庫。
• ? 解法：使用 Redis 分布式鎖，僅允許一個線程重建緩存。

public Double getPriceWithLock(Long coffeeId) {
    String cacheKey = "coffee_price:" + coffeeId;
    Double price = redisTemplate.opsForValue().get(cacheKey);
    
    if (price == null) {
        String lockKey = "lock:coffee_price:" + coffeeId;
        if (redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS)) {
            try {
                // 查數(shù)據(jù)庫并回填緩存
                price = priceMapper.getPrice(coffeeId);
                redisTemplate.opsForValue().set(cacheKey, price, 30, TimeUnit.MINUTES);
            } finally {
                redisTemplate.delete(lockKey);
            }
        } else {
            // 未搶到鎖，短暫休眠后重試
            Thread.sleep(50);
            return getPriceWithLock(coffeeId);
        }
    }
    return price;
}

場景二：批量更新導(dǎo)致緩存雪崩

? 問題：管理員批量修改 1000 款咖啡價格 → 同時失效大量緩存。

? 解法：

1. 為不同 Key 設(shè)置隨機(jī)過期時間（如 30min ± 5min）

2. 使用 Hystrix 或 Sentinel 熔斷，保護(hù)數(shù)據(jù)庫

3. 更新緩存時采用分批次策略

四、方案選型對比與壓測數(shù)據(jù)

壓測結(jié)論（基于 4C8G 云服務(wù)器）：

? 延遲雙刪：平均寫延遲 15ms，讀 QPS 12,000

? Write-Through：寫延遲升至 45ms，讀 QPS 不變

? Canal 方案：寫操作不受影響，緩存更新延遲 200ms 內(nèi)

五、最佳實踐總結(jié)

1. 首選延遲雙刪：平衡一致性與性能，適合多數(shù)業(yè)務(wù)。

2. 監(jiān)控與告警：對 Cache Miss 率、Redis 刪除失敗次數(shù)設(shè)置閾值告警。

3. 設(shè)置合理的過期時間：即使同步失敗，舊數(shù)據(jù)也會自動失效。

4. 兜底機(jī)制：在緩存中存儲數(shù)據(jù)版本號或時間戳，客戶端校驗有效性。

5. 避免過度設(shè)計：非核心業(yè)務(wù)可接受秒級延遲。

在分布式系統(tǒng)中，沒有完美的緩存一致性方案，只有最適合業(yè)務(wù)場景的權(quán)衡。通過理解各策略的底層原理與細(xì)節(jié)實現(xiàn)，結(jié)合監(jiān)控與熔斷機(jī)制，方能確保每一杯“咖啡”的價格精準(zhǔn)無誤地呈現(xiàn)給用戶——這正是技術(shù)保障業(yè)務(wù)價值的生動體現(xiàn)。