题目：常见的分布式事务有哪些？
难度：medium
评分：⭐⭐☆☆☆
常见的分工数主要方案，也就是强一致性跟弱一致性两个方向。强一致性像 2PC、3PC，一次性成功就成功，不成功大家就一起回滚，没有什么中间态。然后另外还有就是 TCC，尝试尝试去提交，然后确认或者取消，做事务的补偿机制，而不是做事务的占留。它是在先把事务执行，然后根据如果出现异常了，就进行回滚的补偿机制来实现的。然后还有一个 STAY。它里边自带几种模式。
评分：⭐⭐☆☆☆
优点：
不足：
补充：
核心考点定位：考察对分布式事务模式的广度认知——能否系统性地列举并分类，而非仅罗列 2-3 个。
知识点拆解：
| 模式 | 一致性 | 侵入性 | 性能 | 阻塞 | 典型场景 |
|---|---|---|---|---|---|
| 2PC | 强 | 低 | 低 | 会阻塞 | 早期银行 |
| 3PC | 强 | 低 | 低 | 可能阻塞 | 学术为主 |
| XA | 强 | 低 | 低 | 会阻塞 | MySQL 跨库 |
| Seata AT | 强 | 低 | 中 | 不阻塞 | 订单+库存 |
| TCC | 强 | 高 | 中高 | 不阻塞 | 核心金融 |
| Saga | 最终 | 中 | 高 | 不阻塞 | 长链路编排 |
| 本地消息表 | 最终 | 中 | 高 | 不阻塞 | 上下游解耦 |
| 事务消息 | 最终 | 低 | 高 | 不阻塞 | 支付通知 |
| 最大努力通知 | 最终 | 低 | 高 | 不阻塞 | 第三方通知 |
本地事务：insert order + insert message_table ← 同一本地事务
定时扫表：扫 status=INIT 的消息 → 发 MQ → 更新 status=SENT
消费端：幂等消费，失败重试 业务发 half message → MQ 暂存 → 执行本地事务 → 提交/回查
本地事务成功 → commit half message → 正常投递
本地事务失败 → rollback half message → 不投递
不确定 → 回查业务方考察方向：
延伸递进面试题：
面试官您好，分布式事务的模式我一般按一致性强度分三类。 强一致类主要有：2PC、3PC、XA、Seata AT。2PC 是经典的 Prepare+Commit 两阶段协议，XA 是 MySQL 内置的实现。3PC 是 2PC 的改进版，加了一个预提交阶段来缓解阻塞，但工程实践中没有替代 2PC。Seata AT 是"自动补偿"模式，框架代理数据源，业务代码基本不用改。 准强一致类主要是 TCC。业务需要实现三个方法：Try 冻结资源（比如扣冻结余额，不实际扣款）、Confirm 提交（真的扣款）、Cancel 补偿（释放冻结）。TCC 侵入性最高，但可控性和审计性也最好，适合核心账务、跨支付等强一致场景。 最终一致类主要有：Saga、本地消息表、事务消息、最大努力通知。 - Saga 是长链路状态机编排，每个活动有对应补偿，适合多步业务流程 - 本地消息表是"本地事务+消息表+定时扫表"，业务方自建扫表逻辑，上下游解耦 - RocketMQ 事务消息用 half message + 回查机制，把"扫表"内置到 MQ 里，业务方代码更简洁 - 最大努力通知是最弱的一类，只保证"尽力通知 N 次"，适合支付成功通知、物流同步 另外 Seata 框架本身有 4 种模式：AT、TCC、Saga、XA，分别覆盖强一致到最终一致的不同场景。 落到业务选型上，我的判断原则是：核心账务 → TCC/XA；订单主链路 → Seata AT 或 TCC；通知/积分/风控 → 本地消息表或事务消息。主链路保证强一致，副链路用最终一致换性能，这是分层治理的核心思想。 选型不是看技术先进性，而是看业务对一致性的容忍度——这也是为什么柔性事务在大厂业务里越来越主流。
题目：常见的分布式事务有哪些？
难度：medium
评分：⭐⭐⭐⭐☆（4/5，本轮第 2 次作答，比上次进步明显）
常见的分布式事务有哪些？这个指的是处理分布式事务的方案吧？
主要分两类，一类是强一致性的分布式事务，类似于 2PC、3PC。另外一类是最终一致性的分布式事务，比如本地消息表，事务消息一类的。
二者核心差异就是对于事物的一致性要求是否要求及时强一致，能否接受中间态。如果不能接受中间态，比如类似于银行系统，这些要求必须随时是强一致的，就使用 2PC 这种方案。如果是像订单系统这种，可以接受短时间的不一致，就使用最终一致性的这种方案，比如事务消息、本地消息表一类的操作方案来实现最终的一致性。
当然还有另外一种模式，就是规避事务，尽可能的不去使用分布式事务，要使用事务也是在本地事务内搞定。然后事后回滚，这衍生就是类似于 TCC 这一套。你说它是事务，它是。然后它通过回滚自身业务的绑定的回滚去实现事务的一致性。呃，如果是一致了，就正常执行，如果不一致了就走回滚取消这一套。
评分：⭐⭐⭐⭐☆（比 2026-09-23 的 ⭐⭐☆☆☆ 有明显提升）
优点：
不足：
补充：
核心考点定位：考察对分布式事务模式的广度认知 + 分类能力 + 场景选型。相比 2026-09-23 那次，本次的分类框架和业务场景化明显提升。
知识点拆解：
| 模式 | 一致性 | 侵入性 | 性能 | 阻塞 | 典型场景 |
|---|---|---|---|---|---|
| 2PC | 强 | 低 | 低 | 会阻塞 | 早期银行 |
| 3PC | 强 | 低 | 低 | 可能阻塞 | 学术为主 |
| XA | 强 | 低 | 低 | 会阻塞 | MySQL 跨库 |
| Seata AT | 强 | 低 | 中 | 不阻塞 | 订单+库存 |
| TCC | 强 | 高 | 中高 | 不阻塞 | 核心金融 |
| Saga | 最终 | 中 | 高 | 不阻塞 | 长链路编排 |
| 本地消息表 | 最终 | 中 | 高 | 不阻塞 | 上下游解耦 |
| 事务消息 | 最终 | 低 | 高 | 不阻塞 | 支付通知 |
| 最大努力通知 | 最终 | 低 | 高 | 不阻塞 | 第三方通知 |
本地事务：insert order + insert message_table ← 同一本地事务
定时扫表：扫 status=INIT 的消息 → 发 MQ → 更新 status=SENT
消费端：幂等消费，失败重试 业务发 half message → MQ 暂存 → 执行本地事务 → 提交/回查
本地事务成功 → commit half message → 正常投递
本地事务失败 → rollback half message → 不投递
不确定 → 回查业务方考察方向：
延伸递进面试题：
面试官您好，分布式事务的模式我一般按一致性强度分三类。 强一致类主要有：2PC、3PC、XA、Seata AT。2PC 是经典的 Prepare+Commit 两阶段协议，XA 是 MySQL 内置的实现。3PC 是 2PC 的改进版，加了一个预提交阶段来缓解阻塞，但工程实践中没有替代 2PC。Seata AT 是"自动补偿"模式，框架代理数据源，业务代码基本不用改。 准强一致类主要是 TCC。业务需要实现三个方法：Try 冻结资源（比如扣冻结余额，不实际扣款）、Confirm 提交（真的扣款）、Cancel 补偿（释放冻结）。TCC 侵入性最高，但可控性和审计性也最好，适合核心账务、跨支付等强一致场景。 最终一致类主要有：Saga、本地消息表、事务消息、最大努力通知。 - Saga 是长链路状态机编排，每个活动有对应补偿，适合多步业务流程 - 本地消息表是"本地事务+消息表+定时扫表"，业务方自建扫表逻辑，上下游解耦 - RocketMQ 事务消息用 half message + 回查机制，把"扫表"内置到 MQ 里，业务方代码更简洁 - 最大努力通知是最弱的一类，只保证"尽力通知 N 次"，适合支付成功通知、物流同步 另外 Seata 框架本身有 4 种模式：AT、TCC、Saga、XA，分别覆盖强一致到最终一致的不同场景。 落到业务选型上，我的判断原则是：核心账务 → TCC/XA；订单主链路 → Seata AT 或 TCC；通知/积分/风控 → 本地消息表或事务消息。主链路保证强一致，副链路用最终一致换性能，这是分层治理的核心思想。 选型不是看技术先进性，而是看业务对一致性的容忍度——这也是为什么柔性事务在大厂业务里越来越主流。
题目：常见的分布式事务有哪些？
难度：medium
标签：arch/distributed/transaction, distributed/transaction, difficulty/medium
评分：⭐⭐⭐⭐☆（4/5）
练习次数：3
常见的分布式事务主要有强一致性的、最终一致性的，还有中间态性质的。
2PC,3PC,XA,AT 其实都算强一致性的,TCC会存在一段时间的中间情况,但是同一个线程内会执行补偿,和回退操作,算中间态性质;
SAGA和事务消息等算最终一致性,会有中间态,但是最后会保证结果正常;
日常使用的话不同场景选择不同;
常规的选择如果强一致性要求会选择 2PC,XA 和 AT,其中 3PC 虽然是对2PC 的优化,但是使用的很少;AT 业务层不用做太多侵入使用的也比较多,XA 模式需要依赖数据库的 XA,XA,AT 都需要保证事务在一个数据库上进行,这影响了部分使用;
TCC 实现复杂度会比较高,但是更通用,不会受限于数据库;
事务消息需要有 MQ 引入,并且需要 MQ 支持事务消息才行;
saga 复杂度会高一些,但是主要用在长一些的事务上
优点：
不足：
补充：
ℹ️ 完整讲解见上方首次记录（2026-09-23）