空回滚问题详解¶

一、空回滚问题出现的原因¶

基础原因
- 分支事务所在服务器宕机或网络异常，导致Try阶段方法未执行。
- 事务协调器（TM）因超时或异常触发全局回滚，调用Cancel阶段方法。
典型场景
- Try请求因网络超时未到达参与者，协调器误判为失败并触发Cancel。
- 服务实例崩溃前未完成Try操作，恢复后收到Cancel请求。

二、空回滚问题的解决方案¶

核心思路
- 通过全局事务ID和分支事务记录表标识Try阶段是否执行。
- Cancel阶段执行前检查Try记录，若无记录则判定为空回滚，直接返回成功。

具体实现步骤

全局事务ID生成
主业务发起全局事务时生成唯一ID（如UUID），贯穿整个事务流程。
分支事务记录表设计
| 字段 | 说明 | |---------------|--------------------------| | global_tx_id | 全局事务ID | | branch_tx_id | 分支事务ID | | status | Try阶段执行状态（0-未执行，1-已执行） |
Try阶段操作
执行业务逻辑前，在分支事务记录表插入记录（status=1）。

Cancel阶段校验

public void cancel(String globalTxId, String branchTxId) {
    // 1. 查询分支事务记录
    BranchTxRecord record = branchTxDao.queryByGlobalId(globalTxId, branchTxId);
    if (record == null || record.getStatus() != 1) {
        // 空回滚：未执行Try，直接返回成功
        return;
    }
    // 2. 执行实际回滚逻辑
    // ...
    // 3. 更新状态为已回滚（可选）
    record.setStatus(2);
    branchTxDao.update(record);
}

附加优化措施
- 超时机制：设置事务超时时间，避免长时间悬挂。
- 幂等性保障：Cancel操作需支持重复调用，防止重复回滚。
- 日志与监控：记录空回滚事件，便于排查异常场景。

三、与其他问题的区分¶

业务悬挂（Hanging Transaction）
- 原因：Cancel请求比Try先执行（如网络拥堵后Try延迟到达）。
- 区��：空回滚是未执行Try直接Cancel，悬挂是Cancel已执行但Try后续到达。
- 解决方案：结合超时机制与补偿逻辑（如人工干预或自动重试）。

四、典型应用场景¶

金融交易：扣款前检查账户余额，若Try未执行则Cancel不触发退款。
库存管理：避免未扣减库存时释放库存资源。
分布式支付：防止未支付订单被错误关闭。

通过上述方案，可有效识别并规避空回滚问��，保障分布式事务的最终一致性。

幂等性问题详解¶

一、幂等性问题出现的原因¶

基础原因
- 网络异常：分支事务调用超时或失败，协调器触发重试机制。
- 服务故障：服务器宕机、应用崩溃导致Try阶段未执行。
- 重试机制：为保证最终执行，TCC方案通常会加入超时重试，但可能引发重复操作。
数据风险
- 重复的Confirm/Cancel调用可能导致资源重复扣减（如重复支付、库存超卖）。
- 未记录操作状态时，无法判断操作是否已执行，破坏事务一致性。

二、幂等性问题的解决方案¶

核心设计
- 状态标记：在分支事务记录表中增加状态字段（如status），标识事务执行阶段。
- 唯一索引：通过全局事务ID+分支事务ID建立唯一索引，防止重复数据写入。
具体实现 ```sql -- 分支事务记录表示例 CREATE TABLE t_branch_transaction ( global_tx_id VARCHAR(64) NOT NULL, -- 全局事务ID branch_tx_id VARCHAR(64) NOT NULL, -- 分支事务ID status TINYINT NOT NULL DEFAULT 0, -- 状态：0-未执行，1-已执行 created_time DATETIME, PRIMARY KEY (global_tx_id, branch_tx_id) );
阶段校验逻辑 • Try阶段 public boolean tryExecute(String globalTxId, String branchTxId) { // 1. 检查状态是否已执行 if (branchTxDao.exists(globalTxId, branchTxId)) { return true; // 幂等性校验通过 } // 2. 执行业务逻辑 // 3. 插入分支事务记录（status=1） branchTxDao.insert(globalTxId, branchTxId, 1); return true; }

• Confirm/Cancel阶段 public void confirm(String globalTxId, String branchTxId) { // 1. 查询分支事务状态 BranchTxRecord record = branchTxDao.queryByGlobalId(globalTxId, branchTxId); if (record == null || record.getStatus() != 1) { return; // 未执行或已回滚，直接幂等返回 } // 2. 执行实际确认逻辑（如扣减库存） // 3. 更新状态为最终态（如status=2） branchTxDao.updateStatus(globalTxId, branchTxId, 2); }

扩展优化 • 超时补偿：结合定时任务清理超时未完成的事务记录。 • 框架支持：使用Hmily/TCC-Transaction等框架自动管理状态与重试。 • 日志追踪：记录操作日志，便于排查重复调用问题。

悬挂问题详解¶

一、悬挂问题出现的原因¶

基础原因
- 在TCC分布式事务中，分支事务的Try阶段通过RPC调用执行。
- 如果调用过程中发生服务器宕机、应用崩溃或网络异常，RPC调用会超时。
- 超时后，事务管理器通知资源管理器回滚事务。
- 资源管理器回滚事务后，RPC请求可能再次到达分支事务所在的业务方法。
- 此时，Try阶段预留的资源无法释放，形成悬挂。
悬挂现象
- 预留业务资源后，无法继续处理事务。

二、解决悬挂问题的方案¶

核心思路
- 如果执行了Confirm阶段或Cancel阶段的方法，则Try阶段的方法不能再执行。
具体方案
- 在执行Try阶段的方法时，查询分支记录表中是否存在同一��局事务下的Confirm阶段或Cancel阶段的事务记录。
- 如果存在，则不再执行Try阶段的方法。

实现细节

分支记录表设计
| 字段 | 说明 | |---------------|--------------------------| | global_tx_id | 全局事务ID | | branch_tx_id | 分支事务ID | | status | 事务状态（0-未执行，1-已执行） |

Try阶段校验逻辑

public boolean tryExecute(String globalTxId, String branchTxId) {
    // 1. 查询分支事务记录
    BranchTxRecord record = branchTxDao.queryByGlobalId(globalTxId, branchTxId);
    if (record != null && record.getStatus() >= 1) {
        return false; // Confirm或Cancel已执行，Try阶段不可再执行
    }
    // 2. 执行业务逻辑
    // 3. 插入分支事务记录（status=1）
    branchTxDao.insert(globalTxId, branchTxId, 1);
    return true;
}

附加优化措施
- 超时补偿：结合定时任务清理超时未完成的事务记录。
- 幂等性保障：确保Confirm和Cancel操作的幂等性。
- 日志与监控：记录悬挂事件，便于排查异常场景。

通过上述方案，可以有效避免悬挂问题，确保分布式事务的最终一致性。

基于本地消息表实现的最终消息一致性方案¶

优点¶

在业务应用中实现了消息的可靠性，减少了对消息中间件的依赖。

缺点¶

绑定了具体的业务场景，耦合性太高，不可公用和扩展。
消息数据与业务数据在同一个数据库，占用了业务系统的资源。
消息数据可能会受到数据库并发性的影响。

基于消息队列中间件实现的最终消息一致性方案¶

优点¶

消息数据能够独立存储，与具体的业务数据库解耦。
消息的并发性和吞吐量优于本地消息表方案。

缺点¶

发送一次消息需要完成两次网络交互，一次是消息的发送，另一次是消息的提交或回滚。
需要实现消息的回查接口，增加了开发成本。

分布式事务中的常见问题与解决方案¶

1. 事务发送方本地事务与消息发送的原子性问题¶

原子性问题产生的原因¶

可靠消息最终一致性要求事务发起方的本地事务与消息发送操作具有原子性。即本地事务成功后，消息必须发送出去；本地事务失败后，消息必须丢弃。两者要么都成功，要么都失败。

原子性问题的解决方案¶

实际方案中，可以通过消息确认服务来解决本地事务与消息发送的原子性问题。

2. 事务参与方接收消息的可靠性问题¶

可靠性问题产生的原因¶

由于服务器宕机、服务崩溃或网络异常等原因，事务参与方可能无法正常接收消息，或在处理事务过程中发生异常，导致��果无法正确回传到消息库，从而产生可靠性问题。

可靠性问题的解决方案¶

可通过消息恢复服务来保证事务参与方的可靠性。

3. 事务参与方接收消息的幂等性问题¶

幂等性问题产生的原因¶

在实际场景中，可靠消息服务可能会多次向事务参与方发送消息。如果事务参与方的方法不具备幂等性，就会造成消息重复消费的问题。

幂等性问题的解决方案¶

事务参与方的方法实现需具备幂等性。即只要参数相同，无论调用多少次接口或方法，结果都应与第一次调用一致。

最大努力通知型方案¶

优点¶

能够实现跨企业的数据一致性。
业务被动方的处理结果不会影响业务主动方的处理结果。
能够快速接入其他业务系统，达到业务数据一致性。

缺点¶

只适用于时间敏感度低的场景。
业务主动方发送的消息可能丢失，造成业务被动方收不到消息。
需要业务主动方提供查询消息的接口，业务被动方需要按照主动方的接口要求查询数据，增加了开发成本。

通知模式的缺点¶

通知模式作为一种分布式系统中常用的通信策略，虽然具有一定的应用场景，但也存在明显的局限性：

时效性问题：只适用于对时间敏感度较低的业务场景，不适合需要实时响应的关键业务。
消息可靠性：业务主动方发送的消息可能丢失，导致被动方无法接收到关键通知。
开发成本：需要业务主动方提供标准化的查询接口，增加了系统间集成的复杂度和开发工作量。

设计与实现要点¶

在采用通知模式时，需要重点解决以下两个核心问题，确保系统的可靠性和数据一致性：

1. 消息重复通知问题¶

问题根源¶

由于网络不稳定或系统繁忙等因素，业务主动方通常会采用**阶梯型通知策略**，按照预设的时间间隔多次重试发送消息。
这种机制虽然提高了消息送达的概率，但也不可避免地导致消息重复投递，若被动方处理逻辑不当，可能造成数据不一致。

解决方案¶

幂等性设计：确保业务被动方接收消息的处理逻辑具备幂等性，即多次执行同一操作产生的结果与执行一次相同。
实现方式：可通过消息ID去重、业务状态检查、分布式锁等技术手段实现幂等处理。
状态追踪：维护消息处理状态表，记录已处理的消息ID和结果。

2. 回调接口设计¶

为确保通知模式的可靠性，业务被动方应当遵循以下设计原则：

标准化响应：定义明确的接口响应格式，包含状态码、业务结果和错误信息。
超时处理：设置合理的接口超时时间，避免长时间占用系统资源。
日志完善：记录详细的请求参数和处理结果，便于问题定位和审计。
监控告警：对接口调用失败率进行监控，设置阈值告警机制。

最佳实践示例¶

@RestController
@RequestMapping("/api/notification")
public class NotificationController {

    private final NotificationService notificationService;
    private static final Logger logger = LoggerFactory.getLogger(NotificationController.class);

    @Autowired
    public NotificationController(NotificationService notificationService) {
        this.notificationService = notificationService;
    }

    @PostMapping("/receive")
    public ResponseEntity<Result> receiveNotification(@RequestBody NotificationRequest request) {
        try {
            // 1. 记录接收日志
            logger.info("Received notification: {}", request.getNotificationId());

            // 2. 幂等性检查
            if (notificationService.isProcessed(request.getNotificationId())) {
                logger.info("Notification already processed: {}", request.getNotificationId());
                return ResponseEntity.ok(Result.success("Already processed"));
            }

            // 3. 业务处理
            boolean success = notificationService.processNotification(request);

            // 4. 记录处理结果
            if (success) {
                logger.info("Successfully processed notification: {}", request.getNotificationId());
                return ResponseEntity.ok(Result.success("Processed successfully"));
            } else {
                logger.warn("Failed to process notification: {}", request.getNotificationId());
                return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
                    .body(Result.failure("Processing failed"));
            }
        } catch (Exception e) {
            logger.error("Error processing notification: " + request.getNotificationId(), e);
            return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
                .body(Result.failure("Internal error: " + e.getMessage()));
        }
    }
}

总结¶

通知模式在分布式系统中具有重要作用，但必须充分考虑消息重复、消息丢失等问题，通过幂等设计、可靠的重试机制和完善的监控体系来确保系统的稳定性和数据一致性。