分布式长事务通常跨多个服务节点执行，当某个环节出现异常时，补偿机制需要精准判断异常类型来决定是否触发回滚或补偿操作。如果异常区分逻辑存在缺陷，就可能出现本不需要补偿的业务被错误触发补偿，或者需要补偿的场景没有正常执行的问题。
分布式长事务补偿机制基础逻辑
分布式长事务一般采用Saga模式或者TCC模式实现，补偿机制的核心是在事务执行失败时，按照反向顺序执行各个分支事务的补偿操作，恢复到事务执行前的状态。补偿触发的前提是明确当前出现的异常是否属于需要回滚的业务异常，而不是可重试的临时异常。
常见的异常分类通常包含三类：
- 可重试异常：比如网络超时、服务临时不可用，这类异常重试后大概率可以成功，不需要触发补偿
- 业务异常：比如库存不足、余额不够，这类异常是业务规则不允许，需要触发补偿回滚
- 系统异常：比如数据库宕机、中间件故障，这类异常需要根据场景判断是否需要补偿
异常区分错误的常见原因
1. 异常类型捕获范围过宽
很多开发者在编写事务逻辑时，直接捕获Exception基类，没有对具体的异常类型做细分，导致可重试异常也被当成业务异常处理，触发不必要的补偿。
2. 自定义异常定义不清晰
不同服务定义的业务异常没有统一规范，比如A服务用BusinessException表示库存不足，B服务用BizError表示同样的问题，补偿逻辑无法统一识别，容易出现判断遗漏。
3. 异常上下文信息丢失
分布式场景下异常经过多次远程调用传递后，原始异常的类型和信息被包装成通用的远程调用异常，补偿逻辑拿到的异常已经失去了原始类型特征，无法准确区分。
完整排查步骤
第一步：收集事务全链路日志
首先需要拿到长事务的完整执行日志，包括每个分支事务的调用参数、返回结果、抛出的异常信息。如果是基于Seata等框架实现的分布式事务，可以直接查看框架输出的事务日志，找到异常抛出的具体节点和异常堆栈。
第二步：核对异常类型与补偿触发规则
查看补偿逻辑的异常判断代码，确认当前配置的触发补偿的异常范围是否包含了不需要补偿的异常类型。比如很多场景下的超时异常是不需要触发补偿的，但是被错误地加入了补偿触发列表。
第三步：验证异常传递链路
检查异常从分支服务抛出到补偿逻辑接收的完整链路，看是否存在异常被包装、类型被篡改的情况。可以在每个远程调用的入口和出口打印异常的类型和详细信息，确认异常在传递过程中没有被修改。
第四步：模拟场景复现问题
根据排查到的异常类型，在测试环境模拟对应的异常场景，观察补偿机制是否被正确触发。如果复现了错误触发的问题，就可以定位到具体的逻辑缺陷。
优化方案与代码示例
统一异常定义规范
首先定义统一的异常基类，所有业务异常都继承该基类，可重试异常单独定义，方便补偿逻辑统一判断。
// 统一业务异常基类，所有需要触发补偿的业务异常都继承该类
public class BaseBusinessException extends RuntimeException {
private String errorCode;
private String errorMsg;
public BaseBusinessException(String errorCode, String errorMsg) {
super(errorMsg);
this.errorCode = errorCode;
this.errorMsg = errorMsg;
}
// 省略getter方法
}
// 库存不足业务异常
public class StockNotEnoughException extends BaseBusinessException {
public StockNotEnoughException(String errorMsg) {
super("STOCK_001", errorMsg);
}
}
// 可重试异常基类
public class RetryableException extends RuntimeException {
public RetryableException(String message) {
super(message);
}
}
// 网络超时异常
public class NetworkTimeoutException extends RetryableException {
public NetworkTimeoutException(String message) {
super(message);
}
}
优化补偿逻辑的异常判断
在补偿逻辑中精准判断异常类型，只触发业务异常的补偿，跳过可重试异常。
public class DistributedTransactionCompensator {
public void compensate(Throwable exception) {
// 如果是可重试异常，不触发补偿，直接返回
if (exception instanceof RetryableException) {
log.info("捕获到可重试异常，不触发补偿，异常信息：{}", exception.getMessage());
return;
}
// 如果是业务异常，触发补偿逻辑
if (exception instanceof BaseBusinessException) {
log.info("捕获到业务异常，开始执行补偿操作，异常信息：{}", exception.getMessage());
executeCompensateActions();
return;
}
// 其他系统异常根据业务场景判断，这里默认不触发补偿
log.warn("捕获到未知系统异常，暂不触发补偿，异常信息：{}", exception.getMessage());
}
private void executeCompensateActions() {
// 执行具体的分支事务补偿逻辑
// 比如调用库存服务的释放库存接口、账户服务的回滚扣款接口等
}
}
避免异常传递过程中的信息丢失
在远程调用时，将原始异常的类型和信息封装到返回结果中，不要直接抛出通用的远程调用异常。
// 远程调用返回结果封装
public class RemoteResult<T> {
private boolean success;
private T data;
private String exceptionType; // 原始异常类型
private String exceptionMsg; // 原始异常信息
// 成功返回
public static <T> RemoteResult<T> success(T data) {
RemoteResult<T> result = new RemoteResult<>();
result.setSuccess(true);
result.setData(data);
return result;
}
// 失败返回，携带原始异常信息
public static <T> RemoteResult<T> fail(Throwable e) {
RemoteResult<T> result = new RemoteResult<>();
result.setSuccess(false);
result.setExceptionType(e.getClass().getName());
result.setExceptionMsg(e.getMessage());
return result;
}
// 省略getter和setter方法
}
在调用方拿到返回结果后，可以根据exceptionType还原原始异常类型，再交给补偿逻辑判断，避免异常类型丢失导致判断错误。
注意：如果是基于现有分布式事务框架改造，需要确认框架是否支持自定义异常判断逻辑，部分框架可能需要在配置文件或者注解中指定触发补偿的异常类型，要按照框架的规范调整配置。