场景——分布式

一、什么是分布式？

各组件分别部署在不同的服务器，比如一个组件的集群。

用于解决单点故障问题，性能问题。

 

二、什么是分布式事务？

事务的四大特性：

• 原子性：一个事务中的所有操作，要么全部成功，要么全部失败；
• 一致性：在事务开始或结束时数据库应该在一致状态；
• 隔离性：事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知；
• 持久性：一旦事务完成，就不能返回，事务对数据所做的变更就完全保存在了数据库中；

 分布式事务：跨越多个组件（服务、数据库、消息队列）的事务操作集合，核心目标是保证这些跨节点的操作要么 “全部成功”，要么 “全部失败”，最终实现数据的一致性。

 

三、分布式事务常见解决方案

1、2PC（依赖数据库）

1. 准备阶段：协调者向所有参与者发送 “准备请求”；
2. 提交阶段：若所有参与者均返回 “就绪”，协调者发送 “提交请求”，参与者执行最终提交；若有任一参与者失败，协调者发送 “回滚请求”，所有参与者撤销操作；

优点：实现强一致性，逻辑简单；
缺点：

• 阻塞问题：准备阶段后，参与者需锁定资源等待提交 / 回滚，长时间阻塞可能导致性能瓶颈；
• 协调者单点风险：若协调者崩溃，参与者将一直阻塞

2、3PC

在 2PC 基础上增加 “预提交” 阶段和超时机制，减少阻塞风险，弱化协调者单点依赖；

实用性较差，仅解决了 2PC 中“准备阶段”对资源长时间锁定的问题。

3、TCC（偏代码逻辑）

1. Try：尝试执行操作，预留资源（如扣库存前先冻结库存，避免被其他事务占用）；
2. Confirm：若所有 Try 成功，确认执行实际操作（如将冻结的库存真正扣减）；
3. Cancel：若任一 Try 失败，取消操作（如解冻冻结的库存）；

优点：

• 无锁阻塞：Try 阶段仅预留资源，不实际提交，性能较高；
• 灵活性强：可根据业务自定义补偿逻辑。

缺点：

• 业务侵入性强：需手写 Try/Confirm/Cancel 三个接口，开发成本高；
• 补偿逻辑复杂：需确保 Cancel 能正确回滚（如避免重复解冻）。

4、Saga（偏长事务）

将分布式事务拆分为一系列 “本地事务”，每个本地事务对应一个 “补偿事务”（用于回滚）。事务按顺序执行，若某步失败，按逆序调用补偿事务回滚。

示例：下单流程拆分为 “创建订单→扣库存→扣余额”，对应补偿为 “删除订单→加库存→加余额”。若扣余额失败，则先执行 “加库存”，再 “删除订单”。
优点：

• 支持长事务（步骤多、耗时久）；
• 无锁阻塞，性能较好。

缺点：

• 仅保证最终一致性（中间可能存在短暂不一致）；
• 补偿事务需处理 “幂等性”（避免重复执行导致数据错误，如重复加库存）。

 

四、分布式事务解决方案——Seata

对比维度	AT 模式（Auto Transaction）	TCC 模式（Try-Confirm-Cancel）	Saga 模式	XAT 模式（XA Transaction）
核心原理	基于本地事务 + undo log 自动补偿：   1. 执行阶段：本地事务提交，生成 undo log（记录数据修改前状态）；   2. 提交 / 回滚：全局事务成功则删除 undo log，失败则通过 undo log 自动回滚。	基于业务自定义补偿：   1. Try：预留资源（如冻结库存）；   2. Confirm：确认执行业务（如扣减冻结库存）；   3. Cancel：取消操作（如解冻库存）。	将分布式事务拆分为多个本地事务，每个本地事务对应一个补偿事务：   1. 按顺序执行本地事务；   2. 若某步失败，按逆序执行补偿事务回滚。	基于 XA 协议（分布式事务标准）：   1. 协调者（TM）通过 XA 接口与参与者（RM，如数据库）通信；   2. 分准备（prepare）和提交（commit）两阶段，保证强一致性。
适用场景	无复杂业务逻辑、需自动补偿的场景（如电商下单、库存扣减等常规业务）。	有复杂业务逻辑、需自定义资源预留的场景（如金融交易、资金划扣等）。	长事务、多步骤跨服务场景（如跨境电商物流、订单履约流程）。	需强一致性、数据库支持 XA 协议的场景（如传统金融核心交易）。
业务侵入性	低（无需手动写补偿逻辑，仅需加 @GlobalTransactional 注解）。	高（需手动实现 Try/Confirm/Cancel 三个接口）。	中（需定义本地事务和补偿事务，可通过状态机配置简化）。	低（依赖数据库 XA 支持，应用层只需标注事务）。
性能	较高（本地事务提交后释放锁，无长时间阻塞）。	高（Try 阶段仅预留资源，无锁阻塞，适合高并发）。	较高（无锁阻塞，异步执行）。	低（两阶段阻塞，资源锁定时间长，吞吐量低）。
一致性保障	最终一致性（执行阶段可能短暂不一致，回滚时通过 undo log 修正）。	最终一致性（Confirm/Cancel 保证最终一致）。	最终一致性（补偿事务可能延迟执行，中间存在不一致）。	强一致性（严格遵循 XA 两阶段，所有操作要么全成，要么全败）。
优势	1. 对业务无侵入，开发成本低；   2. 自动生成补偿逻辑，易用性高。	1. 灵活性强，可自定义资源预留逻辑；   2. 性能好，适合高并发场景。	1. 支持长事务（步骤多、耗时久）；   2. 无锁阻塞，适合跨多服务流程。	1. 强一致性，符合 ACID；   2. 基于标准协议，兼容性好（支持多数关系型数据库）。
劣势	1. 依赖数据库事务支持（需 InnoDB 等支持行锁的引擎）；   2. 对非关系型数据库支持弱。	1. 开发成本高（需处理幂等、空回滚、悬挂等问题）；   2. 业务逻辑耦合补偿逻辑。	1. 补偿事务设计复杂（需保证幂等和顺序）；   2. 一致性较弱，无资源预留机制。	1. 性能差（阻塞导致吞吐量低）；   2. 不适合高并发场景，依赖数据库 XA 支持。
典型使用场景	电商订单创建、商品库存扣减、用户积分变更等。	金融转账、红包发放、库存预留（需复杂校验）等。	物流订单履约（下单→支付→发货→签收）、跨境支付流程等。	银行核心账务系统、支付清算系统等强一致性要求场景。

 

五、