什么情况下需要使用分布式事务，有哪些方案？

分布式事务面试标准答案

【核心定义】

分布式事务是指跨越多个独立数据节点（数据库、服务等）的原子性操作，确保在分布式环境下多个操作要么全部成功，要么全部失败回滚。

【关键要点】

使用场景：当业务操作需要同时修改多个独立数据库/服务的数据，且必须保证数据一致性时使用。
核心矛盾：CAP定理约束下，分布式系统无法同时满足一致性、可用性、分区容错性，需根据业务取舍。
方案分类：强一致性方案（2PC、3PC）、最终一致性方案（TCC、Saga、消息事务）。

【深度推导/细节】

为什么需要分布式事务？

Step 1 - 业务场景驱动：

微服务架构下，一个订单创建涉及：订单服务（写订单表）、库存服务（扣库存）、支付服务（扣款）
三个服务对应三个独立数据库，必须保证三者同时成功或失败

Step 2 - 单机事务的局限性：

传统数据库事务（ACID）仅适用于单数据库
跨数据库的XA协议性能差，不适合高并发互联网场景

Step 3 - 分布式事务的本质矛盾：

网络分区发生时：
1. 选择CP（一致性+分区容错性）→ 系统暂停服务等待网络恢复
2. 选择AP（可用性+分区容错性）→ 允许临时数据不一致，通过补偿机制最终一致

【关联/对比】

主流方案对比分析

方案	一致性	性能	复杂度	适用场景
2PC	强一致	低（同步阻塞）	低	传统银行、内部系统
TCC	最终一致	中	高	高并发电商、秒杀
Saga	最终一致	高	中	长流程业务（旅行预订）
消息事务	最终一致	高	中	异步解耦场景

版本演进差异

早期方案：2PC/XA（数据库层支持，但存在同步阻塞、单点故障）
互联网方案：TCC/Saga（应用层实现，性能好但业务侵入性强）
云原生方案：Seata AT模式（无侵入代理，基于全局锁+行锁）

【直击痛点：关键数字与设计】

1. 为什么2PC有“协调者单点故障”问题？

第一阶段（投票）：协调者询问所有参与者“能否提交”
第二阶段（执行）：协调者发送提交/回滚指令
致命缺陷：协调者宕机时，参与者资源锁定无法释放（阻塞时间通常设30s超时）

2. TCC的“空回滚”与“防悬挂”机制

空回滚：Try未执行，Cancel却先被调用 → 需记录Try阶段状态
防悬挂：Cancel比Try先到 → 需检查全局事务状态
实现关键：事务状态表 + 幂等控制

3. 消息事务的“本地消息表”设计

-- 关键表结构
CREATE TABLE local_transaction (
    id BIGINT PRIMARY KEY,
    biz_data VARCHAR(2000),    -- 业务数据
    status TINYINT,            -- 0-待发送,1-已发送,2-已完成
    retry_count INT DEFAULT 0, -- 重试次数（通常≤3）
    next_retry_time DATETIME   -- 指数退避重试
);

重试机制：首次1min，第二次2min，第三次5min（避免雪崩）
最终保障：定时任务扫描+人工补偿（死信队列）

『面试官追问』

Q1：分布式事务一定比不用的好吗？

不一定。需要权衡：

业务是否真的需要强一致？很多场景最终一致即可
复杂度代价：分布式事务增加系统复杂度30%以上
性能损失：2PC性能下降约40-60%

Q2：如何选择具体方案？

决策矩阵：

强一致性要求 → 2PC/3PC（金融核心）
高并发最终一致 → TCC（资源预留模式）
长业务流程 → Saga（每个步骤可补偿）
异步解耦 → 消息事务（可靠消息）

Q3：Seata的AT模式如何解决脏写？

核心机制：

前置镜像：UPDATE前保存旧数据
后置镜像：UPDATE后保存新数据
全局锁：行级锁防止其他事务修改
回滚时：用前置镜像恢复数据

Q4：分布式事务中的“最大努力通知”是什么？

最终一致性特例：

服务A完成本地事务后，尽最大努力通知服务B
B收到通知后执行业务，失败则记录日志
关键：允许B永远收不到通知（需对账系统兜底）
适用：非核心业务（如发送积分、通知短信）

【最佳实践总结】

避免使用：能通过业务设计避免分布式事务时优先避免（如数据冗余、本地缓存）
弱化一致：80%场景可用最终一致性替代强一致
超时设置：分布式事务超时建议5-10s，避免长时间资源锁定
监控必须：必须实现事务可视化追踪（如SkyWalking+Seata）

技术选型公式：金融支付用TCC，电商订单用Saga，日志通知用消息事务，传统系统用2PC。

# 什么情况下需要使用分布式事务，有哪些方案？