type
Post
status
Published
date
Dec 18, 2025
slug
mysql6
summary
tags
技术探索
category
icon
password
先说结论：
分布式环境下想做到强一致性代价太大，用分布式事务性能又太差，所以实战中核心追求的是最终一致性，尽量把数据不一致的时间窗口缩到最短。
目前最靠谱的就三种方案:
• 第一种也是最常用的，先更数据库再删缓存。
为什么不直接更缓存?
因为高并发下很容易导致数据被覆盖，直接删缓存可以避免脏数据，但唯一的风险就是删缓存失败。
解决办法也很简单，加个重试机制，要么把删缓存的操作扔到消息队列里面，保证缓存最终会被删掉。
• 第二种兜底方案，就是延迟双删。
先删缓存，再更数据库，再异步延迟个几百毫秒再删一次缓存。
主要是解决并发带来的问题:比如说线程A删了缓存，正在修改数据库，线程B查缓存空了就去查旧的数据再写回缓存，会导致脏数据。
缺点就是时间不好精准把控，一般按照业务经验设个几百毫秒就够用了。
• 第三种也是最稳的一个，就是订阅binlog异步删缓存。
用阿里的Canal这类工具监听MySQL的binlog，只要MySQL的数据有变化就去异步删缓存，和业务代码完全解耦，还能保证一致性。
总结一下，对于这个问题不用死磕强一致性，根据业务能容忍的时间窗口来选择方案，避开脏数据就行。
分享