以下是关于Redis与MySQL数据一致性问题的详细解决方案，结合实际场景的常见策略和最佳实践：
一、数据一致性问题的核心挑战
在高并发场景下，Redis作为缓存层与MySQL数据库之间的数据同步可能因以下原因导致不一致：
- 缓存与数据库双写顺序：先更新数据库还是先更新/删除缓存？
- 并发读写竞争：多个线程同时操作缓存和数据库。
- 操作失败回滚：某一环节失败（如缓存删除失败）导致残留脏数据。
二、常见解决方案
1. 双写策略
- 策略一：先更新数据库，再删除缓存（Cache-Aside）
- // 伪代码示例 public void updateData(Data data) { // 1. 更新数据库 mysql.update(data); // 2. 删除缓存 redis.del("data_key"); }
- 优点：简单，减少缓存穿透风险。
- 问题：若缓存删除失败，需结合重试机制（如MQ补偿）。
- 策略二：先删除缓存，再更新数据库
- public void updateData(Data data) { // 1. 删除缓存 redis.del("data_key"); // 2. 更新数据库 mysql.update(data); }
- 问题：若数据库更新耗时，其他线程可能读到旧数据并回填缓存（需结合延迟双删）。
- 延迟双删（优化版）：
- public void updateData(Data data) { // 1. 第一次删除缓存 redis.del("data_key"); // 2. 更新数据库 mysql.update(data); // 3. 延迟再次删除缓存（如1秒后） Thread.sleep(1000); redis.del("data_key"); }
- 适用场景：高并发下减少旧数据残留概率。
2. 订阅MySQL Binlog（最终一致性）
- 实现步骤：
- 使用工具（如Canal、Debezium）监听MySQL的Binlog。
- 解析Binlog中的数据变更事件。
- 根据变更事件同步更新或删除Redis缓存。
- 优点：完全解耦，保证最终一致性。
- 缺点：架构复杂，需维护消息队列（如Kafka）和消费者。
- MySQL → Binlog → Canal → Kafka → Consumer → Redis更新/删除
3. 设置缓存过期时间
- 兜底方案：为Redis中的缓存数据设置合理的TTL（如30分钟）。
- redis.setex("data_key", 1800, data); // 30分钟后自动过期
- 优点：最终强制重新加载最新数据。
- 缺点：短期可能读到旧数据，不适用于强一致性场景。
三、高并发场景下的优化
1. 读写锁控制
- 在业务层对同一数据加分布式锁，确保读写顺序性。
- // 伪代码示例（使用Redisson） RLock lock = redisson.getLock("data_lock"); lock.lock(); try { // 1. 读缓存 Data data = redis.get("data_key"); if (data == null) { // 2. 读数据库 data = mysql.query(); // 3. 写缓存 redis.set("data_key", data); } return data; } finally { lock.unlock(); }
2. 版本号或时间戳
- 在缓存和数据库中存储数据的版本号，更新时校验版本：
- -- MySQL表结构 CREATE TABLE data ( id INT PRIMARY KEY, content VARCHAR(255), version INT DEFAULT 0 );// 更新时校验版本号 public void updateData(Data newData) { int oldVersion = newData.getVersion(); // 更新数据库（带版本校验） int rows = mysql.update( "UPDATE data SET content=?, version=version+1 WHERE id=? AND version=?", newData.getContent(), newData.getId(), oldVersion ); if (rows > 0) { redis.del("data_key"); // 删除缓存 } }
四、异常处理与补偿
1. 异步重试机制
- 若缓存操作失败，通过消息队列（如RocketMQ）异步重试：
- public void updateData(Data data) { try { mysql.update(data); redis.del("data_key"); } catch (Exception e) { // 发送到MQ，由消费者重试删除缓存 mq.send("retry_delete_cache", "data_key"); } }
2. 数据校对任务
- 定时任务扫描数据库与缓存差异，修复不一致数据：
- @Scheduled(fixedRate = 3600000) // 每小时执行一次 public void checkConsistency() { List dbData = mysql.queryAll(); for (Data data : dbData) { String cacheValue = redis.get("data_" + data.getId()); if (!data.equals(cacheValue)) { redis.set("data_" + data.getId(), data); } } }
五、方案对比与选型建议
方案 | 一致性强度 | 实现复杂度 | 适用场景 |
双写 + 延迟删除 | 最终一致性 | 低 | 低频写、允许短暂不一致 |
订阅Binlog同步 | 最终一致性 | 高 | 高频写、要求最终一致性 |
读写锁控制 | 强一致性 | 中 | 对性能要求不高的关键数据 |
缓存过期 + 版本号 | 最终一致性 | 中 | 允许旧数据存在的查询场景 |
六、总结
- 最终一致性：大多数场景选择订阅Binlog或双写+补偿机制。
- 强一致性：需牺牲性能，通过分布式锁或版本控制实现。
- 兜底设计：缓存过期时间 + 数据校对任务，确保最终兜底修复。
- 根据业务权衡：一致性要求越强，系统复杂度和性能损耗越高。