微精选

因公众号更改推送规则，部分小伙伴看不到文章推送，请将 程序视点 设为星标,精品文章第一时间阅读

大家好！欢迎来到程序视点，我是你们的老朋友安戈。

前言

分布式系统的缓存一致性一直是后台架构师们绕不开的话题。

今天，我们就来深入聊聊“分布式环境下MySQL与Redis双写一致性”这件事。

相信不少朋友都遇到过缓存和数据库不同步导致的各种坑，本文将带你系统梳理原理、策略及最佳实践，助你在实际项目中游刃有余。

一、为什么数据会不一致？

在典型的架构中，MySQL作为可靠数据源，Redis作为缓存层。

每一次数据写入（包括增删改）都需要同步到这两个存储点。但同步过程中可能出现：

• 写MySQL成功，写Redis失败，导致Redis中存的是旧数据。
• 写Redis成功，写MySQL失败，导致Redis中是“脏数据”，数据库没有这份数据。
• 并发读写时，一个线程还没更新缓存，另一个线程读取了旧缓存，导致数据不一致。

这些问题本质上都源于多步骤写操作的原子性无法保证。

二、主流一致性策略与模式

1. Cache-Aside模式（旁路缓存）

最经典的缓存模式。应用直接与数据库和缓存交互，缓存不是写入的必经之路。

读流程：

1. 查询Redis，命中则返回。
2. 未命中则查MySQL，将结果写入Redis再返回。

写流程：

1. 更新MySQL。
2. 删除（Invalidate）Redis缓存，而非直接更新缓存。

为什么是删除（Invalidate）缓存，而不是更新缓存？

这是一个关键设计点！

性能：如果更新缓存，每次数据库写操作都要伴随一次缓存写操作，如果该数据并不经常被读取，那么这次缓存写入就是浪费资源的。
并发安全：在并发写场景下，更新缓存的顺序可能与更新数据库的顺序不一致，导致缓存中是旧数据。而删除操作是幂等的，更为安全。

这种模式通过“先更新数据库，再删除缓存”最大程度保证一致性。但在高并发场景仍可能出现极短暂的不一致窗口。

1，线程 A 更新数据库。
2，线程 B 读取数据，发现缓存不存在，从数据库读取旧数据（因为 A 还没提交或刚提交）。
3，线程 B 将旧数据写入缓存。
4，线程 A 删除缓存。

这种情况发生的概率较低，因为通常数据库写操作（步骤1）会比读操作（步骤2）耗时更长（因为涉及锁、日志等），所以步骤2在步骤1之前完成的概率很小。但这是一种理论上的可能。

2. Write-Through / Read-Through模式

缓存层负责与数据库同步。应用只和缓存交互。

• 写操作：先写缓存，缓存同步写入数据库，两者都成功才算写入成功。
• 读操作：读取缓存，未命中由缓存自动从数据库加载。

优点：逻辑对应用透明，一致性比 Cache-Aside 更好。

缺点：性能较差，因为每次写操作都必然涉及一次数据库写入。通常需要成熟的缓存中间件支持。

3. Write-Behind模式（异步写回模式）

应用写入缓存后立即返回，缓存层异步批量同步到数据库。

优点：写性能极高。

缺点：有数据丢失风险（缓存宕机），一致性最弱

适合对一致性要求不高、允许少量数据丢失的场景，比如点赞计数。

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

1. 延迟双删

在Cache-Aside基础上，写完数据库后，先删一次缓存，休眠一段时间后再删一次缓存。这样能清理掉并发读写场景下可能出现的旧数据。

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

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

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

2. 消息队列异步删除

将删除缓存的操作通过消息队列（如RocketMQ、Kafka）异步处理。消息消费失败可重试，提高删除操作的可靠性。

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

3. Binlog同步（推荐）

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

利用MySQL的Binlog日志，借助如Canal、Debezium等中间件实时订阅数据库变更，自动同步到Redis。业务代码无需关心缓存一致性，性能和一致性都非常高，但实现复杂度也较大。

工作原理：

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

优点：

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

缺点：

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

四、策略选择与最佳实践

通用建议：

• 多数应用推荐Cache-Aside（先数据库再删缓存）。
• 不一致窗口不可接受时，引入延迟双删或消息队列异步删除。
• 高要求项目采用Binlog同步。
• 一定给Redis缓存设置过期时间（TTL），保证旧数据自动失效。
• 与产品经理确认业务对一致性的容忍度，避免不必要的复杂架构。

好了，今天的分享就到这里了。大家对双写一致性有什么想法呢？欢迎评论区留言讨论哦~

最后

AI快速发展的时代，原有的生产方式和效率在被颠覆， 需要【有想法】且【懂得利用AI工具】的人才。

最近Cursor官方严控，Cursor Pro出号相对比较困难，每日Cursor Pro数量有限。没有拿到Cursor激活的小伙伴，可以选择Claude Code！