前言

上周生产环境出了个事故，订单系统在处理一笔重要订单时，支付服务调用失败了，虽然我们有异常处理，但后续的库存回滚、积分扣除等操作没有执行，导致数据不一致。

当时只能手动修复数据，费了很大劲才把数据恢复过来。这让我意识到，仅仅捕获异常还不够，我们需要一个完整的事务补偿机制，让失败的事务可查、可重试、可跳过。

今天就分享一下我们的解决方案。

问题背景

在分布式系统中，事务失败是不可避免的，经常会遇到以下问题：

1. 事务失败后处理遗漏：异常处理后，某些操作没有执行
2. 补偿逻辑复杂：需要编写大量补偿代码
3. 缺乏监控手段：不知道哪些事务失败了需要补偿
4. 人工干预困难：出现问题只能手动修复数据
5. 补偿状态不透明：无法知道补偿是否成功

这些问题会导致：

• 数据不一致
• 业务流程中断
• 运维成本高
• 用户体验差
• 系统可靠性降低

传统方案 vs 优化方案

传统方案：手动补偿

// 订单创建流程
@Transactional
public Order createOrder(OrderRequest request) {
    try {
        // 1. 创建订单
        Order order = orderService.create(request);
        
        // 2. 扣减库存
        inventoryService.reduceStock(request.getItems());
        
        // 3. 扣减用户余额
        userService.deductBalance(request.getUserId(), request.getAmount());
        
        // 4. 扣减积分
        pointService.deductPoints(request.getUserId(), request.getPoints());
        
        order.setStatus("SUCCESS");
        return orderService.update(order);
    } catch (Exception e) {
        // 手动补偿逻辑
        try {
            // 回滚库存
            inventoryService.restoreStock(request.getItems());
        } catch (Exception ex) {
            log.error("回滚库存失败", ex);
        }
        
        try {
            // 回滚余额
            userService.restoreBalance(request.getUserId(), request.getAmount());
        } catch (Exception ex) {
            log.error("回滚余额失败", ex);
        }
        
        try {
            // 回滚积分
            pointService.restorePoints(request.getUserId(), request.getPoints());
        } catch (Exception ex) {
            log.error("回滚积分失败", ex);
        }
        
        throw e;
    }
}

问题：

• 代码冗长，补偿逻辑复杂
• 每个业务都需要写类似的补偿代码
• 补偿过程可能出现异常，需要再次补偿
• 无法监控补偿状态

优化方案：事务补偿日志 + 人工干预

// 业务流程简化
@Transactional
public Order createOrder(OrderRequest request) {
    // 正常业务流程
    Order order = orderService.create(request);
    
    try {
        // 1. 扣减库存
        inventoryService.reduceStock(request.getItems());
        
        // 2. 扣减用户余额
        userService.deductBalance(request.getUserId(), request.getAmount());
        
        // 3. 扣减积分
        pointService.deductPoints(request.getUserId(), request.getPoints());
        
        order.setStatus("SUCCESS");
        return orderService.update(order);
    } catch (Exception e) {
        // 记录补偿日志
        compensationService.createCompensationLog(
            order.getId().toString(),
            "ORDER_ROLLBACK",
            "Rollback order: " + order.getId()
        );
        
        order.setStatus("FAILED");
        orderService.update(order);
        
        // 继续处理其他逻辑...
        throw e;
    }
}

// 补偿服务自动处理
@Scheduled(fixedRate = 30000) // 每30秒执行一次
public void executePendingCompensations() {
    List<CompensationLog> readyLogs = getReadyToRetryCompensations();
    for (CompensationLog log : readyLogs) {
        executeCompensation(log.getId());
    }
}

优势：

• 业务代码简洁
• 补偿逻辑统一处理
• 自动重试机制
• 人工干预能力
• 可视化监控

核心设计思路

1. 补偿日志机制

设计要点：

• 状态管理：记录补偿任务的执行状态
• 重试控制：限制最大重试次数
• 时间调度：控制重试间隔
• 错误记录：保存失败原因

实现原理：
通过数据库表记录所有需要补偿的操作，包括业务键、操作类型、参数、执行状态等信息。系统定时扫描待处理的补偿任务，自动执行补偿操作。

状态流转：

• PENDING → PROCESSING → SUCCESS/FAILED
• FAILED → RETRY → PENDING → PROCESSING
• FAILED → MAX_RETRY → MANUAL_INTERVENTION

2. 自动补偿机制

设计要点：

• 定时执行：定期扫描待处理任务
• 异步处理：补偿操作异步执行
• 幂等性保证：确保补偿操作可重复执行
• 异常处理：妥善处理补偿过程中的异常

实现原理：
使用Spring的@Scheduled注解创建定时任务，定期扫描补偿日志表中状态为PENDING且到达下次执行时间的任务，然后异步执行补偿操作。

执行流程：

1. 扫描待执行的补偿任务
2. 更新状态为PROCESSING
3. 执行具体的补偿逻辑
4. 根据执行结果更新状态
5. 设置下次重试时间（如果需要）

3. 人工干预后台

设计要点：

• 任务查询：支持按条件查询补偿任务
• 手动操作：支持手动重试、跳过等操作
• 实时监控：显示补偿任务统计信息
• 操作记录：记录人工干预操作

实现原理：
提供REST API接口，允许运维人员查询、重试、跳过补偿任务。同时提供Web界面，以可视化的方式展示补偿任务状态和统计数据。

功能模块：

• 补偿任务列表
• 状态统计图表
• 手动干预操作
• 任务详情查看

实现细节

补偿日志实体设计

设计补偿日志实体，记录补偿任务的详细信息：

核心字段：

• 业务键（businessKey）：关联原始业务
• 操作类型（operation）：标识补偿操作
• 参数（parameters）：补偿操作所需参数
• 状态（status）：当前执行状态
• 重试次数（retryCount）：已重试次数
• 错误信息（errorMessage）：失败原因

状态管理：

• PENDING：待处理
• PROCESSING：处理中
• SUCCESS：成功
• FAILED：失败
• SKIPPED：已跳过
• CANCELLED：已取消

补偿服务实现

实现补偿服务，负责补偿任务的创建、执行和管理：

核心功能：

1. 创建补偿日志
2. 执行补偿操作
3. 处理补偿失败
4. 管理重试逻辑

重试机制：

• 最大重试次数限制
• 指数退避策略
• 错误分类处理

人工干预接口

提供REST API接口，支持运维人员干预补偿任务：

核心接口：

• GET /api/compensation/logs：查询补偿日志
• POST /api/compensation/retry/{id}：重试补偿
• POST /api/compensation/skip/{id}：跳过补偿
• GET /api/compensation/stats：获取统计信息

实战经验分享

在项目实施过程中，遇到了一些坑，这里分享给大家：

1. 补偿操作的幂等性

最开始我们的补偿操作不是幂等的，导致重试时出现数据重复操作。后来我们在补偿操作中加入了幂等性检查，确保同一补偿操作可以重复执行而不产生副作用。

建议：所有补偿操作都应该是幂等的，可以通过业务键去重或状态检查来实现。

2. 重试策略的设计

一开始我们设置了固定的重试间隔，但发现对于瞬时故障和永久故障都用同样的策略不合理。后来我们根据错误类型采用了不同的重试策略。

建议：对不同类型的错误采用不同的重试策略，比如网络错误可以快速重试，业务错误可能需要人工介入。

3. 补偿任务的监控

最初我们只记录了补偿任务的状态，但没有实时监控功能，运维人员无法及时发现和处理失败的任务。后来我们增加了实时监控页面和告警机制。

建议：建立完善的监控告警机制，及时发现和处理补偿失败的任务。

4. 补偿日志的清理

补偿日志会不断增长，如果不清理会导致数据库越来越大。我们设置了自动清理机制，定期清理已完成的补偿日志。

建议：定期清理已完成的补偿日志，避免数据库过大，但要保留足够的历史数据用于审计。

5. 补偿操作的并发控制

当有大量补偿任务需要执行时，可能会对下游系统造成压力。我们增加了并发控制，限制同时执行的补偿任务数量。

建议：控制补偿任务的执行速率，避免对下游系统造成冲击。

效果验证

方案上线后，我们做了对比测试：

从数据可以看出，这套方案在事务失败处理率、问题发现时间和人工干预效率方面都有显著提升，数据一致性也得到了明显改善。

最佳实践

1. 分级补偿策略

根据业务重要性，采用不同的补偿策略：

• 核心业务：严格补偿，多次重试
• 重要业务：标准补偿，适度重试
• 普通业务：宽松补偿，快速失败

2. 补偿操作分类

将补偿操作按类型分类处理：

• 数据回滚型：库存回滚、余额回滚
• 状态恢复型：订单状态恢复
• 通知补发型：消息补发

3. 监控告警机制

建立完善的监控告警机制：

• 补偿失败告警：补偿失败时告警
• 长时间未处理告警：补偿任务长时间未处理时告警
• 重试次数超限告警：重试次数超限时告警

4. 人工干预权限控制

对人工干预操作进行权限控制：

• 查询权限：所有运维人员
• 重试权限：高级运维人员
• 跳过权限：管理员

注意事项

1. 幂等性保证：确保补偿操作是幂等的
2. 重试策略：根据业务场景设计合理的重试策略
3. 监控告警：建立完善的监控告警机制
4. 日志清理：定期清理历史补偿日志
5. 并发控制：控制补偿任务的执行速率

写在最后

事务补偿是分布式系统中不可缺少的一环，通过补偿日志和人工干预后台，可以让失败的事务得到妥善处理，提高系统的可靠性和数据的一致性。

当然，这套方案也不是万能的，需要根据具体业务场景进行调整和优化。在实施过程中，要注意补偿操作的幂等性，合理设计重试策略，建立完善的监控告警机制。

希望这套方案能给大家带来一些启发，让事务补偿不再是系统的负担。

公众号：服务端技术精选

专注后端技术分享，定期推送高质量技术文章。关注我，一起成长！

点赞、在看、转发，是对我最大的支持！