Wong Kosheng先从一个最典型的场景说起：你在一个电商平台下单，订单系统说“订单创建成功”，但库存系统却说“扣减失败”。用户看到的是商品还在，钱没了；你看到的是系统日志一片混乱，两边数据对不上。这不是代码 bug，而是分布式事务没做好。
微服务化之后，业务被拆成独立部署的服务，原本一个本地事务能干完的事，现在要跨多个服务、多套数据库协作。一旦其中某个环节失败，整个业务的数据一致性就崩了。这就是分布式事务要解决的核心问题：多个独立资源之间的数据一致性。
这篇文章我会把分布式事务的三大经典方案——两阶段提交（2PC）、三阶段提交（3PC）、TCC——从头到尾拆一遍。不只是讲流程，而是结合订单和库存这个最经典的业务场景，把每个方案的设计思路、核心流程、优缺点、坑点、实际落地时的细节全部说透。适合正在做微服务架构、中间件研发、或者被分布式事务折磨过的后端工程师阅读，也适合准备系统学习分布式理论的技术人作为入门参考。
1. 问题根源：为什么本地事务解决不了分布式场景
先弄清楚问题的本质。分布式事务的所有方案，都是为了对抗同一个东西：网络不可靠性和系统自治性。
在单库时代，我们用本地事务（BEGIN TRANSACTION / COMMIT）来保证数据一致性。事务的 ACID 特性由数据库自身保证，要么全部成功、要么全部回滚，friendly 得很。但到了微服务架构下，订单在订单库，库存在库存库，用户下单需要同时操作这两个库里的事务，问题立刻就来了：
- 你没法用一个数据库事务去跨库提交，因为两个库是独立的物理资源，各自有自己的事务管理器。
- 即便通过消息队列、补偿机制等手段，也只能做到“最终一致”，做不到绝对同时成功。
- 一旦订单服务提交成功后宕机、库存服务没收到消息，整个数据就处于不一致状态。
所以分布式事务本质上是多个事务参与者之间达成一致的协议问题。它要求不同节点之间通过某种协议来协调动作，要么大家一起成功，要么大家一起失败，要么通过补偿机制恢复到一致状态。
我见过不少团队踩过的坑：订单模块和库存模块在同一个事务里用 JPA 的 @Transactional 注解把两边方法一起包了，以为这样就能保证事务。结果一上线，库存偶尔对不上账，排查半天才发现是因为跨服务调用的回滚根本不生效——本地事务只对当前服务的数据源有效，远程调用的 Redis、ES、第三方库，一概不在事务管辖范围内。这个认知极其重要，理解不了这点，后面看任何分布式事务方案都会觉得隔了一层。
2. 两阶段提交（2PC）：最朴素却最沉重的协调式方案
两阶段提交协议（Two-Phase Commit，2PC）是最早期的分布式事务协议，也是后续很多方案的雏形。它把一个分布式事务拆成两个阶段：表决阶段（prepare） 和 提交阶段（commit/abort），协调者（Coordinator）负责统一调度，所有参与者（Participant）必须都准备好才允许最终提交。
2.1 协议流程拆解：表决阶段、提交阶段、回滚决策
我在工程中把 2PC 的流程映射成一个非常形象的类比：聚餐AA制，一个人负责点菜和分账。
第一阶段（表决）：协调者向所有参与者发送 prepare 请求。每个参与者收到后执行事务，写 undo 日志和 redo 日志，然后把自己置为“ready”状态——但此时并不真正提交，只是告诉协调者“我这边没问题，可以交钱”。如果有任何一个参与者回复“我失败了/我超时了”，协调者就能立刻判断事务需要回滚。
第二阶段（提交）：协调者收到所有参与者的 agree 响应后，再次向所有参与者发送 commit 请求。每个参与者收到后真正把事务落库，完成提交。如果第一阶段有人不同意，协调者就向所有参与者广播 abort。
这个协议的优点在于：逻辑简单清晰，实现起来容易，且能保证强一致性——只要协调者不撒谎、网络不出问题，所有参与者要么全提交、要么全回滚。这也是为什么像 PostgreSQL、MySQL 的 XA 协议、以及一些金融交易系统的老架构会用它的原因。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2.2 从订单和库存来看 2PC 的致命伤
用订单和库存这个场景来推演一下。假设用户下单，订单服务要去订单库插入一条订单记录，同时调用库存服务扣减库存。按 2PC 的做法：
- 协调者先让订单服务执行
prepare，在订单库里写入一条订单（状态是“预提交”），记录 undo 日志。 - 再让库存服务执行
prepare，在库存库里做预扣减，记录 undo 日志。 - 两边都准备好了，协调者发出
commit，两个库同时落库完成。
看起来完美。但真实生产环境里，2PC 有三个致命的问题：
第一，同步阻塞。 订单库因为 prepare 了，行记录被锁定；库存库也锁定了库存记录。从 prepare 到 commit 的整个窗口期，其他事务如果尝试操作这几条记录会被阻塞。如果其中某个服务响应慢，协调者卡在等待状态，所有参与者都得一直持有锁，整个数据库并发能力直线下降，这是 2PC 被诟病最多的点。
第二，单点故障。 协调者一旦宕机，整个事务卡死在半路。参与者不知道到底是提交还是回滚，只能继续持有锁等待恢复。网上有句话叫“2PC 天生就是为故障而设计的”，宕机时它几乎无解。
第三，脑裂时无法保证一致性。 即使协调者发给了所有参与者 commit 指令，网络分区也可能导致部分节点收到了 commit，另一部分没收到。收到 commit 的节点提交了，没收到的节点还在等待，数据又不一致了。这说明 2PC 只是尽可能降低不一致的概率，并没有完全消灭网络故障带来的不确定性。
2.3 实际工程中为什么很少直接用 2PC
说实话，现在做业务开发，几乎没有团队会裸写 2PC，因为它的代价太高。大多数人对 2PC 的接触是通过数据库的 XA 协议、JTA（Java Transaction API）或者一些分布式事务中间件（如早期的 Atomikos、Narayana）来间接实现的。
但真正在生产环境直接上 XA 的，我见得极少。一个核心原因是：2PC 的“强一致”是拿全局锁换来的，业务数据的并发量一上来，数据库死锁、锁等待超时、协调者阻塞，随便一个都能让系统雪崩。另一个原因是，跨服务调用时，参与者可能不是数据库而是第三方 API，API 不支持 prepare 阶段，2PC 根本没法落地。
3. 三阶段提交（3PC）：从通信阻塞到超时自决的改进
3PC（Three-Phase Commit）可以理解为 2PC 的增强版。它的设计目标就是解决 2PC 在协调者故障时参与者无限期阻塞的问题。把提交过程拆成三个阶段：CanCommit、PreCommit、DoCommit，并且为每个阶段引入超时机制。
3.1 协议阶段拆解：CanCommit、PreCommit、DoCommit
第一阶段 CanCommit（询问）：协调者问所有参与者“大家能提交这个事务吗？”注意，此时参与者并不真正执行事务，只检查自身状态，回复“可以”或者“不行”。这个阶段相当于提前做一次体检，过滤掉明显不可能成功的节点。
第二阶段 PreCommit（预提交）：参与者收到 precommit 请求后，执行事务并写 undo/redo 日志，然后进入“预提交”状态。如果所有人都准备好了，协调者会告诉大家“准备正式提交”。
第三阶段 DoCommit（正式提交）：协调者确认所有参与者都在预提交状态后，广播 doCommit。参与者收到后把事务落库，完成提交。
最关键的设计是：3PC 每个阶段都引入超时——参与者如果在超时时间内没收到协调者的下一步指令，默认执行 commit。这个行为定义了“超时即提交”策略，从协议层面避免了 2PC 里参与者无限等待协调者的问题。
3.2 用订单库存场景推演 3PC 与 2PC 的差异
我还用订单和库存来对比一下。假设协调者已经对订单服务和库存服务发出了 precommit，接着准备发 doCommit，此时协调者突然崩溃：
- 2PC 下，订单服务和库存服务会一直持有锁等待，直到协调者恢复，而且期间不能做任何决策，因为万一协调者之前已经广播过 commit，就会出现部分节点提交、部分节点回滚的惨案。
- 3PC 下，参与者有超时机制，超时后订单服务和库存服务都默认自身事务可以提交，于是各自提交。虽然这样可能产生一部分节点提交了、一部分节点回滚的不一致，但至少系统不会卡死。
从可用性角度，3PC 比 2PC 高了一个台阶。但从一致性角度，3PC 引入了“数据可能不完全一致”的风险，因为它不具备 2PC 那样的“要么全提交、要么全回滚”的绝对保障。说白了，3PC 想用牺牲强一致性来换取更低的阻塞风险和更高的系统可用性，这在很多业务场景下是划算的。
3.3 3PC 的实际应用与工程困境
实际上 3PC 在工程中的落地也不多。原因有两个：一是协议已经比较复杂，参与方之间消息交互多，网络开销大；二是在 DoCommit 阶段，如果网络分区导致一部分节点收到 doCommit 而另一部分没收到（超时后默认提交），两边数据不一致，需要靠后续的补偿机制来恢复，这让“最终一致”的实现成本也高。
所以业界现实是：2PC 和 3PC 更多是作为理论基础存在，真正被工程化、大规模落地的是 TCC、本地消息表、Saga 这类偏最终一致的方案。对大多数微服务团队来说，掌握 2PC/3PC 的原理是为了理解分布式事务的“坐标系”，而不是照搬实现。
4. TCC 核心实现原理：业务层面的分布式事务方案
TCC（Try-Confirm-Cancel）是目前微服务架构中落地最广、也最考验业务编码能力的分布式事务方案。它的核心思路非常朴素：把每个服务的业务操作拆成三个步骤：Try（尝试）、Confirm（确认）、Cancel（取消），通过业务逻辑来保证一致性。
它跟 2PC/3PC 最大的区别是——TCC 是“业务层”的方案，而不是“资源层”的方案。2PC/3PC 操作的是数据库事务全局锁，TCC 操作的是业务状态和业务动作，所以它不会长时间锁资源，对性能和并发更友好，但也意味着你必须自己实现每个阶段的业务逻辑，代码量和工作量成倍增加。
4.1 TCC 的三个阶段：Try、Confirm、Cancel 到底在做什么
先用订单+库存+账户余额这个完整电商下订单场景，把三阶段讲清楚：
Try 阶段（尝试）：这不是真扣钱、真扣库存，而是做“预检查 + 预占用”。比如：
- 库存服务：检查库存是否充足，冻结 N 件库存（准备好的待扣减状态），不真正扣减。
- 账户服务：检查余额是否充足，冻结 N 元资金（预占用），不真正扣款。
- 订单服务：创建一条订单记录，状态置为“待确认”。
Confirm 阶段（确认）：所有 Try 都成功之后，确认整个事务有效，把预占资源释放并真正提交。比如：
- 库存服务：把冻结库存真正扣减掉。
- 账户服务：把冻结资金真正扣除。
- 订单服务：订单状态从“待确认”更新为“已创建”。
Cancel 阶段（取消）：如果某个 Try 失败，或者协调者决定回滚，则对所有已成功的 Try 执行反向补偿。比如：
- 库存服务：把冻结的 N 件库存释放回可售库存。
- 账户服务：把冻结的资金解冻回余额。
- 订单服务：订单状态标记为“已取消”。
这个逻辑听起来不复杂，真正复杂的是在你把每一步对应到业务状态机时，要处理各种边界情况。我下面会用完整的状态转换来演示。
4.2 订单+库存+账户 的 TCC 实现细节
设计 TCC 时，每个服务除了业务表，最好加一张 TCC 记录表（事务控制表），用来记录事务状态，这样你才有幂等和控制的基础。我给一个非常具体的表结构设计参考：
sql复制CREATE TABLE `tcc_record` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`tx_id` varchar(64) NOT NULL COMMENT '全局事务ID',
`service_name` varchar(64) NOT NULL COMMENT '参与者服务名',
`method_name` varchar(64) NOT NULL COMMENT 'TCC方法名：try/confirm/cancel',
`status` tinyint(4) NOT NULL COMMENT '0-初始 1-成功 2-失败',
`payload` text COMMENT '业务参数JSON，confirm和cancel需要根据参数做补偿',
`created_at` datetime NOT NULL,
`updated_at` datetime NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_tx` (`tx_id`, `service_name`, `method_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
这里面的核心是 tx_id 全局唯一，用来串联一次分布式事务的所有参与者操作。当调用一个参与者的 try 方法时，先检查这张表里有没有 tx_id + service_name + method_name = try 的记录，有就直接返回成功（幂等），没有就插入一条 status=0 的记录再执行业务逻辑。
Confirm 和 Cancel 阶段的幂等也相同：先查记录，如果已存在并且状态是 1，说明已经执行过了，直接返回；如果没有，就先插入（status=0），然后执行业务逻辑，执行成功更新 status=1，失败可以记录 status=2 等待重试。
通常实际的 TCC 框架（比如 Seata 的 TCC 模式、hmily、tcc-transaction 等）都帮你封装了这部分逻辑，但理解表结构会让你在排查问题时不被框架的黑盒坑到。
4.3 一次下单请求的完整 TCC 状态流转过程
我以用户“小A”下单一双 999 元的鞋为例，把整个 TCC 流程推演一遍：
- 全局事务管理组件作为协调者，生成全局事务 ID（假设为
tx-20240611-001），开启 TCC 事务。 - 先执行订单服务 try：
- 在 tcc_record 插入
tx-20240611-001 + order + try，status=0。 - 在订单表插入订单记录（默认状态“待确认”）。
- 更新 tcc_record 该行为 status=1，返回成功。
- 在 tcc_record 插入
- 再执行库存服务 try：
- 在 tcc_record 插入
tx-20240611-001 + inventory + try，status=0。 - 校验可售库存 > 1，执行
UPDATE inventory SET frozen = frozen + 1 WHERE sku_id = 'sneaker-999' AND available >= 1。 - 更新 tcc_record 为 status=1，返回成功。
- 在 tcc_record 插入
- 再执行账户服务 try：
- 校验用户余额 >= 999，执行
UPDATE account SET frozen = frozen + 999 WHERE user_id = 'A' AND balance >= 999。 - 更新 tcc_record 该行为 status=1，返回成功。
- 注意前后顺序：涉及资金的服务尽量往后放，因为资金操作失败的可能性高，把它往后挪，前面流程失败导致的回滚面更小。
- 校验用户余额 >= 999，执行
- 所有 try 都成功，协调者进入 confirm 阶段：
- 订单服务 confirm：更新订单状态“待确认”为“已创建”。
- 库存服务 confirm：把冻结库存转成已扣库存：
UPDATE inventory SET frozen = frozen - 1, sold = sold + 1 WHERE sku_id = 'sneaker-999'。 - 账户服务 confirm：扣减余额：
UPDATE account SET balance = balance - 999, frozen = frozen - 999 WHERE user_id = 'A'。
- 如果第 4 步账户服务 try 失败（比如余额不足），协调者进入 cancel 阶段：
- 订单服务 cancel：把订单状态改为“已取消”，同时释放该订单占用的标识。
- 库存服务 cancel：执行反向 SQL：
UPDATE inventory SET frozen = frozen - 1 WHERE sku_id = 'sneaker-999'，把冻结的 1 件释放回可售库存。 - 账户服务 cancel：因为在 try 里失败了，没有创建冻结记录，所以 cancel 不做任何操作（空操作），但要保留一条幂等记录。
4.4 TCC 设计里的三个经典坑：空回滚、悬挂、幂等
这里我想专门提一下 TCC 实战中最容易踩的连环坑，这三个问题让无数团队在线上诉苦：“我们 TCC 上线后对不上账”。
第一个坑：空回滚（Empty Cancel）。如果协调者在调用库存服务的 try 阶段超时了（try 可能没有真正执行），然后协调者发起全局回滚，调用 inventory cancel，而库存服务的业务表里根本没有对应的冻结记录，这时候执行 cancel 如果去扣减 frozen，会把别人的冻结记录扣掉，造成数据错乱。
解决办法：cancel 操作执行前，必须检查 tcc_record 表里 tx_id + inventory + try 这条记录是否存在。如果不存在，说明 try 没有成功，此时 cancel 直接返回成功即可（空回滚）。
第二个坑：悬挂（Suspension）。try 超时后协调者发起了 cancel，但 cancel 执行完之后，try 的请求又慢悠悠地到达了库存服务并且执行成功，把库存冻结了。此时事务已经回滚完了，这笔冻结变成了一条没人管的状态。
解决办法：try 执行前检查 tcc_record 表里 tx_id + inventory + cancel 记录是否已经存在。如果存在，说明 cancel 已经执行过了，直接拒绝当前 try，不让它“悬挂”一个孤儿状态。注意 try 的判断条件跟 cancel 的判断条件是互相反向的，两者配合起来才能堵住这个漏洞。
第三个坑：幂等性。分布式系统里，confirm 和 cancel 接口可能会被调用多次。比如协调者没收到 confirm 的响应，会重新调一次 confirm；客户端重试时也会重复调 TCC 接口。所以每个参与者的 try、confirm、cancel 都必须幂等——以 tcc_record 表的存在性判断为幂等依据，已经执行过的方法直接返回之前的结果，不要重复执行业务操作。
我实测下来，幂等是 TCC 里最容易被忽略、也是最容易出事的点。很多团队一开始只关注“try 成功之后 cancel 要能释放资源”，完全不记得“同一个接口可能被调两次”这件事，最后对账对到怀疑人生。处理方式就是在框架层保证幂等，而不是靠每个业务开发自己拍脑袋。
4.5 Seata TCC 与手写 TCC 的取舍
提到 TCC 落地，绕不开 Seata 这个开源中间件。Seata 的 TCC 模式提供了一套相对完整的框架支撑，包括全局事务管理、分支事务注册、状态机驱动等。如果你所在团队用的是 Spring Cloud Alibaba，直接用 Seata 可以省掉很多重复造轮子的工作。
但 Seata 的 TCC 模式也有学习成本：你得理解它的事务协调逻辑、分支事务注册时机、超时与重试配置，还要适配它的编解码和通信协议。对于简单场景（比如就两三个服务，且数据量不大），手写一个轻量级 TCC 协调器反而更加灵活可控。我见过有团队直接基于 RocketMQ 事务消息实现了类似 TCC 的效果，也在线上稳定运行了很久，说明技术选型没有唯一答案，只有适合与不适合。
5. 从 2PC、3PC 到 TCC：三大方案的横向对比与选型建议
这一节我把三大方案放在同一个表里来对比，供你直接截图收藏。
| 维度 | 2PC | 3PC | TCC |
|---|---|---|---|
| 一致性级别 | 强一致性 | 弱一致（偏最终一致为主） | 最终一致，业务保证 |
| 阻塞情况 | 资源锁长时间持有，事务期间阻塞 | 每个阶段短超时，降低阻塞 | 不锁资源，只在业务层做资源预占，性能好 |
| 协调者故障处理 | 参与者无限阻塞 | 参与者超时后自行决策提交 | 继续按阶段推进或回滚，结合重试异常恢复 |
| 实现复杂度 | 相对简单，靠协议和资源锁 | 协议复杂度高，消息交互多 | 业务编码复杂，需自实现每个阶段 |
| 业务侵入性 | 低，数据库 / 资源层支撑 | 低，但实现是资源层 | 高，每个业务方法要拆 Try/Confirm/Cancel |
| 适用场景 | 单点强一致、低频操作 | 对可用性要求高、容忍小概率不一致 | 高并发业务、性能要求高，且业务可拆分补偿 |
| 代表技术 | XA 协议、JTA | 理论居多，工程实现少 | Seata TCC、hmily、tcc-transaction |
从我的实践来看，给业务团队做技术选型时，基本可以遵循这几个原则：
- 如果你追求极致的强一致，且业务量很小、对性能不敏感——2PC 或直接用数据库迁移工具，都是可选项。
- 如果业务需要高可用，而且可以接受极低概率的不一致（比如数据后续可以通过对账脚本修复）——3PC 理论可行，但工程上不如直接用最终一致方案来得省事。
- 如果业务并发量高、性能敏感、需要快速响应——TCC 是首选，但它的前提是你的业务操作能被拆成预留/确认/补偿三个语义。拆得出来才用 TCC，拆不出来就别硬上。
6. 分布式事务方案落地的其他思路：本地消息表与 Saga
文章最后再补一块我经常被问到的问题：除了 2PC、3PC、TCC，还有别的主流方案吗？答案是肯定的——本地消息表和 Saga，也是企业实战里使用非常频繁的方案。尤其在互联网公司，Saga 几乎和 TCC 平分秋色。
6.1 本地消息表：最落地可用的最终一致性方案
本地消息表的核心思想非常简单：业务数据和消息数据在同一个本地事务里写入。比如订单服务在事务里同时完成“插入订单记录”和“插入一条‘扣减库存’的消息”，然后通过一个后台 task 把消息表里的消息不断投递到 MQ，库存服务消费消息执行扣库存，扣完库存后回调用通知订单服务更新消息状态。
这个方案看起来朴素，却是生产环境里最稳定、最好排查的最终一致性方案之一。它不依赖分布式事务中间件，代码逻辑完全可控，数据不一致的窗口也很小（只有消息投递和消费的延迟）。
它最大的缺点是：消息表的写入和读取都在业务库里，订单量过大时消息表会成为一个隐藏的性能瓶颈；同时消息的投递、消费、重试、幂等都需要自己写一套轮子。因此很多团队会把这个方案升级为 事务消息，比如 RocketMQ 的事务消息模式，思路是一致的，但把消息表的管理交给了 MQ 中间件，减轻了业务负担。
6.2 Saga：长事务业务的最佳选择
Saga 来自分布式事务的另一个思想流派：把一个长事务拆分成多个本地子事务，每个子事务有正向操作和对应的补偿操作。执行时，按顺序编排正向操作；任何一个正向操作失败，就按逆序逐个执行补偿操作。
比如订单创建流程拆成：创建订单（正向）/ 取消订单（补偿）、锁定库存（正向）/ 解锁库存（补偿）、扣除余额（正向）/ 退还余额（补偿）。一旦扣除余额失败，就依次执行解锁库存、取消订单。
Saga 和 TCC 的最大区别在于：TCC 的 Try 阶段会“预占”资源，Saga 的正向操作就是直接执行，没有预占阶段。所以 Saga 的实现比 TCC 更轻量，但它的补偿方式也需要更精细的设计——因为你的正向操作可能已经把数据落到数据库里再回滚，数据被其他事务读到的话会产生不一致窗口。因此 Saga 更适合长事务、业务流程清晰、且各阶段允许短暂不一致的业务。
6.3 如何在这些方案之间做选择
如果你的业务形态是典型的电商下单、支付、库存三件套，我个人推荐的落地路线是这样的：
- 并发量中低、对强一致要求高：优先考虑本地消息表或事务消息，最简单也最可控。
- 并发量高、每个参与者都愿意做资源预留：TCC 最合适，但要提前做好空回滚、悬挂、幂等的预案。
- 业务流程特别长，比如订机票包含订酒店、租车、保险多个环节：Saga 更贴合业务，因为每个子事务本来就是独立可提交的业务单元。
- 不想深度自研，团队规模允许引入中间件：直接用 Seata，选 AT 模式还是 TCC 模式按场景来。
7. 一些非常重要的实战心得
这一节分享几个我在实践中反复给团队强调的原则。
第一，分布式事务不是银弹，每引入一种方案都在为系统增加复杂度。如果业务能通过接口幂等 + 消息重试 + 定期对账实现最终一致，就不要轻易上重量级分布式事务框架。相信我，很多业务在严格要求下其实并不需要引入 TCC 或者 Saga，一张本地消息表就能解决问题。
第二，幂等设计是分布式事务的地基。无论你用哪种方案，消息重复、请求重试、网络超时永远是常态，如果每个接口不做好幂等，任何方案都会功亏一篑。所谓幂等，就是同一个请求执行多次和执行一次的结果完全一致。用唯一 ID 做防重表是最常见的实现方式。
第三，监控和报警要提前规划。分布式事务系统链路长，参与者多，一旦出现数据不一致，你如果没有 trace 能力和事务状态监控，排查会变成一场灾难。所有参与者的 tcc_record 表、消息表、状态机流转日志，都要有完善的监控和 alert，比如“某个 tx_id 在某种状态停留超过阈值”就要告警，这样才有可能在问题扩散之前处理掉。
第四，从 2PC 到紧耦合的方案，逐级放宽一致性要求。我在方案评审时特别喜欢问一个问题是：“这个业务真的需要立刻一致吗？”如果用户支付后 1 秒内看到订单创建成功，和支付后 1 分钟内看到订单创建成功，体验上差别不大，那就应该走最终一致性方案。如果答案是“必须立刻”，再考虑 TCC 这类较强一致性方案。把需求吃透了，技术选型自然水到渠成。