一杯咖啡的时间，聊聊技术与成长
TCC 三大坑：空回滚、幂等、悬挂
网络一抖，Cancel 比 Try 先到（空回滚）、Confirm 被重试调了三遍（幂等）、回滚完迟到的 Try 又把资源冻上了（悬挂）。三大坑一个根源：远程调用的时序不可控。一张事务控制表管住三个接口的状态，全防住。
TCC：把事务搬进业务代码
XA 的性能债还不起，就用业务改造来换：Try 预留、Confirm 确认、Cancel 释放。把数据库的锁换成业务字段里的冻结标记，吞吐回来了，代价是每个参与者多写两个接口、多背一套幂等纪律。
2PC 与 XA：强一致的经典与枷锁
先表决再提交，全员点头才生效——2PC 用一把全局的钥匙换来了跨库强一致，代价是同步阻塞、协调者单点、不一致窗口三道枷锁。XA 把它做成了数据库标准，接入便宜，性能昂贵：低并发改造成本最低的方案，高并发链路的禁区。
理论基石：从 ACID 到 CAP 再到 BASE
ACID 的护城河出了单机就塌了；CAP 不是三选二，P 没得选，真正的取舍在 C 和 A 之间；BASE 把中间态合法化，最终一致成为互联网架构的宿命。理论不解决问题，但决定你选方案时问什么问题。
订单创建了，库存没扣：分布式事务从哪来的
单体拆成微服务，@Transactional 鞭长莫及：订单库提交了，库存服务却超时回滚，账对不上。网络不可靠、失败只是一部分、超时三态——分布式事务的所有方案，都是在给这三个现实打补丁。
收官复盘：一张作战地图串起整个系列
十六篇走完，从订单号撞车讲到踩坑清单。症状速查表、三条铁律、十项上线检查——把分布式 ID 的全部家当收进一张作战地图，下次再遇到发号问题，先翻这张图。
踩坑实录：前十四篇没写透的七个坑
前端拿到的 ID 尾号集体变 0，秒级时间戳八年后到期，多活机房发号撞车——这些坑不在架构图里，在生产事故清单里。七个高频翻车点逐个复盘：现象、根因、解法，一次清算。
高可用与降级：发号服务挂了怎么办
发号服务是单点中的单点：它一挂，全公司下单链路跟着挂。三道缓冲加一级降级阶梯——DB 挂了本地号段顶上，发号服务挂了雪花兜底，兜底 ID 打上标记可追溯。预案写在文档里没用，演练进了排期表才算数。
分片基因：把路由信息写进 ID
订单表分了二百五十六张，拿到订单号却不知道它在哪张表。路由表多一次查询，广播全库杀鸡取卵，基因法一步到位——把 user_id 的路由基因嵌进 ID 里，ID 自己会认路。代价也明码标价：分片规则从此焊死在号上。