MySQL 与 Redis 如何保证双写一致性

优点：逻辑对应用透明，一致性比 Cache-Aside 更好。 缺点：性能较差，因为每次写操作都必然涉及一次数据库写入。通常需要成熟的缓存中间件支持。

策略三：Write-Behind Pattern（异步写回模式）

Write-Through 的异步版本。应用写入缓存后立即返回，缓存组件在之后某个时间点（例如攒够一批数据或定时）批量异步地更新到数据库。

优点：写性能极高。 缺点：有数据丢失风险（缓存宕机），一致性最弱。适用于允许少量数据丢失的场景，如计数、点赞等。

三、保证最终一致性的进阶方案

为了弥补 Cache-Aside 模式中的缺陷，我们可以引入一些额外的机制。

方案一：延迟双删

针对 Cache-Aside 中提到的'先更新数据库，再删除缓存'可能带来的并发问题，可以引入一个延迟删除。

1. 线程 A 更新数据库。
2. 线程 A 删除缓存。
3. 线程 A 休眠一个特定的时间（如 500ms - 1s）。
4. 线程 A 再次删除缓存。

第二次删除是为了清理掉在第 1 次删除后、其他线程可能写入的旧数据。这个休眠时间需要根据业务读写耗时来估算。

优点：简单有效，能很大程度上解决并发读写导致的不一致。 缺点：降低了写入吞吐量，休眠时间难以精确设定。

方案二：通过消息队列异步删除

为了解耦和重试，可以将删除缓存的操作作为消息发送到消息队列（如 RocketMQ, Kafka）。

1. 更新数据库。
2. 向消息队列发送一条删除缓存的消息。
3. 消费者消费该消息，执行删除 Redis 的操作。如果删除失败，消息会重试。

这保证了删除缓存的操作至少会被执行一次，大大提高了可靠性。

方案三：通过数据库 Binlog 同步（最优解）

这是目前最成熟、对业务侵入性最小、一致性最好的方案。其核心是利用 MySQL 的二进制日志（Binlog）进行增量数据同步。

工作原理：

1. 业务系统正常写入 MySQL。
2. 由一个中间件（如 Canal, Debezium）伪装成 MySQL 的从库，订阅 Binlog。
3. 中间件解析 Binlog，获取数据的变更详情（增、删、改）。
4. 中间件根据变更，调用 Redis 的 API 来更新或删除对应的缓存。

优点：

• 业务无侵入：业务代码只关心写数据库，完全不知道缓存的存在。
• 高性能：数据库和缓存的同步是异步的，不影响主业务链路的性能。
• 强保证：由于基于 Binlog，它能保证只要数据库变了，缓存最终一定会被同步。顺序也与数据库一致。

缺点：

• 架构复杂，需要维护额外的同步组件。
• 同步有毫秒级到秒级的延迟。

四、总结与最佳实践选择

通用建议：

1. 首选方案：对于大多数应用，从 Cache-Aside（先更新数据库，再删除缓存） 开始。它简单、有效，在大多数情况下已经足够。
2. 进阶保障：如果 Cache-Aside 的不一致窗口无法接受，可以引入延迟双删或消息队列异步删除来增强。
3. 终极方案：当业务发展到一定规模，对一致性和系统解耦有更高要求时，投入资源搭建基于 Binlog 的异步同步方案。这是业界证明最可靠的方案。
4. 设置合理的过期时间：无论如何，都给 Redis 中的缓存设置一个过期时间（TTL）。这是一个安全网，即使同步逻辑出现问题，旧数据也会自动失效，最终从数据库加载新数据，保证最终一致性。
5. 业务容忍度：最重要的是，与产品经理确认业务对一致性的容忍度。很多时候，1-2 秒内的数据不一致用户是感知不到的，不需要为此付出巨大的架构和性能代价。