当前位置：首页 > 文章列表 > 文章 > java教程 > Spring Boot 事务消息表怎么用：解决订单状态与通知不一致

Spring Boot 事务消息表怎么用：解决订单状态与通知不一致

来源：17golang原创 2026-07-26 10:01:51 0浏览收藏

订单表已经显示“已支付”，用户却没有收到权益通知，这类问题通常不是消息队列本身坏了，而是业务事务和发送动作之间存在一小段没人负责的空档。比较稳妥的做法是引入事务消息表：订单与待发送事件在同一个数据库事务里提交，后续再由发送器把事件投递出去。

要点速览

业务数据和 outbox_event 必须使用同一个本地事务。
发送器只领取到期事件，失败后按次数和时间回退，不阻塞订单提交。
事件要有业务唯一键，消费者必须按事件键幂等处理。
连续失败不能静默丢弃，应保留 dead 状态和人工补偿入口。

事务消息表解决的不是“发得快”，而是“不能丢”

把“更新订单”和“调用消息客户端”写在一个方法里，看起来流程顺理成章：

@Transactional
public void markPaid(Long orderId) {
    orderRepository.markPaid(orderId);
    messageClient.send("order.paid", orderId);
}

但数据库提交和远程发送不是同一个资源。数据库提交成功后，应用进程可能立刻重启；数据库回滚时，消息也可能已经发出。更隐蔽的情况是发送接口超时，调用方不知道对端究竟收没收到。

事务消息表的边界很明确：它不保证网络世界“只发一次”，它保证业务事件先可靠地留下来，再允许后续重试。重复发送交给事件键和消费者幂等处理。

Spring Boot 订单事务提交与通知发送之间的丢失窗口，以及订单表和事务消息表一起落库的变化

先把订单和 outbox_event 设计成一个提交单元

示例使用 MySQL 8.x。消息表不需要复制完整订单，只保存消费者真正需要的事件信息：

CREATE TABLE outbox_event (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  event_key VARCHAR(80) NOT NULL,
  event_type VARCHAR(40) NOT NULL,
  aggregate_id BIGINT NOT NULL,
  payload JSON NOT NULL,
  status VARCHAR(16) NOT NULL DEFAULT 'PENDING',
  retry_count INT NOT NULL DEFAULT 0,
  next_attempt_at DATETIME NOT NULL,
  created_at DATETIME NOT NULL,
  UNIQUE KEY uk_outbox_event_key (event_key),
  KEY idx_outbox_ready (status, next_attempt_at, id)
);

event_key 是这张表最重要的约束。例如订单 90021 的支付事件可以写成 order:90021:paid。业务代码重复提交时，唯一键会把同一个事实挡在门外，避免一次订单变成两条通知。

服务层只做两件事：更新订单状态、插入事件。两次写入都放在同一个 Spring 事务中：

@Transactional
public void markPaid(Long orderId) {
    int changed = orderRepository.markPaidIfUnpaid(orderId);
    if (changed == 0) {
        return;
    }

    OutboxEvent event = OutboxEvent.pending(
        "order:" + orderId + ":paid",
        "ORDER_PAID",
        orderId,
        nextAttemptAt.now()
    );
    outboxRepository.insert(event);
}

这里的检查点是事务边界，而不是方法返回值：订单更新失败，事件不能出现；事件插入失败，订单状态也必须回滚。只有两者都提交，发送器才有资格看到这条事件。

发送器要处理“领到但没发完”的中间状态

发送器每次领取少量 PENDING 或到期的 RETRY 事件，并把它们短暂标记为 PROCESSING。发送动作不要放在数据库锁里，否则网络抖动会拖住其他订单。

SELECT id, event_key, event_type, aggregate_id, payload
FROM outbox_event
WHERE status IN ('PENDING', 'RETRY')
  AND next_attempt_at

实际项目可以用租约字段，例如 locked_until 和 worker_id，让另一个发送器在租约过期后接管。发送成功后更新为 SENT；超时或明确的临时错误则增加 retry_count，把 next_attempt_at 推迟到下一次退避时间。

outbox_event 从待发送、处理中到成功或重试的 Spring Boot 事件生命周期与幂等消费路径

一条简化的状态判断可以写成：

结果	事件状态	下一步
收到确认	SENT	记录发送时间，保留审计数据
网络超时	RETRY	指数退避，限制最大次数
参数不可用	DEAD	告警并进入人工补偿
租约过期	RETRY	允许其他发送器重新领取