4. 缓存一致性难题：最终一致性、强一致性、分布式事务与缓存同步的权衡

在数据库与缓存构成的混合存储架构中，一致性是最核心也最棘手的权衡点。强一致性保证数据实时准确，但会牺牲可用性与吞吐；最终一致性换取高性能，却可能让用户读到过期数据。本章从工程视角拆解四种主流一致性模型及其对应的缓存同步策略，并给出选型决策框架。

4.1 一致性模型对比

4.2 缓存同步的三种典型策略

4.2.1 同步双写（强一致倾向）

应用在同一个事务内同时更新数据库和缓存。若缓存写入失败，事务回滚。该策略能保证数据绝对一致，但会显著增加写入延迟，且缓存故障直接导致写入失败。

// 伪代码：同步双写
@Transactional
public void updateUserBalance(Long userId, BigDecimal amount) {
    // 1. 更新数据库
    userBalanceDao.update(userId, amount);
    // 2. 同步更新缓存（若失败则抛异常触发回滚）
    cacheClient.set("balance:" + userId, amount.toString());
}

4.2.2 异步补偿（最终一致倾向）

先更新数据库，再通过消息队列异步删除或更新缓存。允许短暂的不一致窗口，但吞吐量高、对缓存故障容忍度强。

// 伪代码：异步补偿
public void updateProductStock(Long productId, Integer delta) {
    // 1. 更新数据库
    stockDao.updateStock(productId, delta);
    // 2. 发送缓存失效消息
    mqProducer.send(new CacheInvalidateMsg(productId, "stock"));
}

// 消费者
@RabbitListener(queues = "cache.invalidate")
public void handleInvalidate(CacheInvalidateMsg msg) {
    cacheClient.del("stock:" + msg.getProductId());
}

4.2.3 基于Binlog的监听同步

通过Canal等组件监听数据库Binlog变更，异步同步到缓存。对业务代码无侵入，适合异构系统或遗留系统改造。

4.3 缓存一致性架构图

下图展示了从强一致到最终一致的四种同步策略及其适用边界：

4.4 分布式事务与缓存同步的冲突

当引入分布式事务（如TCC、Saga）时，缓存同步面临新的挑战：

• TCC 的 Try-Confirm 阶段：Try阶段预留资源时，缓存应标记为"中间态"；Confirm后才能真正更新缓存。若直接更新，Cancel时缓存回滚困难。
• Saga 的补偿操作：补偿操作需要反向更新缓存，但缓存中可能已混入其他并发写入，导致补偿后的缓存值与数据库不一致。
• 本地消息表 + 缓存：事务消息投递成功后，消费者更新缓存。若消费者重复消费，需保证缓存操作的幂等性。

4.5 选型决策矩阵

4.6 一致性保障的工程手段

1. 版本号乐观锁：缓存中存储数据版本号，更新时对比版本，防止旧数据覆盖新数据。
2. 延迟双删：先删除缓存，再更新数据库，延迟几百毫秒后再删一次缓存，解决并发读请求导致的脏缓存。
3. 缓存失效时间兜底：所有缓存设置合理的TTL，即使同步失败，也能在TTL过期后自动恢复一致。
4. 全量对账任务：定期扫描数据库与缓存，发现不一致后自动修复，作为最终防线。