1. 缓存一致性问题的本质与挑战
在分布式系统中，缓存与数据库的双写一致性一直是架构设计的难点。我经历过多次生产环境的数据不一致事故，深刻理解这个问题的复杂性。让我们先从一个实际案例说起：
去年我们电商系统大促时，商品库存出现了严重的不一致问题。后台显示某热门商品库存已更新为100件，但用户端页面却一直显示旧数据50件，导致超卖事故。事后排查发现，这是典型的缓存与数据库不一致问题——数据库更新后，缓存未能及时失效或更新。
1.1 为什么会出现不一致？
根本原因在于缓存和数据库是两个独立的数据存储系统，它们之间的数据同步存在时间差。具体来说有三大典型场景：
- 更新时序问题：先更新数据库还是先更新缓存？不同的顺序会导致不同的结果
- 并发冲突问题：多个线程同时更新同一数据时，可能出现更新覆盖
- 操作失败问题：某个操作（如缓存更新）失败后如何处理
重要提示：没有任何一种方案能100%保证所有场景下的强一致性，我们需要根据业务特点选择最适合的折中方案。
2. 延时双删方案深度解析
2.1 基本实现原理
延时双删的核心思想是通过两次删除操作来保证缓存最终一致性。具体流程如下：
- 更新数据库记录
- 立即删除缓存中的对应数据
- 等待一个短暂的时间间隔（通常500ms-1s）
- 再次删除缓存中的对应数据
java复制// 伪代码示例
public void updateProduct(Product product) {
// 1. 更新数据库
productDao.update(product);
// 2. 第一次删除缓存
redisCache.delete(product.getId());
// 3. 延时后第二次删除
executor.schedule(() -> {
redisCache.delete(product.getId());
}, 500, TimeUnit.MILLISECONDS);
}
2.2 为什么需要两次删除？
第一次删除是为了清除旧数据，让后续读请求能从数据库加载最新数据。但考虑以下并发场景：
- 线程A更新数据库
- 线程A删除缓存
- 线程B读取数据，发现缓存不存在，从数据库读取旧值（因为A的事务可能还未提交）
- 线程B将旧值写入缓存
- 线程A第二次删除缓存，清除这个旧值
没有第二次删除的话，步骤4写入的旧数据会长期存在于缓存中。
2.3 关键参数设置
-
延时时间：通常设置为500ms-1s
- 需要考虑数据库主从同步延迟
- 需要评估业务系统的平均事务时间
- 可以通过压测确定最优值
-
重试机制：对删除操作需要实现重试
java复制// 带重试的删除实现 void deleteWithRetry(String key, int maxRetry) { int retry = 0; while (retry < maxRetry) { try { redisCache.delete(key); break; } catch (Exception e) { retry++; if (retry == maxRetry) { log.error("删除缓存失败，key: {}", key); } } } }
2.4 优缺点分析
优势：
- 实现简单，不需要处理复杂的并发控制
- 对写性能影响小，只有两次轻量级删除操作
- 天然适应Redis集群环境
劣势：
- 存在短暂的不一致窗口期
- 缓存失效后可能出现缓存击穿
- 不适合写多读少的场景
3. 双写一致方案全面剖析
3.1 基本实现模式
双写一致要求同时更新数据库和缓存，主流实现有两种模式：
模式一：先更新数据库，再更新缓存
java复制public void updateProduct(Product product) {
// 1. 更新数据库
productDao.update(product);
// 2. 更新缓存
redisCache.set(product.getId(), product);
}
模式二：先删除缓存，再更新数据库，最后更新缓存
java复制public void updateProduct(Product product) {
// 1. 删除缓存
redisCache.delete(product.getId());
// 2. 更新数据库
productDao.update(product);
// 3. 更新缓存
redisCache.set(product.getId(), product);
}
3.2 并发冲突处理
双写一致最大的挑战是处理并发更新。考虑以下场景：
- 线程A和线程B同时更新同一条数据
- 线程A先更新数据库（值A）
- 线程B后更新数据库（值B）
- 线程B先更新缓存（值B）
- 线程A后更新缓存（值A）
最终缓存中是旧的值A，而数据库是最新的值B。
解决方案：
-
分布式锁：
java复制public void updateProductWithLock(Product product) { String lockKey = "lock:" + product.getId(); try { // 获取分布式锁 boolean locked = redisLock.tryLock(lockKey, 1, TimeUnit.SECONDS); if (locked) { productDao.update(product); redisCache.set(product.getId(), product); } } finally { redisLock.unlock(lockKey); } } -
版本号控制：
- 在数据中增加版本号字段
- 更新缓存时检查版本号，只有新版本才能覆盖
3.3 异常处理机制
双写一致必须考虑操作失败的场景：
- 数据库更新成功，缓存更新失败
- 缓存更新成功，数据库更新失败
推荐方案：
- 实现可靠的重试机制
- 结合消息队列保证最终一致性
- 记录操作日志用于后续核对修复
java复制// 使用消息队列实现重试
public void updateProductWithMQ(Product product) {
try {
productDao.update(product);
redisCache.set(product.getId(), product);
} catch (Exception e) {
// 发送到消息队列重试
mqProducer.send(new UpdateEvent(product));
}
}
4. 两种方案的对比与选型
4.1 核心维度对比
| 维度 | 延时双删 | 双写一致 |
|---|---|---|
| 一致性 | 最终一致性（毫秒级延迟） | 强一致性/准强一致性 |
| 实现复杂度 | 简单 | 复杂（需处理并发和失败） |
| 写性能 | 影响小（仅删除操作） | 影响大（需额外写缓存） |
| 读性能 | 缓存失效时会有数据库查询压力 | 读性能最优（缓存命中率高） |
| 适用场景 | 读多写少，允许短暂不一致 | 写多读少，要求强一致性 |
4.2 选型决策树
code复制是否需要强一致性？
├── 是 → 选择双写一致
│ ├── 并发高？ → 加分布式锁
│ └── 可靠性要求高？ → 结合消息队列
└── 否 → 选择延时双删
├── 热点数据？ → 加互斥锁防击穿
└── 数据冷热不均？ → 配合缓存预热
4.3 混合使用方案
在实际生产中，我们经常采用混合策略：
-
核心业务数据：使用双写一致+分布式锁
- 订单状态
- 账户余额
- 库存数量
-
非核心业务数据：使用延时双删
- 商品描述
- 用户资料
- 静态内容
-
特殊场景：结合binlog同步
- 数据仓库
- 数据分析
- 跨系统同步
5. 生产环境最佳实践
5.1 延时双删优化技巧
-
动态调整延时时间：
java复制// 根据主从延迟动态调整 long delay = getReplicaLag() + 50; // 额外增加50ms缓冲 executor.schedule(() -> deleteCache(key), delay, TimeUnit.MILLISECONDS); -
热点数据特殊处理：
- 对热点key使用互斥锁防止缓存击穿
- 实现自动缓存预热机制
-
监控与告警：
- 监控缓存删除失败率
- 设置不一致告警阈值
5.2 双写一致优化技巧
-
降低锁粒度：
- 使用细粒度锁（如按商品ID加锁）
- 避免全局锁影响性能
-
异步双写：
java复制// 异步更新缓存 public void updateProductAsync(Product product) { productDao.update(product); executor.submit(() -> { redisCache.set(product.getId(), product); }); } -
降级方案：
- 当缓存集群异常时自动降级为延时双删
- 实现熔断机制保护数据库
5.3 监控指标设计
-
基础指标：
- 缓存命中率
- 数据库查询QPS
- 缓存操作耗时
-
一致性指标：
- 数据不一致次数
- 不一致持续时间
- 自动修复成功率
-
性能指标：
- 写操作平均延迟
- 锁等待时间
- 消息队列积压量
6. 常见问题与解决方案
6.1 延时双删典型问题
问题1：第二次删除前缓存又被写入旧数据
解决方案：
- 增加延时时间
- 结合版本号控制
- 实现删除操作的幂等性
问题2：缓存击穿导致数据库压力大
解决方案：
java复制// 使用互斥锁防止击穿
public Product getProduct(String id) {
Product product = redisCache.get(id);
if (product == null) {
String lockKey = "lock:" + id;
try {
if (redisLock.tryLock(lockKey, 1, TimeUnit.SECONDS)) {
product = productDao.get(id);
redisCache.set(id, product, 5, TimeUnit.MINUTES);
} else {
// 等待其他线程加载
Thread.sleep(100);
return getProduct(id);
}
} finally {
redisLock.unlock(lockKey);
}
}
return product;
}
6.2 双写一致典型问题
问题1：并发更新导致缓存覆盖
解决方案：
- 实现乐观锁控制
- 使用CAS操作更新缓存
java复制// 使用版本号的CAS操作 public void updateProductCAS(Product product) { int version = product.getVersion(); productDao.update(product); while (true) { Product cached = redisCache.get(product.getId()); if (cached == null || cached.getVersion() <= version) { if (redisCache.cas(product.getId(), cached, product)) { break; } } else { break; // 已有新版本，放弃更新 } } }
问题2：缓存更新失败导致不一致
解决方案：
- 实现异步重试队列
- 设置不一致告警
- 定期全量核对数据
7. 进阶架构模式
7.1 结合binlog的最终一致性
对于大型系统，可以引入binlog监听实现缓存同步：
- 使用Canal监听MySQL binlog
- 解析出数据变更事件
- 发送到消息队列（Kafka）
- 消费者更新Redis缓存
java复制// 伪代码示例
@KafkaListener(topics = "binlog")
public void handleBinlogEvent(BinlogEvent event) {
if (event.isUpdate()) {
redisCache.delete(event.getKey());
// 或者
redisCache.set(event.getKey(), event.getNewValue());
}
}
7.2 多级缓存策略
对于超高并发场景，可以采用多级缓存：
- L1：本地缓存（Caffeine）
- L2：分布式缓存（Redis）
- L3：数据库
更新策略：
- 先更新数据库
- 再删除Redis缓存
- 最后通过广播通知各节点失效本地缓存
7.3 读写分离架构
对于读多写少的场景：
- 写操作：主库+双写/延时双删
- 读操作：从库+多级缓存
- 通过中间件（如ShardingSphere）自动路由
在实际项目中，我们根据业务特点将商品服务设计为：
- 商品基础信息：读写分离+延时双删
- 商品库存：主库强一致+双写一致
- 商品评价：最终一致性+binlog同步
这种混合架构既保证了核心业务的一致性，又提高了整体系统的吞吐量。经过多次大促验证，系统在保证数据准确性的同时，成功支撑了每秒数万次的读写请求。