当前位置：首页 > news >正文

深入理解缓存一致性：从旁路缓存到Binlog订阅

news 2026/6/13 19:51:15

深入理解缓存一致性：从旁路缓存到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,delay=100);// 异步，不阻塞}

优点：写线程不阻塞
缺点：自己实现重试、幂等
适用：比同步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
故障恢复	脏数据可能残留	位点保证不丢不重
维护成本	低（纯代码）	中高（需部署Canal+MQ）

真正的优势

零侵入：业务代码只写数据库，缓存同步完全解耦。加新表、新字段，不需要改任何业务代码。
位点保证：Canal记录binlog位点，崩溃重启后从上次位置继续消费，不丢不重。这是MySQL生态久经考验的机制。
架构清晰：缓存策略独立演进，业务团队不需要知道“哦，这个数据还要删缓存”。

一个形象的类比

延迟双删：定闹钟。猜快递5分钟后到，设5分钟闹钟。万一堵车迟到，白跑一趟。
订阅Binlog：装门铃。快递员必须按门铃你才开门，不论何时到都不会错过。

六、方案选型建议

场景	推荐方案
小型项目，几个写接口	标准Cache-Aside + 过期时间
对一致性稍高，能接受写延迟	延迟双删（同步sleep）
高并发，不想阻塞写线程	异步延迟删除（MQ）
中大型系统，追求架构优雅	订阅Binlog
强一致性要求（库存、余额）	重新评估架构，不依赖旁路缓存