一、引言为什么会有双写一致性问题在互联网高并发系统中Redis 作为缓存层几乎已经成为标配。引入缓存的初衷很简单——减轻数据库压力提升读取性能。但缓存一旦引入一个绕不开的问题就浮出水面数据库中的数据更新了Redis 中的缓存怎么办这就是所谓的“双写一致性问题”——当业务数据同时存在于数据库和 Redis 缓存中时如何保证两者数据的一致性。先看一个典型的场景用户修改了自己的昵称你更新了 MySQL但 Redis 中还存着旧的昵称。下一次用户查询时读到的是旧数据——这就是不一致。如果运气不好这种不一致可能持续很长时间直到缓存过期或被主动淘汰。二、主流解决方案详解方案一Cache-Aside Pattern旁路缓存模式这是最经典的缓存策略核心思路是应用程序在更新数据时先更新数据库再删除缓存。工作流程读请求先查缓存命中则直接返回未命中则查数据库回填缓存写请求先更新数据库再删除缓存为什么是“删缓存”而不是“更新缓存”更新缓存存在明显的并发问题线程A更新数据库为100线程B更新数据库为200如果两者以不同顺序更新缓存最终缓存值可能是错的。而删除缓存则简单得多——下次读请求自然会从数据库加载最新值。存在的问题先更新数据库再删除缓存如果删除失败怎么办缓存中会长期保留旧数据。另外在极端并发下可能出现这种情况线程A更新数据库后、删除缓存前线程B读到旧缓存并回填导致旧值覆盖新值。改进思路引入重试机制——删除缓存失败时将需要删除的 key 发送到消息队列由消费者不断重试直到成功。方案二延迟双删延迟双删是对 Cache-Aside 的改良流程如下先删除缓存更新数据库延迟 N 秒后再次删除缓存这个“延迟再删一次”的目的是什么主要是为了清除在更新数据库期间其他读请求可能写入的旧缓存数据。适用场景对一致性要求不高的非高并发业务。需要注意延迟时间怎么定一般设置为“读请求耗时 几百毫秒”的缓冲时间。但这个方案无法保证100%可靠延迟处理也可能不满足实时性需求。方案三订阅 Binlog 异步同步Canal Redis这是目前生产环境中广泛使用的方案核心思想是应用程序只负责操作数据库缓存由独立的同步服务自动维护。整体架构应用写入 MySQL → MySQL 生成 binlog → Canal 伪装成 MySQL Slave 拉取 binlog → 解析后推送给 Redis 客户端 → 更新或删除 Redis 缓存。Canal 的工作原理Canal 是阿里巴巴开源的 MySQL binlog 增量订阅组件它模拟 MySQL Slave 的交互协议向 Master 发送 dump 协议接收 binlog再将原始 byte 流解析为结构化的 INSERT/UPDATE/DELETE 事件。关键设计要点MySQL 必须开启 binlog 并设置为 ROW 模式Redis Key 设计要规范建议格式为{业务}:{实体}:{ID}设置合理的 TTL防止冷数据长期驻留同一 Key 的变更要按顺序处理如 Kafka 分区按主键哈希优势业务解耦、高吞吐低延迟、最终一致性有保障。局限性增加了组件复杂度需部署 Canal、可能还需引入 MQ且依赖 MySQL binlog。方案四分布式锁在并发更新场景下可以使用分布式锁如 Redisson在更新数据前锁定资源确保同一时刻只有一个操作能进行。优点强一致性有保障。缺点性能开销大不适合高并发场景。三、方案对比与选型建议方案一致性级别实现复杂度适用场景Cache-Aside 重试最终一致性低通用场景大多数业务延迟双删最终一致性低非高并发、一致性要求不高Canal Binlog最终一致性中需要解耦、变更频繁的场景分布式锁强一致性中并发冲突多、对一致性要求极高选型建议大多数业务场景Cache-Aside 删除重试机制就足够了简单可靠数据变更频繁、希望解耦Canal Redis 是更好的选择对一致性要求极高但并发不高可以考虑分布式锁终极兜底无论采用哪种方案都应该给缓存设置合理的过期时间这是最后一道防线四、总结缓存一致性没有银弹。强一致性、高性能、高可用三者往往不可兼得。在实际工程中我们需要根据业务场景做取舍对于用户维度的数据订单、用户信息并发冲突概率低Cache-Aside 足矣对于商品、菜单等基础数据Canal 订阅 binlog 过期时间能覆盖绝大部分需求秒杀、库存等对一致性要求极高的场景则需要更严谨的方案组合最后记住一点缓存是性能优化的手段不是数据的主存储。接受“最终一致性”的理念在绝大多数场景下用合理的方案兜底机制就能把不一致的风险控制在可接受范围内。
一、引言为什么会有双写一致性问题在互联网高并发系统中Redis 作为缓存层几乎已经成为标配。引入缓存的初衷很简单——减轻数据库压力提升读取性能。但缓存一旦引入一个绕不开的问题就浮出水面数据库中的数据更新了Redis 中的缓存怎么办这就是所谓的“双写一致性问题”——当业务数据同时存在于数据库和 Redis 缓存中时如何保证两者数据的一致性。先看一个典型的场景用户修改了自己的昵称你更新了 MySQL但 Redis 中还存着旧的昵称。下一次用户查询时读到的是旧数据——这就是不一致。如果运气不好这种不一致可能持续很长时间直到缓存过期或被主动淘汰。二、主流解决方案详解方案一Cache-Aside Pattern旁路缓存模式这是最经典的缓存策略核心思路是应用程序在更新数据时先更新数据库再删除缓存。工作流程读请求先查缓存命中则直接返回未命中则查数据库回填缓存写请求先更新数据库再删除缓存为什么是“删缓存”而不是“更新缓存”更新缓存存在明显的并发问题线程A更新数据库为100线程B更新数据库为200如果两者以不同顺序更新缓存最终缓存值可能是错的。而删除缓存则简单得多——下次读请求自然会从数据库加载最新值。存在的问题先更新数据库再删除缓存如果删除失败怎么办缓存中会长期保留旧数据。另外在极端并发下可能出现这种情况线程A更新数据库后、删除缓存前线程B读到旧缓存并回填导致旧值覆盖新值。改进思路引入重试机制——删除缓存失败时将需要删除的 key 发送到消息队列由消费者不断重试直到成功。方案二延迟双删延迟双删是对 Cache-Aside 的改良流程如下先删除缓存更新数据库延迟 N 秒后再次删除缓存这个“延迟再删一次”的目的是什么主要是为了清除在更新数据库期间其他读请求可能写入的旧缓存数据。适用场景对一致性要求不高的非高并发业务。需要注意延迟时间怎么定一般设置为“读请求耗时 几百毫秒”的缓冲时间。但这个方案无法保证100%可靠延迟处理也可能不满足实时性需求。方案三订阅 Binlog 异步同步Canal Redis这是目前生产环境中广泛使用的方案核心思想是应用程序只负责操作数据库缓存由独立的同步服务自动维护。整体架构应用写入 MySQL → MySQL 生成 binlog → Canal 伪装成 MySQL Slave 拉取 binlog → 解析后推送给 Redis 客户端 → 更新或删除 Redis 缓存。Canal 的工作原理Canal 是阿里巴巴开源的 MySQL binlog 增量订阅组件它模拟 MySQL Slave 的交互协议向 Master 发送 dump 协议接收 binlog再将原始 byte 流解析为结构化的 INSERT/UPDATE/DELETE 事件。关键设计要点MySQL 必须开启 binlog 并设置为 ROW 模式Redis Key 设计要规范建议格式为{业务}:{实体}:{ID}设置合理的 TTL防止冷数据长期驻留同一 Key 的变更要按顺序处理如 Kafka 分区按主键哈希优势业务解耦、高吞吐低延迟、最终一致性有保障。局限性增加了组件复杂度需部署 Canal、可能还需引入 MQ且依赖 MySQL binlog。方案四分布式锁在并发更新场景下可以使用分布式锁如 Redisson在更新数据前锁定资源确保同一时刻只有一个操作能进行。优点强一致性有保障。缺点性能开销大不适合高并发场景。三、方案对比与选型建议方案一致性级别实现复杂度适用场景Cache-Aside 重试最终一致性低通用场景大多数业务延迟双删最终一致性低非高并发、一致性要求不高Canal Binlog最终一致性中需要解耦、变更频繁的场景分布式锁强一致性中并发冲突多、对一致性要求极高选型建议大多数业务场景Cache-Aside 删除重试机制就足够了简单可靠数据变更频繁、希望解耦Canal Redis 是更好的选择对一致性要求极高但并发不高可以考虑分布式锁终极兜底无论采用哪种方案都应该给缓存设置合理的过期时间这是最后一道防线四、总结缓存一致性没有银弹。强一致性、高性能、高可用三者往往不可兼得。在实际工程中我们需要根据业务场景做取舍对于用户维度的数据订单、用户信息并发冲突概率低Cache-Aside 足矣对于商品、菜单等基础数据Canal 订阅 binlog 过期时间能覆盖绝大部分需求秒杀、库存等对一致性要求极高的场景则需要更严谨的方案组合最后记住一点缓存是性能优化的手段不是数据的主存储。接受“最终一致性”的理念在绝大多数场景下用合理的方案兜底机制就能把不一致的风险控制在可接受范围内。
