交付：分布式事务四种方案对比技术长文（2PC / TCC / SAGA / 本地消息表）

背景

我在做团队内部「分布式事务选型」的沉淀，想委托一篇对外可发布的技术长文，要求有真实工程视角，而不是把官方文档抄一遍。我本人有 8 年团队负责人经验，对一致性协议与消息中间件熟，验收时会重点看失败模式分析和取舍依据是否站得住。

最终要什么

一篇 3000–5000 字的中文技术文章，覆盖 4 种主流分布式事务方案的横向对比：

1. 2PC（两阶段提交）：以 XA 为例（MySQL XA 或 Atomikos），讲清 prepare/commit 两阶段、协调者单点问题、资源锁定窗口。
2. TCC：Try-Confirm-Cancel 三阶段，重点讲空回滚、幂等、悬挂三大问题，并给一个支付场景（下单 + 扣库存 + 扣余额）的伪代码骨架。
3. SAGA：长事务拆分 + 补偿链，对比正向补偿链与逆向补偿链两种编排（编排式 vs 协同式），给一个订单流转的 Mermaid 时序图。
4. 本地消息表 / 可靠消息最终一致性：以 RocketMQ 事务消息或 MySQL 本地表 + 扫描器为例，讲清「业务写 + 消息写」原子性如何保证，以及消息重投的幂等设计。

输入与上下文

• 目标读者：3–5 年后端工程师，能读懂伪代码，不熟悉 CAP/Paxos 细节。
• 不需要涉及 CAP 定理长篇科普，但每章结尾需点一句该方案的一致性强度（强一致 / 最终一致）与隔离级别（读己之写 / 无隔离）。
• 必须给一张横向对比表：维度包括 一致性强度、隔离级别、性能（QPS 量级）、可用性、实现复杂度、典型适用场景。
• 至少 2 个真实故障案例（可引用公开 postmortem，如数据库主从切换导致 2PC 卡死、TCC Cancel 漏补偿导致资损等），并给出你的复盘结论而不是只讲故事。

交付格式

• 正文 Markdown，标题层级 ≤ h4，含 Mermaid 时序图 ≥2 张。
• 文末附「选型决策树」：3–5 个分支问题，引导读者按业务特征落到具体方案。
• 文末附「开放问题」一节（≥3 条）：你认为当前方案仍未解决的痛点，供社区讨论。
• 代码片段用 ``` 围栏标注语言，伪代码用 Python 风格。

备注

• 文章会用于内部 Wiki + 对外博客，请避免使用未脱敏的公司内部系统名、内部 IP、内部表名。
• 引用第三方资料时请在文末列出处（≥3 条）。
• 我会在验收时按 acceptanceCriteria 逐条打勾，缺项会驳回，请一次做齐。