最大努力通知型最终一致性分布式事务解决方案

敖正炀
135 阅读5分钟

一、方案概述

最大努力通知型（Best-Effort Delivery） 是一种面向跨系统或跨组织场景的分布式事务解决方案，核心思想是 发送方通过多次重试 将业务结果通知到接收方，直到成功或达到最大重试次数。其目标是尽可能保证通知的可靠性，但不严格保证强一致性，适用于允许最终一致性的场景（如支付结果回调、订单状态同步等）。

二、核心原理

1. 架构角色

• 通知发起方（Sender） ：执行业务操作并生成通知消息。 • 通知接收方（Receiver） ：接收通知并执行业务处理，需支持幂等性。 • 通知存储层：持久化通知记录，用于重试与状态跟踪。 • 调度服务：定时触发通知重试。

2. 工作流程
  1. 业务操作与通知记录 • 发送方执行本地业务操作（如支付成功），并记录通知消息到存储层（如数据库）。
  2. 首次通知 • 发送方立即尝试通知接收方，若成功则标记通知状态为“已成功”。
  3. 异步重试 • 若首次通知失败，调度服务定时（如指数退避）重试通知，直到成功或达到最大次数。
  4. 最终处理 • 若超过最大重试次数仍失败，标记为“死亡消息”，触发告警或人工介入。

image-20250401225226815

三、关键技术实现

1. 通知记录表设计
CREATE TABLE notify_record (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  biz_id VARCHAR(64) NOT NULL,          -- 业务唯一ID（如订单号）
  notify_url VARCHAR(255) NOT NULL,     -- 接收方通知地址
  content TEXT NOT NULL,                -- 通知内容（JSON格式）
  status TINYINT NOT NULL DEFAULT 0,     -- 状态（0-待通知，1-已成功，2-已失败，3-死亡）
  retry_count INT NOT NULL DEFAULT 0,    -- 重试次数
  next_retry_time DATETIME,              -- 下次重试时间
  create_time DATETIME NOT NULL,
  update_time DATETIME NOT NULL
);

• 索引优化：对 status 和 next_retry_time 建立联合索引，加速重试查询。

2. 重试策略

• 指数退避：每次重试间隔逐渐增加（如1s、5s、30s、5min）。 • 最大重试次数：通常设置为5~10次，避免无限重试。 • 死亡消息处理：超过最大重试次数后，记录日志并触发告警。

3. 接收方幂等性

• 唯一业务ID：通知中携带 biz_id，接收方检查是否已处理。 • 数据库唯一约束：通过唯一索引或版本号防重。

四、最佳实践示例：支付结果回调通知

场景描述

• 用户支付成功后，支付系统需通知商户系统更新订单状态。 • 要求：必须确保商户最终收到通知，允许短暂延迟。

实现步骤

  1. 支付系统（Sender） • 支付成功后，记录通知消息：

    INSERT INTO notify_record 
(biz_id, notify_url, content, status)
VALUES 
('ORDER_001', 'http://merchant.com/notify', '{"status":"PAID"}', 0);

    • 立即调用商户通知接口：

    boolean success = httpClient.post(notifyUrl, content);
if (success) {
    updateNotifyStatus('ORDER_001', 1); // 标记成功
} else {
    updateNotifyStatus('ORDER_001', 2); // 标记失败，触发重试
}

  2. 调度服务 • 定时扫描待重试的通知（status=2且next_retry_time <= NOW()）：

    @Scheduled(fixedRate = 60000) // 每分钟执行一次
public void retryFailedNotifications() {
    List<NotifyRecord> records = notifyDao.selectRetryList();
    for (NotifyRecord record : records) {
        boolean success = retryNotify(record);
        if (success) {
            notifyDao.updateStatus(record.getId(), 1);
        } else {
            notifyDao.incrementRetryCount(record.getId());
            if (record.getRetryCount() >= MAX_RETRY) {
                notifyDao.markAsDead(record.getId());
            }
        }
    }
}

  3. 商户系统（Receiver） • 接收通知并更新订单状态（幂等性保障）：

    @PostMapping("/notify")
public String handleNotify(@RequestBody NotifyRequest request) {
    String bizId = request.getBizId();
    if (orderService.isProcessed(bizId)) {
        return "SUCCESS"; // 幂等返回
    }
    orderService.updateStatus(bizId, "PAID");
    return "SUCCESS";
}
容错设计

• 网络超时：设置HTTP请求超时（如3秒），避免阻塞调度线程。 • 异步重试：使用线程池异步发送通知，提升吞吐量。 • 对账补偿：定时对账支付状态与商户订单状态，修复不一致。

五、方案优缺点

优点

• 简单易实现：无需复杂的事务协议（如2PC、TCC）。 • 高可用性：通过重试机制容忍临时故障。 • 适用性强：适用于跨系统、跨组织的异步通知场景。

缺点

• 最终一致性：不保证实时一致性，存在通知延迟。 • 资源消耗：高频重试可能增加网络与数据库压力。 • 依赖接收方：需接收方实现幂等性，否则可能导致数据错误。

六、适用场景

  1. 支付结果回调：如支付宝/微信支付通知商户。
  2. 状态同步：订单状态同步至物流系统。
  3. 第三方服务集成：如短信发送结果通知、API计费回调。

七、优化策略

  1. 批量通知：合并多个通知请求，减少HTTP调用次数。
  2. 优先级队列：按业务优先级设置重试间隔（如支付通知优先于日志通知）。
  3. 异步确认机制：接收方处理成功后主动ACK，减少发送方轮询压力。
  4. 熔断与降级：监控接收方可用性，故障时暂停重试，避免雪崩。

八、总结

最大努力通知型方案通过 持久化存储 + 重试机制 平衡了可靠性与实现复杂度，是跨系统异步通信场景的经典选择。关键成功要素： • 幂等消费：接收方必须支持重复消息处理。 • 智能重试：合理设计重试间隔与次数，兼顾效率与资源消耗。 • 监控告警：实时跟踪通知成功率与延迟，及时处理死亡消息。

通过合理设计，该方案可广泛应用于电商、金融、物流等领域，成为分布式系统中跨服务协作的重要纽带。

avatar
文章
阅读
粉丝