分布式事务深入（2PC、TCC、Saga、Seata）

• 2PC 的两阶段（prepare/commit）流程
• 协调者故障导致的阻塞
• 悬挂与锁持有

两阶段提交（2PC）分两阶段：准备阶段（prepare/vote），协调者向所有参与者发 prepare，参与者预留资源并返回准备结果；提交阶段（commit/abort），协调者收回所有确认后统一发 commit 或 abort。阻塞问题：若协调者在准备阶段后、提交阶段前发生故障，参与者已进入"准备完成"状态却拿不到最终指令，只能继续持有事务资源（锁、undo 日志）等待，形成"悬挂"（in-doubt）——参与者无法自行决定提交还是回滚，导致锁被长期占用、堵塞其他事务，系统进入不确定状态。这是 2PC 的固有缺陷：协调者单点故障会造成阻塞，且无法完全避免（需要协调者恢复或人工介入）。

2PC 强调"强一致"，但以阻塞为代价。协调者故障时参与者处于"已准备、未决"状态，既不能提交也不能回滚，只能持锁等待。缓解方式：协调者做持久化与高可用、参与者提供 xa_recover 查询未决事务、人工或超时补偿，但都无法彻底消除阻塞窗口。

• TCC 的三个阶段（Try/Confirm/Cancel）
• 幂等、悬挂、空回滚的防御
• 业务补偿思想

TCC（Try-Confirm-Cancel）是业务层面的分布式事务模式，分三阶段：Try（预留/检查资源，把操作前的资源状态固定下来，如冻结余额、预占库存）、Confirm（确认提交，把 Try 预留的资源真正扣减/生效）、Cancel（取消，回滚 Try 的预留，释放资源）。三个阶段都需业务实现，且 Confirm 与 Cancel 必须做好幂等（防止重复调用）。防御问题：幂等——Confirm/Cancel 可能被重复调用，需记录操作状态保证只生效一次；悬挂——Try 未执行成功但 Confirm/Cancel 已到达（靠空回滚与幂等表拦截）；空回滚——Try 没执行（或失败）就收到 Cancel，需要能识别"无 Try 状态"的 Cancel 且不产生副作用。通过事务控制表/状态机记录每个参与者的事务状态，保证幂等、防悬挂、防空回滚。

TCC 的核心是"业务预留 + 确认/取消"，把刚性资源操作拆成可补偿的三步。相比 2PC，TCC 不长时间持行级锁（Try 用冻结代替真实的锁），但要求业务提供补偿逻辑。防御点（幂等、悬挂、空回滚）是 TCC 落地成败关键，需用状态表与幂等控制。

• Saga 的正向服务与补偿服务
• Choreography（编舞）vs Orchestration（编排）
• 两种方式的优劣

Saga 是长事务模式：把一个大事务拆成多个本地事务（正向服务），每个本地事务有对应的补偿服务（反向操作），若某一步失败，则逆序执行已成功步骤的补偿，实现最终一致。编排（Orchestration）用中央调度器（Saga Coordinator/Orchestrator）统一编排各步骤及补偿，集中管理状态、流程清晰、易于监控与失败重试，但调度器是单点。Choreography（编舞）则无中央调度器，各服务通过事件（如消息队列）相互驱动，前一步完成后发布事件，下一步监听并执行，高可用、无单点，但流程分散、难以追踪与调试，出错时依赖事件传播。选择：业务复杂、需集中控制用 Orchestration；追求解耦与高可用用 Choreography。

Saga 的核心是"正向本地事务 + 反向补偿"，用最终一致替代强一致。Choreography 是事件驱动、去中心化；Orchestration 是中央编排、集中可控。两者都需补偿幂等与状态管理。Orchestration 更易监控回溯，Choreography 更解耦但难排障。

• AT 模式的写隔离与全局锁
• undo_log 前后镜像
• 反向 SQL 补偿

Seata AT 模式基于"侵入最小的自动补偿"：对业务 SQL 无感，通过代理自动生成补偿。其原理：执行前，解析 SQL 生成 undo_log（记录变更前镜像 before image 与变更后镜像 after image）；执行后，在全局事务提交前，通过全局锁（Global Lock）保证写隔离（不同全局事务对同一数据的写冲突检测）；提交时若全局事务成功，则删除 undo_log；若失败，用 undo_log 的反向 SQL 做补偿（把变更后的数据根据 after image 逆操作改回 before image，实现回滚）。AT 模式依赖数据库本地事务与 undo_log 表，无需业务写补偿代码，侵入小。其隔离性较弱（读未提交级别），需业务侧配合。

AT 模式的核心是"自动记录镜像 + 全局锁 + 反向 SQL"，把 2PC 的人工补偿自动化。它用 undo_log 实现回滚，用全局锁做写隔离。优点是侵入小、易用；缺点是隔离性弱（依赖业务约束），且多一次 undo_log 写入开销。

• AT 模式的隔离级别
• 全局读锁缺失与脏读
• 业务侧约束

Seata AT 模式提供的是读未提交（Read Uncommitted）级别的隔离，因为 AT 模式只通过全局锁做了"写隔离"（全局事务提交前，其他事务不能修改已加锁的数据），但没有全局读锁。这意味着：一个未提交的全局事务改了数据（本地已提交、全局未提交），另一个事务可能读到这些"中间态"数据，造成脏读。业务侧约束：应用需能容忍脏读（读未提交），或通过"SELECT FOR UPDATE"、业务层面保证读一致性，或在读时检查全局事务状态（如 Seata 的 after image 校验）。这是 AT 模式的固有取舍——用"读未提交"换取自动补偿与低侵入，对要求强隔离的业务需改用 XA 或业务约束。

AT 模式的隔离性弱是其关键特性。写隔离靠全局锁，读隔离缺失 → 脏读。业务若需强一致读，需在业务侧约束（如仅对最终一致场景使用、必要时加锁读）。理解这一点有助于选型：强一致读场景慎用 AT。

• 数据库 XA 的 2PC 实现
• xa_recover 与悬空事务恢复
• MySQL 与 PostgreSQL 的差异

数据库原生 XA 通过 XA 接口实现 2PC：应用（协调者）调用 XA START（开启分支）、XA END、XA PREPARE（准备阶段，参与者锁定资源）、XA COMMIT/XA ROLLBACK（提交阶段）。协调者崩溃后，参与者处于"已准备未决"（in-doubt）状态，可通过 XA RECOVER（如 MySQL 的 XA RECOVER）查询未决事务分支，协调者恢复后根据决策对每个分支执行 XA COMMIT/XA ROLLBACK 完成恢复，或人工介入。MySQL 与 PostgreSQL 差异：MySQL 支持 XA 但存在一些已知问题（如 XA 与 binlog 复制、部分隔离级别下的缺陷），且 MySQL 的 XA 在崩溃恢复时需依赖 xa_recover 与 binlog 协调；PostgreSQL 的 XA 支持不如 MySQL 常用（需通过连接池/中间件实现，且 PostgreSQL 原生对 XA 做统筹的能力有限），通常借助 JTA/XA 中间件。整体上两者都靠 XA 协议与 xa_recover 恢复，但兼容性与落地难度不同。

XA 是数据库层的 2PC 标准，优点是强一致、数据库原生支持；缺点是阻塞、协调者单点、性能差。崩溃恢复靠 xa_recover 找出未决事务并由协调者决策。MySQL 与 PostgreSQL 在 XA 支持上都有局限，需结合中间件与运维方案。

• 2PC 与 3PC 的阶段差异
• 3PC 的超时与预备提交机制
• 脑裂问题的无法彻底解决

2PC 有两阶段（prepare、commit），协调者故障会导致参与者阻塞。3PC 增加了一个"预备提交（pre-commit）"阶段并与超时结合：三阶段为 CanCommit（询问是否可提交）、PreCommit（协调者通知可提交，进入预备提交）、DoCommit（正式提交）。3PC 的改进：参与者引入超时机制——若在 pre-commit 后超时未收到协调者指令，参与者可自行提交（因为已确认可提交），从而缓解 2PC 的阻塞。但 3PC 仍无法彻底解决脑裂：在协调者故障、网络分区（脑裂）时，不同参与者的超时判断可能不一致（部分提交、部分回滚），导致数据不一致。因此 3PC 在缓解阻塞的同时引入新的不一致风险，实际工程中较少使用。

3PC 的本质是"用超时 + 预备提交换阻塞缓解"，但代价是允许参与者在超时后自行决策，可能产生脑裂下的不一致。2PC 强一致但阻塞，3PC 减少阻塞但引入脑裂风险。工程上 XA 类常见，3PC 少见。

• 四种模式的机制
• 适用场景
• 性能对比

Seata 四种模式各有侧重。AT：自动补偿，基于 undo_log 与全局锁，侵入小、易用，性能中上（多一次 undo_log 写入），隔离性弱（读未提交），适合大多数非强隔离的微服务场景。TCC：业务三阶段（Try/Confirm/Cancel）手动实现，无全局锁、灵活、性能较好，但需业务写补偿，适合预留资源型业务（库存、余额）。SAGA：长事务，正向本地事务 + 补偿，编排/编舞，适合跨服务长流程、最终一致，性能取决于中间件，可能较慢。XA：数据库原生强一致，性能最差（全局锁、阻塞、协调者开销），隔离性强，适合强一致、低并发场景。性能对比大致：TCC/SAGA 较灵活，AT 折中，XA 最慢。适用场景：强一致用 XA，自动补偿用 AT，业务复杂补偿用 TCC，长流程用 SAGA。

选型依据是"一致性要求、侵入性、性能、业务复杂度"。AT 优先（易用），业务需预留资源用 TCC，跨服务长流程用 SAGA，强一致低并发用 XA。性能与侵入性、隔离性各有取舍，需按场景权衡。

• 强一致与最终一致的含义
• 各自的适用业务
• 业务取舍

分布式事务的一致性强弱决定业务取舍。强一致（2PC/XA、Seata AT 在部分场景）：事务提交后所有节点立即看到一致结果，适合资金、订单等要求"要么都成功要么都失败、读立即可见"的强一致业务，但代价是性能低、阻塞、可用性受限。最终一致（Saga、TCC）：事务先执行本地操作，通过补偿/异步传播最终达到一致，中间状态可被读到（暂时不一致），适合对实时一致性要求不高、可用性与性能优先的业务（如积分、日志、非关键流程）。取舍：强一致保证"数据正确性优先"，最终一致保证"可用性与性能优先"。业务需根据"一致性的实时性要求、失败容忍度、性能需求"选择，并配合对账、幂等、补偿机制保证最终收敛。

一致性强弱是"正确性 vs 性能可用性"的权衡。强一致读立即可见但代价高；最终一致允许短暂不一致但通过补偿收敛。实践中绝大多数互联网业务用最终一致 + 对账兜底，只有资金类等强一致场景用强一致方案。

• 本地消息表的原理
• 事务消息（Half Message）原理
• 两者比较

消息最终一致性通过"本地事务 + 消息"解耦实现。本地消息表：在业务库建一张消息表，业务更新与写消息在同一本地事务中提交，之后由定时任务扫描消息表发送到 MQ，成功后标记已发送；消费方处理并幂等。这样保证"业务数据与消息"要么都成功要么都失败。事务消息（RocketMQ Half Message）：先发送一条半消息（Half Message，消费者暂不可见），再执行本地事务，若本地事务成功则向 MQ 提交（commit）消息，消息才对消费者可见；若失败则回滚（rollback）消息。如果本地事务执行中 MQ 端超时/未收到确认，MQ 会反查（check）本地事务状态决定提交或回滚。两者都实现了"本地事务与消息发送的一致性"，本地消息表依赖数据库与定时任务，事务消息依赖 MQ 的 half message 与回查机制。

两者核心都是"保证消息发送与业务事务原子"，避免"业务成功但消息没发"或"消息发了但业务失败"。本地消息表更简单、依赖数据库；事务消息依赖 MQ 能力（RocketMQ 特有）。都需消费方幂等。

• 悬挂事务检测
• 幂等去重
• 对账补偿

分布式事务的监控与治理关注三方面。悬挂事务检测：监控长时间处于"已准备/未决/进行中"状态的事务（如 2PC 的 in-doubt、TCC 的 Try 未负确认），通过超时与状态看板识别，及时清理或人工介入，避免阻塞与资源泄漏。幂等去重：分布式事务中重复请求（网络重试、消息重投）会导致重复执行，需用幂等表/唯一键/状态机保证同一操作只生效一次。对账补偿：定时对账任务比对各参与方的最终状态（如金额、库存、消息投递），发现不一致时触发补偿（重试、反向补偿、人工修复），保证最终一致。三者共同构成"监控-防重-兜底"的治理闭环。

分布式事务不能只靠"能提交"，还要"能监控、能重试、能修复"。悬挂检测保障健康，幂等保障正确（防重复），对账补偿兜底收敛（最终一致）。这是分布式事务在生产落地的关键。

• 业务拆分与单库事务
• 异步解耦
• 最终一致方案

高并发互联网场景常避免使用分布式事务，而用替代方案：业务拆分——把强耦合业务合并到同一库/同一事务内（避免跨库事务），或把跨系统的操作拆成独立可成对的步骤，从源头减少分布式事务需求；异步解耦——用消息队列把不要求强一致的操作异步化（如写订单后异步更新库存、发通知），降低同步链路与耦合；最终一致——用本地消息表、事务消息、Saga/TCC 等保证最终一致，配合幂等与对账。这些方案优先保证"可用性与性能"，把正确性靠"最终一致 + 补偿对账"兜底。只有在强一致且无法拆分时（如资金）才用分布式事务。

互联网业务的思路是"尽量避免分布式事务"：能单库就单库，能异步就异步，能最终一致就最终一致。分布式事务成本高（性能、阻塞、复杂度），只在强一致刚需时使用。通过拆分、异步、补偿把"跨库强一致"转化为"本地事务 + 最终一致"。

• TC 的角色
• 高可用部署方式
• 状态存储与故障转移

Seata 的 TC（Transaction Coordinator，即 Seata Server）负责全局事务的协调（记录分支、决策提交/回滚）。TC 高可用部署需保证 TC 不成为单点：TC 集群部署（多节点），通过注册中心（Nacos、Eureka、Consul 等）让客户端发现可用 TC；TC 的全局事务状态需持久化/共享存储（DB、Redis 等），使多节点共享同一份状态，故障时其他节点可接管，避免状态丢失；客户端重试与故障转移——TC 节点故障时，客户端通过注册中心切换到其他节点，恢复未决事务。对事务状态的管理要支持"提交/回滚决策"的持久化，保证故障后能恢复。部署上常见：TC 多实例 + 共享后端存储 + 注册中心 + 心跳健康检查。

TC 高可用的核心是"状态共享 + 集群 + 故障切换"。TC 是分布式事务的中枢，若单点故障则事务悬挂。通过共享存储（状态持久化）与多节点集群 + 注册中心发现，实现 TC 故障时无缝接管。客户端需支持重连与重试。

• 即时补偿（实时链路）
• 定时对账（兜底链路）
• 双通道的协同

分布式事务的补偿与对账双通道设计：即时补偿通道——事务执行失败时，立即（异步）触发反向补偿（如 Saga 的补偿、TCC 的 Cancel、消息重试），保证正常路径下快速收敛到一致；定时对账通道——定时任务定期比对各参与方的状态（如订单、库存、账务、消息投递），发现即时补偿通道遗漏的或不一致的数据，触发补偿/修复（重发、反向操作、人工介入）。两者协同：即时通道处理"正常失败"，保证性能与即时性；对账通道兜底"异常/遗漏"，保证最终一致的可靠性。对账需幂等、可重复执行，并输出对账报告。

双通道是"快路径 + 兜底路径"的设计。即时补偿保证快速收敛，对账保证"不遗漏、可修复"。单靠即时补偿在异常（消息丢失、程序 bug）时会漏，因此对账兜底不可缺。这是最终一致可靠性的关键。

• 前进（forward recovery）与后退（backward recovery）
• 失败决策策略
• 无补偿服务的设计

Saga 中某步骤失败后，需决定前进（forward）还是后退（backward）。前进恢复：对失败步骤做正向重试（如瞬时故障、可重试），适合"错误可重试且不会破坏一致性"的情况；后退恢复：对已成功步骤逆序执行补偿，适合"重试无法解决、需要回滚"的情况。选择依据：根据失败类型（可重试的瞬时错误 vs 不可恢复的业务错误）与业务约束（是否允许重试）决定。无补偿能力的服务（如第三方接口、不可逆操作）风险在于失败后无法回滚，避免进入不可恢复状态的方法：设计为"幂等且可重试"（多次调用结果一致），或在步骤前做预留/校验（确认可执行才执行），或将不可逆操作放在 Saga 最后一步（作为"必成功"的收尾），或保证失败时进入"待人工处理"状态而非自动回滚导致不一致。

Saga 的策略核心是"判断失败可重试还是需回滚"。前进重试适合瞬时错误，后退补偿适合需回滚。无补偿服务要设计成幂等、可重试、或放最后、或留人工兜底，避免"既不能继续也不能回滚"的僵局。

• 选型决策维度
• 决策树逻辑
• 技术栈匹配

分布式事务选型决策树基于三个维度：业务一致性要求（强一致 vs 最终一致）、性能容忍度（能否接受高延迟/低吞吐）、技术栈（是否用 Seata/中间件、数据库是否支持 XA）。决策逻辑：若业务要求强一致（资金、账务）且并发低、性能可容忍 → 用 XA/AT 强一致方案；若可接受最终一致 → 优先用消息最终一致、Saga/TCC（按业务复杂度：有预留资源用 TCC，长流程用 Saga，简单解耦用消息表/事务消息）；若业务能拆分避免跨库事务 → 优先拆分，不用分布式事务。技术栈匹配：若已有 Seata 且主流中间件，用 AT/TCC/SAGA；若用 RocketMQ 可做事务消息。整体原则：先尝试避免，再选择最轻量的方案，最后才用重型强一致方案。

选型决策树的核心是"先判断有没有必要、再选最轻的方案"。强一致刚需且无法拆分才用分布式事务；其余用最终一致 + 补偿。决策树帮助系统化地把"一致性、性能、技术栈"约束映射到具体方案。

• Percolator 的分布式事务模型
• Spanner 的外部一致性（TrueTime）
• 工程实现要点

Percolator 是 Google 的分布式事务模型，采用"两阶段提交 + 主键（primary）"设计：每个事务有一个主键（primary）作为事务的权威记录，通过主键的锁状态判断事务是否提交，配合参与者的锁与写提交，实现跨行原子事务；它用 Bigtable 的单元格存储锁与提交时间戳，崩溃恢复通过扫描主键锁状态决定提交/回滚。Google Spanner 的事务提供外部一致性（external consistency），即所有事务的提交时间顺序与全局真实时间顺序一致，实现基于 TrueTime（用 GPS 与原子钟同步的全局时间 API，能给出"时间区间"），通过提交时间戳与 TrueTime 的区间保证全局时间戳的有序分配，从而让读能读到所有已提交事务的写，实现线性一致性的分布式事务。

Percolator 用"主键 + 2PC + Bigtable 锁"实现分布式事务，简单但协调成本高；Spanner 用 TrueTime 提供全局有序时间戳，在不依赖集中协调的情况下实现外部一致性。两者的工程核心分别是"主键锁的崩溃恢复"与"全局时间戳的一致性"。

• 故障注入的类型
• 分布式事务的测试方法
• 演练的验证目标

分布式事务的测试与故障演练用于验证其在异常下的正确性。故障注入类型：协调者故障（TC/协调者崩溃、重启）、参与者超时（某分支响应超时、网络分区）、补偿失败（补偿逻辑执行失败、重复调用）、消息丢失/乱序、进程崩溃。测试方法：用测试框架（如 Chaos/Litmus 注入故障）在演练环境构造这些场景，验证：事务在协调者故障时的悬挂/恢复、参与者超时后的超时处理与最终一致、补偿失败后的重试与对账兜底、幂等性（重复请求不重复生效）。演练目标：确认系统在故障下能"收敛到最终一致或强一致"，不产生数据不一致、不永久阻塞、补偿可重试可达。演练应覆盖正常路径、故障路径与恢复路径，并检查对账与日志。

分布式事务的难点在"异常路径"。测试必须主动注入故障，验证"悬挂恢复、超时处理、补偿失败重试、幂等、对账"等机制真正生效。故障演练是保障分布式事务可靠性的关键手段，需在隔离环境反复验证。

• 分布式事务的延迟与吞吐开销测量
• 与消息最终一致的对比
• 成本不可接受的量级

分布式事务的额外延迟与吞吐开销测量：对比同一业务在"有无分布式事务"下的耗时与吞吐，测量点包括：事务提交延迟（2PC 的 prepare + commit 往返、全局锁等待、undo_log 写入）、吞吐（TPS 上限，受协调者与锁并发限制）、以及故障时的恢复时间。可通过压测（JMeter 等）对比基线方案，量化分布式事务带来的额外 RTT 与吞吐下降。对比消息最终一致方案：消息方案把"同步跨库事务"变成"本地事务 + 异步消息"，延迟低、吞吐高、无阻塞。成本不可接受的量级：当业务 QPS/TPS 高（如每秒数千以上）且对一致性实时性要求不高时，分布式事务的全局锁、协调者与阻塞会显著拖垮吞吐，其成本（降低的吞吐、增加的延迟、复杂度）不可接受，此时应改用消息最终一致。具体阈值取决于硬件与中间件，但"高并发 + 非强一致"场景几乎都不适合分布式事务。

测量的核心是"量化分布式事务的代价"（延迟增加、吞吐下降、锁竞争）。消息最终一致以"短暂不一致"换取高性能。当吞吐要求高、强一致非必需时，分布式事务的代价（性能损失、复杂度）不可接受，应选消息最终一致。需结合业务量级与一致性要求做技术选型。