文章目录1. 物理环境与网络层故障最常见2. 应用程序异常崩溃3. 业务逻辑与时序冲突 如何解决删除失败解决方案演进方案 A消息队列MQ重试机制异步补救方案 B订阅 Binlog 异步删除目前的大厂标杆 深度思考失效即正义在分布式系统中**“先更新数据库后删除缓存”**虽然是最佳实践但它并非“原子操作”。从代码逻辑执行到网络传输每一个环节都存在导致删除失败的风险。我们可以将缓存删除失败的原因拆解为以下几个维度1. 物理环境与网络层故障最常见这是最不可控的因素网络抖动在数据库更新成功后应用程序向 Redis 发送DEL指令时恰好发生了网络波动或丢包导致指令未到达或响应超时。Redis 服务不可用此时 Redis 可能恰好因为 OOM内存溢出导致进程崩溃、正在进行 RDB 镜像持久化导致瞬间阻塞或者正在经历主从切换Failover。连接池耗尽高并发下应用程序的 Redis 连接池被占满无法获取可用连接来执行删除操作。2. 应用程序异常崩溃非原子性导致的“半路夭折”代码执行完db.update()后程序还没来得及执行redis.delete()JVM 就因为 OOM 崩溃了或者所在的 Pod/容器被 K8s 强制重启。异常处理不当程序员在代码中只对db.update()做了事务控制但在更新完数据库后的删除逻辑里没有写完备的try-catch或重试逻辑。如果删除时抛出异常且未被捕获这个“失效”指令就丢失了。3. 业务逻辑与时序冲突分布式事务失效在微服务环境下数据库和缓存往往不在同一个事务域内。即使数据库本地事务成功提交全局事务如 Seata或本地后续逻辑的异常也可能干扰删除动作。并发删除竞争极少数情况下多个实例同时对同一个 Key 进行写操作由于执行顺序的错乱早期的删除指令可能覆盖了晚期的删除逻辑虽然这在“删缓存”策略中影响较小但在“更新缓存”中是致命的。 如何解决删除失败解决方案演进针对上述失败风险工业界有两套主流的“补丁”方案方案 A消息队列MQ重试机制异步补救既然同步删除可能失败就利用 MQ 的持久化和重试特性。更新数据库成功。将“删除某个 Key”的消息发送到 MQ比如 RocketMQ 或 RabbitMQ。消费者从 MQ 消费消息并执行 Redis 删除。优点如果删除失败MQ 会自动按时间间隔重试直到成功为止。方案 B订阅 Binlog 异步删除目前的大厂标杆这是目前解决“双写一致性”最优雅的方案因为它完全解耦了业务代码。业务代码只管更新数据库啥也不用管缓存。中间件如 Canal伪装成 MySQL 的从库实时监听 Binlog数据库变更日志。解析与执行Canal 监听到数据变动后提取出 Key再由专门的消费者去执行 Redis 删除。优点只要数据库更新成功Binlog 就一定存在。即使删除进程挂了重启后依然能从上次的偏移量继续同步。 深度思考失效即正义在分布式系统设计中我们通常追求的是**“最终一致性”**而非“强一致性”。作为开发者在处理类似《小哈书》这类高并发内容社区时你不仅要防范“删除失败”还要配合“缓存过期时间TTL”进行双重保障。即使所有重试方案都挂了缓存到期后依然会强制回源数据库从而拉回正确的数据。你目前在实现 Redis 缓存时是否已经给关键业务数据比如用户信息、帖子详情设置了合理的随机抖动过期时间这种设计往往能解决很多由于“意外失败”带来的长效脏数据问题。