深入理解缓存一致性从旁路缓存到Binlog订阅前言在分布式系统中缓存一致性是一个经典而又棘手的问题。本文记录了我与一位技术同学关于“为什么更新数据库时要删除缓存而不是更新缓存”这一问题的深入探讨逐步延伸到各种解决方案的优劣对比。希望通过这篇对话式的技术博客帮助读者真正理解缓存一致性的本质。一、为什么是“删除缓存”而不是“更新缓存”问题的起点在旁路缓存Cache-Aside模式中更新数据的标准流程是先更新数据库然后删除缓存。很多人会问为什么不直接更新缓存呢这样缓存里不就是最新值了吗核心答案删除比更新更安全原因一并发脏数据问题假设采用“更新缓存”方案考虑以下时序操作A更新数据库v1 → v2操作B更新数据库v2 → v3操作B更新缓存v3操作A更新缓存v2网络延迟导致A后执行结果数据库是v3缓存是v2。脏数据诞生且可能长期存在。原因二资源浪费一个数据可能被更新100次但期间只被读取1次。如果每次都更新缓存前99次都是无用功。删除缓存采用懒加载思想只在真正需要时才加载。原因三复杂缓存值的处理缓存存的可能是聚合计算后的结果更新数据库原始字段后要同步更新这个复杂计算结果很麻烦。结论选择删除缓存本质上是用一次未来的读开销换取当前写操作的安全与简单。二、Cache-Aside的最大问题不一致窗口即使采用删除缓存方案仍存在一个天然的不一致窗口缓存刚好失效线程A读数据未命中缓存去数据库读旧值v1线程B写数据更新数据库为v2删除缓存线程A把旧值v1写回缓存结果数据库v2缓存v1。不一致窗口从此刻开始。为什么这是最大问题必然存在只要读写并发这个窗口就存在影响直观用户可能读到旧数据解决方案都有代价没有完美方案三、常见解决方案对比方案一设置缓存过期时间被动兜底redis.setex(key,30,value);// 30秒过期优点简单零额外成本缺点过期前脏数据一直存在适用绝大多数业务能容忍秒级不一致方案二延迟双删主动修复publicvoidupdateData(key,newValue){cache.del(key);// 第一次删除db.update(key,newValue);// 更新数据库Thread.sleep(100);// 等待cache.del(key);// 第二次删除}优点主动修复实现简单缺点阻塞写线程延迟时间靠“猜”适用对一致性要求稍高的场景方案三异步延迟删除publicvoidupdateData(key,newValue){db.update(key,newValue);mq.send(delCacheTask,delay100);// 异步不阻塞}优点写线程不阻塞缺点自己实现重试、幂等适用比同步sleep更优的改进版方案四订阅Binlog专业化方案架构 MySQL → Canal监听binlog→ MQ → 缓存删除服务优点零代码侵入业务只写数据库可靠性位点机制保证不丢消息自动重试失败后不断重试直到成功缺点引入额外组件运维成本高适用中大型系统高并发高一致性要求方案五分布式锁强一致性lock.acquire();try{cache.del(key);db.update(key,newValue);}finally{lock.release();}优点理论上的强一致性缺点性能断崖式下降适用几乎不用强一致性场景应重新评估架构四、深度辨析延迟双删的灵魂拷问困惑一第一次删除的意义是什么问题标准方案是先更新数据库再删除缓存延迟双删却先删缓存这不是走回头路吗回答第一次删除是为了对抗“更新数据库后、删除缓存前”这个微小窗口内的读请求命中旧缓存。虽然会短暂增加数据库压力但换取了“读请求不会读到明确不一致的旧缓存”。困惑二第一次删除后读请求写回旧缓存怎么办问题先删缓存 → 读请求读旧值 → 写回缓存 → 再更新数据库 → 这不还是一样有问题吗回答这是一个理论存在但概率极低的问题。因为“第一次删除”到“更新数据库”的时间窗口通常1ms在这个窗口内恰好有读请求并完成整个读流程的概率极低。大多数工程实践接受这个微小漏洞。如果追求理论完美可以加分布式锁。困惑三延迟双删真正解决的是什么问题关键认识延迟双删主要解决的是主从复制延迟问题第一次删除缓存更新主库主从同步需要时间如50ms读请求打到从库可能读到旧值第二次删除清理可能的脏缓存五、为什么Binlog订阅是“专业化标志”与延迟双删的本质区别维度延迟双删异步版订阅Binlog代码侵入每个写方法都要发MQ业务代码零感知可靠性需自己实现重试、位点天然at-least-once故障恢复脏数据可能残留位点保证不丢不重维护成本低纯代码中高需部署CanalMQ真正的优势零侵入业务代码只写数据库缓存同步完全解耦。加新表、新字段不需要改任何业务代码。位点保证Canal记录binlog位点崩溃重启后从上次位置继续消费不丢不重。这是MySQL生态久经考验的机制。架构清晰缓存策略独立演进业务团队不需要知道“哦这个数据还要删缓存”。一个形象的类比延迟双删定闹钟。猜快递5分钟后到设5分钟闹钟。万一堵车迟到白跑一趟。订阅Binlog装门铃。快递员必须按门铃你才开门不论何时到都不会错过。六、方案选型建议场景推荐方案小型项目几个写接口标准Cache-Aside 过期时间对一致性稍高能接受写延迟延迟双删同步sleep高并发不想阻塞写线程异步延迟删除MQ中大型系统追求架构优雅订阅Binlog强一致性要求库存、余额重新评估架构不依赖旁路缓存七、总结删除缓存而非更新缓存核心是避免并发脏数据用一次读开销换写操作安全。Cache-Aside的最大问题读写并发导致的不一致窗口这是用最终一致性换高性能的必然代价。延迟双删的本质用sleep等待主从同步完成第二次删除清理可能的脏数据。有理论漏洞但工程上可接受。Binlog订阅的专业性不在于时机更准而在于零侵入 位点机制保证可靠性。这是从“写代码补救”到“利用中间件保证”的质变。没有银弹根据业务场景选择方案强一致性场景应重新思考是否真的需要旁路缓存。后记本文源于一次深入的技术讨论。感谢那位不断追问的同学正是他的质疑让许多模糊的概念变得清晰。技术方案的选择往往不是非黑即白理解每个方案的适用边界和代价才是工程师真正的功力所在。如果你有任何疑问或补充欢迎在评论区讨论。
深入理解缓存一致性：从旁路缓存到Binlog订阅
发布时间：2026/6/13 19:51:24
深入理解缓存一致性从旁路缓存到Binlog订阅前言在分布式系统中缓存一致性是一个经典而又棘手的问题。本文记录了我与一位技术同学关于“为什么更新数据库时要删除缓存而不是更新缓存”这一问题的深入探讨逐步延伸到各种解决方案的优劣对比。希望通过这篇对话式的技术博客帮助读者真正理解缓存一致性的本质。一、为什么是“删除缓存”而不是“更新缓存”问题的起点在旁路缓存Cache-Aside模式中更新数据的标准流程是先更新数据库然后删除缓存。很多人会问为什么不直接更新缓存呢这样缓存里不就是最新值了吗核心答案删除比更新更安全原因一并发脏数据问题假设采用“更新缓存”方案考虑以下时序操作A更新数据库v1 → v2操作B更新数据库v2 → v3操作B更新缓存v3操作A更新缓存v2网络延迟导致A后执行结果数据库是v3缓存是v2。脏数据诞生且可能长期存在。原因二资源浪费一个数据可能被更新100次但期间只被读取1次。如果每次都更新缓存前99次都是无用功。删除缓存采用懒加载思想只在真正需要时才加载。原因三复杂缓存值的处理缓存存的可能是聚合计算后的结果更新数据库原始字段后要同步更新这个复杂计算结果很麻烦。结论选择删除缓存本质上是用一次未来的读开销换取当前写操作的安全与简单。二、Cache-Aside的最大问题不一致窗口即使采用删除缓存方案仍存在一个天然的不一致窗口缓存刚好失效线程A读数据未命中缓存去数据库读旧值v1线程B写数据更新数据库为v2删除缓存线程A把旧值v1写回缓存结果数据库v2缓存v1。不一致窗口从此刻开始。为什么这是最大问题必然存在只要读写并发这个窗口就存在影响直观用户可能读到旧数据解决方案都有代价没有完美方案三、常见解决方案对比方案一设置缓存过期时间被动兜底redis.setex(key,30,value);// 30秒过期优点简单零额外成本缺点过期前脏数据一直存在适用绝大多数业务能容忍秒级不一致方案二延迟双删主动修复publicvoidupdateData(key,newValue){cache.del(key);// 第一次删除db.update(key,newValue);// 更新数据库Thread.sleep(100);// 等待cache.del(key);// 第二次删除}优点主动修复实现简单缺点阻塞写线程延迟时间靠“猜”适用对一致性要求稍高的场景方案三异步延迟删除publicvoidupdateData(key,newValue){db.update(key,newValue);mq.send(delCacheTask,delay100);// 异步不阻塞}优点写线程不阻塞缺点自己实现重试、幂等适用比同步sleep更优的改进版方案四订阅Binlog专业化方案架构 MySQL → Canal监听binlog→ MQ → 缓存删除服务优点零代码侵入业务只写数据库可靠性位点机制保证不丢消息自动重试失败后不断重试直到成功缺点引入额外组件运维成本高适用中大型系统高并发高一致性要求方案五分布式锁强一致性lock.acquire();try{cache.del(key);db.update(key,newValue);}finally{lock.release();}优点理论上的强一致性缺点性能断崖式下降适用几乎不用强一致性场景应重新评估架构四、深度辨析延迟双删的灵魂拷问困惑一第一次删除的意义是什么问题标准方案是先更新数据库再删除缓存延迟双删却先删缓存这不是走回头路吗回答第一次删除是为了对抗“更新数据库后、删除缓存前”这个微小窗口内的读请求命中旧缓存。虽然会短暂增加数据库压力但换取了“读请求不会读到明确不一致的旧缓存”。困惑二第一次删除后读请求写回旧缓存怎么办问题先删缓存 → 读请求读旧值 → 写回缓存 → 再更新数据库 → 这不还是一样有问题吗回答这是一个理论存在但概率极低的问题。因为“第一次删除”到“更新数据库”的时间窗口通常1ms在这个窗口内恰好有读请求并完成整个读流程的概率极低。大多数工程实践接受这个微小漏洞。如果追求理论完美可以加分布式锁。困惑三延迟双删真正解决的是什么问题关键认识延迟双删主要解决的是主从复制延迟问题第一次删除缓存更新主库主从同步需要时间如50ms读请求打到从库可能读到旧值第二次删除清理可能的脏缓存五、为什么Binlog订阅是“专业化标志”与延迟双删的本质区别维度延迟双删异步版订阅Binlog代码侵入每个写方法都要发MQ业务代码零感知可靠性需自己实现重试、位点天然at-least-once故障恢复脏数据可能残留位点保证不丢不重维护成本低纯代码中高需部署CanalMQ真正的优势零侵入业务代码只写数据库缓存同步完全解耦。加新表、新字段不需要改任何业务代码。位点保证Canal记录binlog位点崩溃重启后从上次位置继续消费不丢不重。这是MySQL生态久经考验的机制。架构清晰缓存策略独立演进业务团队不需要知道“哦这个数据还要删缓存”。一个形象的类比延迟双删定闹钟。猜快递5分钟后到设5分钟闹钟。万一堵车迟到白跑一趟。订阅Binlog装门铃。快递员必须按门铃你才开门不论何时到都不会错过。六、方案选型建议场景推荐方案小型项目几个写接口标准Cache-Aside 过期时间对一致性稍高能接受写延迟延迟双删同步sleep高并发不想阻塞写线程异步延迟删除MQ中大型系统追求架构优雅订阅Binlog强一致性要求库存、余额重新评估架构不依赖旁路缓存七、总结删除缓存而非更新缓存核心是避免并发脏数据用一次读开销换写操作安全。Cache-Aside的最大问题读写并发导致的不一致窗口这是用最终一致性换高性能的必然代价。延迟双删的本质用sleep等待主从同步完成第二次删除清理可能的脏数据。有理论漏洞但工程上可接受。Binlog订阅的专业性不在于时机更准而在于零侵入 位点机制保证可靠性。这是从“写代码补救”到“利用中间件保证”的质变。没有银弹根据业务场景选择方案强一致性场景应重新思考是否真的需要旁路缓存。后记本文源于一次深入的技术讨论。感谢那位不断追问的同学正是他的质疑让许多模糊的概念变得清晰。技术方案的选择往往不是非黑即白理解每个方案的适用边界和代价才是工程师真正的功力所在。如果你有任何疑问或补充欢迎在评论区讨论。
的演进与通信机制)
