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

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

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

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

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

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

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

先把订单和 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 推迟到下一次退避时间。

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

反例是把消息表当成“发送成功表”

有些实现会先把事件改为 SENT，再调用通知服务，想用状态字段避免重复。这个顺序反而制造了更大的丢失窗口：进程在状态更新后崩溃，通知根本没有发出去，后续扫描也不会再看到它。

另一个反例是无限重试。收件人地址失效、模板变量缺失、权限被撤销，都不是靠重试能解决的问题。建议把错误分成临时错误和永久错误：前者重试并观察延迟，后者进入 DEAD，保留原始响应和人工处理原因。

消费者也不能假设发送器只会投递一次。比如权益服务用 event_key 建唯一记录，重复收到 order:90021:paid 时直接返回已处理结果，而不是再次发放权益。

什么时候值得采用这个模式

如果一个事务只修改本地表，且没有外部副作用，事务消息表会增加维护成本，没有必要为了“架构完整”而加入。它更适合下面这些压力同时存在的场景：

• 订单、库存或账户状态一旦提交，就必须通知另一个服务。
• 消息服务偶发超时，业务方需要可追踪、可重试的事件记录。
• 团队能接受最终一致性，并愿意建设幂等消费和失败告警。

如果业务要求跨库强一致扣款，或者事件体包含不能落盘的敏感数据，应该先评估分布式事务、脱敏与加密方案。事务消息表不是所有一致性问题的通用答案。

上线前用四个问题检查实现

1. 订单状态和 outbox_event 是否确实由同一个数据源事务提交？
2. event_key 是否能唯一描述一次业务事实，重复请求会不会产生不同键？
3. 发送器崩溃、网络超时、租约过期后，事件能否重新被领取？
4. 消费者重复收到事件时，是否只产生一次业务效果？

这四个问题都能用测试验证：在提交前后注入进程中断，模拟通知超时，重复投递同一个事件，再检查订单、事件状态和权益记录。能回答清楚，模式才真正落地。

相关问题

事务消息表和 MQ 的事务消息一样吗？

不完全一样。事务消息表先把事件写入业务数据库，再由发送器投递到 MQ；它依赖数据库和消费者幂等，但实现简单、可观测。

事件发送成功后还要保留记录吗？

建议保留一段时间。发送时间、响应摘要和重试次数能帮助排查，达到保留期限后再按归档策略清理。

怎样避免发送器重复发送？

发送器可以用租约降低并发领取，但无法消除所有重复投递。真正的最后一道防线是消费者按 event_key 做幂等。

小结

事务消息表的核心只有一条：把业务事实和待发送事件放进同一个本地事务，把不可靠的网络发送移到事务之外处理。它换来的不是“绝不重复”，而是可恢复、可追踪和可验证的最终一致性。只要把唯一键、重试边界、租约和消费者幂等一起设计，订单状态与通知之间的空档就不会再靠运气。