使用 Outbox 模式保证业务数据与消息发送一致性时，如何避免消息重复投递、消息积压以及 CDC 延迟带来的业务影响？

Outbox 模式本质上解决的是：业务数据和待发送消息在同一个本地事务里落库，后面再通过 CDC 或定时任务把 Outbox 表里的消息投递到 MQ。它能保证“业务数据写成功，就一定有消息可发”，但不能天然保证消息只投递一次，也不能避免延迟和积压，所以这几个问题要额外设计。

1. 避免消息重复投递

Outbox 场景下一般默认按“至少一次投递”来设计，不强依赖 MQ 或 CDC 做绝对的 exactly once。

常见做法是：

每条 Outbox 消息生成全局唯一的 message id，比如雪花 ID、UUID，或者业务单号 + 事件类型。 消费端必须做幂等处理，不能假设消息只会来一次。 消费端可以维护一张消费记录表，以 message id 建唯一索引，处理前先插入，插入成功才执行业务逻辑，插入失败说明已经消费过，直接丢弃。 如果消息对应的是某个业务状态变更，也可以利用业务唯一键、状态机、版本号做幂等，例如订单只能从 PAID 变成 SHIPPED 一次。 对有顺序要求的消息，可以带上 aggregate id 和 `ver