HoRain云--Redis与数据库数据一致性终极方案-CSDN博客

本文链接：https://blog.csdn.net/sinat_57153473/article/details/148394572

🎬 HoRain 云小助手：个人主页

⛺️生活的理想，就是为了理想的生活!

⛳️ 推荐

前些天发现了一个超棒的服务器购买网站，性价比超高，大内存超划算！忍不住分享一下给大家。点击跳转到网站。

⛳️ 推荐

🔒 一、强一致性方案（金融/订单等核心场景）

⏱️ 二、最终一致性方案（通用场景，如商品/用户信息）

🚀 三、高性能写入方案（计数/日志等高频写场景）

⚠️ 四、通用优化技巧

💎 方案对比与选型建议

为确保Redis缓存与数据库（如MySQL）的数据一致性，需根据业务场景选择合适策略。以下是主流方案及适用场景分析：

🔒 一、强一致性方案（金融/订单等核心场景）

分布式锁 + 双写
- 流程：
  - 写操作前获取分布式锁（如Redisson）
  - 更新数据库 → 删除缓存 → 释放锁
- 优点：彻底避免并发冲突，数据强一致
- 缺点：性能损耗大，复杂度高
- 代码示例：
```
RLock lock = redisson.getLock("user_lock");
lock.lock();
try {
    db.update(user);  // 更新数据库
    redis.delete("user:" + id); // 删除缓存
} finally {
    lock.unlock();
}
```
事务消息（如RocketMQ）
- 流程：
  - 更新数据库 → 发送事务消息 → MQ消费者删除缓存
  - 消息失败则重试，确保最终一致
- 适用：高可靠场景，但需引入消息队列

⏱️ 二、最终一致性方案（通用场景，如商品/用户信息）

Cache Aside + 延迟双删
- 流程：
  - 先删除缓存 → 更新数据库 → 延迟几百毫秒 → 再次删除缓存
- 关键：
  - 延迟时间 = 主从同步时间 + 业务读取耗时（通常100-500ms）
  - 第二次删除覆盖并发读产生的脏数据
- 代码示例：
```
public void updateUser(User user) {
    redis.delete("user:" + user.getId()); // 第一次删除
    db.update(user);                     // 更新数据库
    Thread.sleep(200);                   // 等待主从同步
    redis.delete("user:" + user.getId()); // 第二次删除
}
```
异步监听Binlog（Canal）
- 原理：
  - Canal伪装为MySQL从库，实时解析Binlog → 将变更推送到MQ → 消费者更新Redis
- 优点：
  - 业务代码零侵入，解耦彻底
  - 支持全量/增量同步
- 缺点：架构复杂，需维护Canal和MQ
消息队列异步更新
- 流程：
  - 更新数据库 → 发送消息到MQ → 独立服务消费消息并更新/删除缓存
- 适用：允许短暂延迟（如秒级）的场景

🚀 三、高性能写入方案（计数/日志等高频写场景）

Write Behind（异步写）
- 流程：
  - 写操作只更新Redis → 定时批量同步到数据库
- 优点：写入性能极高，吞吐量大
- 缺点：数据丢失风险高，仅适用于非关键数据（如点赞数）

⚠️ 四、通用优化技巧

设置合理TTL
- 缓存数据添加过期时间（如30分钟），避免长期不一致
失败重试机制
- 删除缓存失败时，通过消息队列异步重试
禁用粗暴的“更新缓存”
- 直接更新缓存易引发并发冲突，优先选择删除缓存策略

💎 方案对比与选型建议

方案	一致性强度	性能影响	复杂度	适用场景
分布式锁	强一致	高损耗	高	金融支付、库存扣减
延迟双删	最终一致	中	中	用户信息、商品详情
Binlog监听（Canal）	最终一致	低	高	实时性要求较高的业务
消息队列异步更新	最终一致	低	中	允许秒级延迟的场景
Write Behind	弱一致	极高	低	浏览量、日志统计

graph TD
    A[业务场景] --> B{一致性要求}
    B -->|强一致| C[分布式锁/事务消息]
    B -->|最终一致| D[延迟双删 或 Binlog同步]
    B -->|弱一致| E[Write Behind]
    D --> F[允许延迟] --> G[Binlog+MQ]
    D --> H[低延迟需求] --> I[延迟双删+重试]