补偿性事务（Compensating Transaction）是一种基于“事后修正”逻辑的分布式事务方案，核心目标是在不依赖数据库强一致性协议（如XA）的前提下，通过执行“反向操作”来修正已完成的局部事务，最终保障分布式场景下的数据最终一致性。
核心逻辑：用“反向操作”抵消错误
补偿性事务的本质是“没有直接回滚能力时，用一个新的事务来修正结果”。其核心思路可拆解为两步：
1.先执行正向事务：各参与节点（如微服务）依次执行本地业务操作（如扣减库存、创建订单），且这些操作会直接提交（而非像XA模式那样“预提交”）。
2.异常时执行补偿事务：若任一节点执行失败，触发“补偿逻辑”——对所有已成功执行的正向事务，执行对应的反向操作（如恢复库存、删除订单），抵消之前的影响，让数据回归到事务开始前的状态。
关键特点
-
不依赖数据库协议：完全由业务代码控制，无需数据库支持XA等分布式协议，适配非关系型数据库（如Redis、MongoDB）或第三方接口（如支付、物流API）场景。
-
最终一致性：事务执行过程中可能存在短暂的数据不一致（如A服务已扣库存，B服务创建订单失败），但通过补偿操作，最终会恢复一致。
-
业务侵入性强：需为每个正向业务操作，手动设计对应的补偿操作（例：正向“扣减库存”→补偿“增加库存”；正向“创建订单”→补偿“取消订单”），开发成本较高。
典型应用场景
补偿性事务是TCC模式、Saga模式的核心思想，常见于高并发、业务逻辑复杂的分布式场景，例如：
电商下单：正向流程（扣库存→创订单→扣余额），补偿流程（加库存→删订单→加余额）。
跨系统支付：正向流程（发起支付→扣用户钱→通知商户），补偿流程（退款→加用户钱→通知商户取消）。
与“回滚”的区别
需注意补偿性事务≠数据库事务的“回滚”：
-
数据库回滚：依赖数据库事务日志，仅能撤销未提交的本地操作，无法跨节点、跨系统生效。
-
补偿事务：是业务层的主动修正，通过执行新的业务逻辑（而非数据库层面的撤销），抵消已提交的跨节点操作，适用于分布式场景。
