redis和数据库的一致性如何保证

1.如何保证缓存和数据库的一致性？

常用方案：

1. Cache Aside（写后删缓存）

2. 双写策略

3. MQ 异步保证最终一致性

**2.**Redis 事务失败能回滚吗？

不能回滚

解决方案：

• 使用 Lua 脚本 保证原子性

• 或在 应用层做补偿逻辑

应用层怎么补偿？ 记录操作日志，用于补偿。

如果是新增数据，就删除缓存

如果是更新数据，就还原旧值或者删除缓存

如果是计数器，就减回去

注意，补偿逻辑必须 幂等；

2.1补偿失败了怎么办？

记录失败日志

告警人工介入

定时任务再次补偿

3.MySQL 事务回滚了，但 Redis 已经写成功了，怎么办？

这是一个分布式数据不一致问题，因为：MySQL 支持 事务回滚，而Redis 不支持回滚。两者不在同一个事务里。我们的目标不是"强行回滚"，而是 最终一致性 + 应用层补偿

解决方案

通过 本地事务 + 可靠事件 + 补偿机制 保证最终一致性。

核心思想

以 MySQL 为准

Redis 允许短暂不一致

通过 补偿 / 对账 / 重试 修复

**✅ 方案一：应用层补偿（最常用）

执行流程**

1. 开启 MySQL 事务
2. 写 MySQL
3. 写 Redis
4. 如果 MySQL 提交失败 → 主动补偿 Redis

如果是新增数据，就删除缓存

如果是更新数据，就还原旧值或者删除缓存

如果是计数器，就减回去

注意，补偿逻辑必须 幂等；补偿失败要 记录日志 / 报警

✅ 方案二：先写 MySQL，后写 Redis（推荐）

mysql写成功再写redis

✅ 方案三：可靠事件 / MQ（进阶）

1. MySQL 事务提交成功后
2. 发送消息 → 更新 Redis
3. 消费者失败 → 重试

常用于高并发、核心业务

✅ 方案四：定期对账（兜底）

定时任务扫描 MySQL

2. 对比 Redis 数据
3. 不一致 → 自动修复

4.为什么不直接删缓存

删缓存是 最常见、成本最低的补偿

但要注意并发下的 缓存击穿 / 雪崩