什么是分布式事务？

面试记录 2026-09-23

题目：什么是分布式事务？

难度：low

标签：arch/distributed/transaction, distributed/transaction, general/knowledge, difficulty/low

评分：⭐⭐⭐☆☆

我的回答

分布式事务是和单机事务对比而来的，它本质还是事务，想要达成的目标是数据的一致性。这个一致性可能是最终一致性，也可能是强一致性，但大多数分布式事务还是以最终一致性为目标的，因为强一致性带来的整体收益相对较低。当然，不同的业务场景也会选择使用强一致性的分布式事务。分布式事务，它基本上是通过 RPC 或者是 TCC 来实现的，另外还有一个 STAY 的算法。它实现的方式 RPC 的话，就是多个事务节点确认自己能执行，然后都确认了之后，然后统一进行一个执行提交，确保不会出现某事务节点不能执行，但是其他事务节点执行完，后续处理处理困难的问题。然后另外是 TCC，TCC 的话它是先尝试，然后做对应的回滚策略，测试大家能执行，然后没问题，先尝试，然后执行，要么执行成功，要么执行失败，执行失败之后大家做补偿，把对应的事务那问题进行补偿。都是目标是，要么完成整个事务内所有内容完成，要么整个事务内所有东西都不完成。核心目的还是这个一致性。只是实现方式从原本的单机由数据库自己完成，转化为分布式的，要么是自定义业务和实现补偿，要么是一些补偿的相应的机制去相应的自己处理。这是我理解的分布式事务。

点评

评分：⭐⭐⭐☆☆

优点：

• 从"单机事务对比"切入，正确指出本质仍是事务，核心目标是数据一致性
• 准确区分强一致 vs 最终一致，并说明"多数业务选最终一致"的收益权衡
• 2PC 的"prepare 全确认再 commit"流程描述清晰
• TCC 的 Try/Confirm/Cancel 补偿机制描述基本正确

不足：

• 术语混淆："RPC 实现"应为"2PC 协议"；"STAY"应为"Seata"
• 未提到"为什么要分布式事务"的触发场景（跨服务、跨库、跨资源）
• 未把分布式事务放在 CAP/BASE 框架下讨论
• 未列举主流实现模式（2PC / TCC / Saga / 本地消息表 / 事务消息 / Max Effort）
• 补偿机制的描述偏"业务自定义"，未提到框架化补偿（如 Seata / Netflix Conductor）

补充：

• 本质差异：单机事务由单一数据库通过 ACID + 锁 + WAL 保证；分布式事务没有单一"事务协调者"能直接控制所有参与者，只能靠协议/补偿/异步达成"跨节点原子性"
• 理论框架：CAP 里 P 无法避免时，只能选 CP（强一致，如 2PC/XA）或 AP（最终一致，如 Saga / TCC / 消息）；BASE 是对 ACID 的放宽，是最终一致的哲学基础
• 常见模式分类：强一致 → XA / 2PC；准强一致 → TCC / Seata AT；最终一致 → Saga / 本地消息表 / 事务消息 / 最大努力通知

面试记录 2026-10-19（第 2 次）

题目：什么是分布式事务？

难度：low

标签：arch/distributed/transaction, distributed/transaction, difficulty/low

评分：⭐⭐⭐⭐☆（4/5）

练习次数：2

我的回答

分布式事务是在多服务进行协助过程中保证整个事务链路执行的原子性的;

对比单机事务,分布式事务可能会跨服务,跨数据库,无法像单机事务那样依靠数据库自身的ACID去保证执行的原子性;

使用分布式事务的核心原因是在当前大流量或者说高并发的情况下,单机无法承载相应的服务要求,而开始使用分布式服务来承接流量,但是原本单体时代的事务要求没有变化,这就需要用分布式事务去进行处理这方面的问题;

常规的分布式事务手段主要是强一致和最终一致性两种;

常规的是2PC,AT,XA,TCC,或者事务消息来实现

点评

优点：

• 抓住了本质：跨服务/跨库链路下的原子性，单机 ACID 无法覆盖
• 讲清了动因：拆分/高并发导致事务边界跨节点
• 正确给出强一致 vs 最终一致两大类，并列举 2PC/AT/XA/TCC/事务消息

不足：

• 未放到 CAP/BASE 框架下说明（P 不可避免 → CP 或 AP）
• 未点明"没有单一数据库能统一控制所有参与者"这一根本约束
• 未提到补偿/对账/幂等是最终一致的落地前提

补充：

• CAP：分布式下 P 必选，只能在 C/A 间取舍；BASE 是最终一致的哲学基础
• 落地三件套：协议（2PC/TCC）+ 补偿（Saga）+ 兜底（对账/幂等/重试）

ℹ️ 完整讲解见上方首次记录（2026-09-23）