0. 先讲个让人睡不着的故事双十一凌晨 02:17客服群置顶三条消息用户A提示支付成功订单显示「待支付」库存却扣了我还能不能买 用户B余额扣了 199积分没到客服说「最终会一致」等到什么时候 用户C转账显示成功对方没收到你们是不是把钱吃了值班开发小王把三条链路日志拉出来发现一个共同点链路A 侧结果B 侧结果用户体感下单扣库存库存库扣减成功订单库插入超时回滚有扣无单支付加积分账户库扣款成功积分库MQ 丢了有扣无分跨行转账A 账户减成功B 账户加失败单边账每条链路里两边各自的本地事务都「成功/失败得清清楚楚」合在一起却是「全局灾难」。组长老张甩过来一句后来成了本专栏 slogan 的话「局部 ACID 很成功全局一致性很失败。」本系列就是把这句话背后的整套知识体系拆成能啃、能写代码、能面试、能避坑的七篇文章。1. 本专栏贯穿案例极简购电商为了避免每篇换故事我们固定一家虚构公司极简购MiniMall—— 把单体拆成微服务后的典型互联网电商。RPCRPC用户 AppAPI 网关订单服务 / order_db库存服务 / stock_db账户服务 / account_db积分服务 / point_db消息队列核心业务不变量有订单 ⇒ 必须有对应库存占用或已释放。支付成功 ⇒ 账户扣款与订单状态必须对齐。扣款成功 ⇒ 积分最终必须到账允许延迟不允许永久丢失。转账A 减 B 加不允许长期单边。关键人物小王13 年经验爱写Transactional以为加了注解就天下太平。老张十年架构说话阴阳怪气但特准。产品经理小美永远问「能不能保证实时一致」。DBA 老周一听 XA、长事务就血压升高。2. 专栏目录篇号标题你吃透什么核心案例01ACID 为什么管不到微服务本地事务边界、undo/redo、单边账复现同库转账 vs 跨库转账02CAP / PACELC / BASE为什么必须妥协、最终一致如何落地分区演练、支付中状态机032PC / 3PC 图解吃透强一致协议代价、为何微服务少用XA 转账、协调者宕机04TCC 实战冻结、空回滚、悬挂业务补偿三板斧与异常全集下单预扣库存完整代码05本地消息表与事务消息Outbox、半消息、回查、幂等下单通知积分06Seata AT 深度镜像与 undo一阶段提交、二阶段补偿、脏写校验订单库存 AT 落地07选型与全链路复盘一张表定生死、避坑清单极简购全链路改造3. 一张总图你要走的路拆服务拆库强一致硬指标可接受短暂不一致少参与者同机房本地 ACID 单库事务发现全局原子性缺失CAP: 分区下 C/A 二选一BASE: 接受中间态与最终一致一致性诉求?2PC / XA 认阻塞与延迟工程方案TCC 业务补偿消息 / OutboxSeata AT/SAGA可用幂等 补偿 对账生产可落地演进一句话2PC 正确但太慢太脆 → 3PC 想去阻塞却难落地 → TCC 把锁变成冻结 → 消息把跨服务改成可靠事件 → Seata 把补偿自动化。4. 读系列前的三个防骗提醒分布式事务不是银弹。能收口单库单事务永远优先收口。「最终一致」没有闭环 永久不一致。闭环 可靠投递 幂等 补偿 对账。ACID 的 C ≠ CAP 的 C。混为一谈面试直接掉段生产更会选错方案。下期预告《01ACID 为什么管不到微服务用一次「同库转账 vs 跨库转账」把地基砸透》我们会用可运行的 SQL/Java 片段亲手制造一笔「单边账」再讲清楚 undo/redo、隔离级别和「一致性到底是谁的责任」。