嘿，兄弟，今天咱们聊聊那个让人抓狂的场景：订单geng新成功了可分账消息居然没发出去。你想想，那一秒钟里系统就像在打呼噜——订单走进 WAIT_SHARE，分账单却成了空白。

先说点基本背景

你知道吗？业务往往是先把状态改到 WAIT_SHARE，然后再发一条 “SHARE_CREATE” 的消息给下游。理论上这两步应该是原子操作，但实际上它们分别跑在不同的系统里：数据库和 Kafka。于是就出现了裂缝。

典型代码片段

@Transactional
public void handlePaySuccess {
    String orderNo = event.getOrderNo;
    int rows = orderMapper.updateStatus(orderNo,
            OrderStatus.PAID,
            OrderStatus.WAIT_SHARE);
    if  {
        log.info;
        return;
    }
    ShareCreateMessage message = buildShareCreateMessage;
    kafkaTemplate.send;
    log.info;
}

从表面kan挺干净的——事务里先改状态，再裸发消息。但你要记住这里的事务只管 MySQL，而 Kafka 的发送是异步、独立的。

那到底出了啥问题？

原因其实hen简单：数据库事务和 MQ 发送不是同一个原子动作。那Ru果服务在提交后立刻宕机怎么办？

举个例子：

DB 写入成功；

Kafka 的生产者把消息写进 broker，但网络抖动导致没有收到 ack；

服务因超时宕机；

下游根本没收到任何消息。

结果是：订单Yi进入 WAIT_SHARE，但分账单根本没创建。咱们也Neng从日志里kan到：

UPDATE t_outbox_message SET status='SENDING' WHERE id=...

Ru果这个标记后马上宕机，那条记录就长时间停留在 SENDING 状态。

说实话，这种情况其实挺常见的。

hen多项目Zui开始dou直接裸发 MQ，结果线上频繁出现 “状态Yi变但消息没发”的报错。要想搞定，就得把两件事拆开再连接起来。

"为什么百度不收录"

对啊，你会问这跟我们的分账问题有啥关系？别急，其实这也Neng说明一个道理——信息不完整，总会被搜索引擎忽略。比如说Ru果你写了一篇技术文档，却忘了加关键字或外链，那么百度根本不会爬到它。

类似地，Ru果我们把业务状态和 MQ 消息放在不同的持久化边界上，就相当于给自己写了一份“无键值对”的文档——搜索不到，也没人Neng找到它。

解决办法就是加上可靠的交接记录，让整个链路dou有“索引”。这就是 Outbox 模式的核心思想。

"Outbox" 模式到底是什么？

"Outbox" 就是把待发送的消息先写进本地数据库，然后后台任务负责真正去 Kafka 发。这样一来即使服务崩溃，消息也不会丢失。

核心流程图解

A. 业务方法里同时写业务数据 + 写 outbox 消息；     此时两条写操作dou包在同一个 DB 事务里。

B. 事务提交后outbox 表里出现一条 INIT 状态的新记录；     此时系统还没有去 Kafka 发过任何东西。

C. 后台扫描任务每隔几秒跑一次把 INIT 或 FAIL 状态的记录挑出来；     然后尝试发送，并根据结果geng新为 SENT 或 FAIL 并设置重试时间。

D. 消费者拿到 MESSAGE 后以幂等方式处理——即使重复收到也只生效一次。

public void dispatchOutboxMessages {
    List messages = outboxMapper.queryPending;
    for  {
        boolean locked = outboxMapper.markSending);
        if  continue;
        try {
            kafkaTemplate.send, msg.getBody).get;
            outboxMapper.markSent);
        } catch  {
            outboxMapper.markFail, e.getMessage,
                    nextRetryTime));
        }
    }
}

"SENDING 超时怎么办"

Ru果后台任务因为某种原因崩掉，而那条记录被标记为 SENDING，那它就卡在那里。这时候我们Ke以给 SENDING 加一个超时恢复机制：比如每隔一分钟检查一次Ru果超过一定时间仍未geng新，则重新置为 FAIL 并触发告警。这样既避免了永远挂起，也保证后续还Neng重试。

"为什么kan起来顺利却隐藏风险"

hen多人觉得“先改 DB，再裸发 MQ”，听着安全。但实际上，一旦中间出现网络抖动、Broker 暂时不可用或者服务宕机，你就会得到一种kan似正常但实则异常的数据一致性问题。换句话说你把“分账消息是否送达”这一关卡放到了一个非原子性的地方，让整个系统暴露给了隐形缺口。

"幂等性的重要性"

Kafka 消费端一定要实现幂等，否则即使你多次重试，也可Neng导致重复创建分账单。而 Outbox 模式虽然Neng保证不会丢失，但不Neng解决重复消费的问题。所以这一步一定不Neng省略。

"补偿对账"

a）定期扫描订单表与分账表，对比是否存在漏单； b）若发现差异，就手工触发补偿逻辑或自动补齐。当然这一步也是基于 Outbox Neng够让我们清晰kan到哪些消息Yi经发送、哪些失败、哪些卡住。

"Zui终一致性 vs 实时性"

有些人追求实时一致，即立即让所有节点同步状态。但这通常意味着牺牲可靠性：一旦任意节点宕机，就会产生不可预料的问题。而 Outbox 模式geng倾向于Zui终一致性：通过可靠存储 + 重试 + 幂等处理，让整个链路Zui终达到一致，却允许短暂的不一致现象存在。这种折衷方案在微服务架构中被广泛接受，因为它兼顾了可用性和持久化需求。

说实话，Ru果你只是想要一个“一次改 DB 就行，不需要担心异步”，那Ke以直接裸发。不过当业务量增长到每秒几十万笔交易，你hen可Neng会遇到那些隐藏在细节里的小崩盘。

一下： 1）不要把 DB 与 MQ 的写操作混成同一个事务； 2）使用 Outbox 写入待发送记录，并由独立任务负责真正发送； 3）确保消费者具备幂等Neng力； 4）添加 SENDING 超时恢复、Zui大重试次数以及告警机制； 5）定期对账，及时补偿。

Zui后一句话：别忘了当系统出现 “订单Yi变但分账没走”的情况时用“查kan日志+查询 outbox”这两个步骤往往Neng快速定位问题。Ru果还没查出来那大概率就是你的 Outbox 没Zuo好维护工作。

祝你编码愉快，顺风顺水！

---