Kafka on FelixHao's Blog

Follow 接口压测 QPS 卡在 90 的瓶颈排查复盘

Wed, 29 Jul 2026 23:58:40 +0800

Follow 接口压测 QPS 卡在 90 的瓶颈排查复盘

1. 背景

在对微博系统的 follow 接口进行压力测试时，发现一个比较反直觉的现象：

follow 接口 QPS 到 90 左右后基本上不再上升；
应用服务器 CPU 使用率只有 20% 左右；
MySQL 所在机器 CPU 使用率也只有 50% 左右；
继续增加并发后，QPS 提升不明显，接口延迟开始上升。

从资源使用率看，应用和数据库似乎都没有“打满”，但系统吞吐却已经进入瓶颈区间。

本文记录这次 follow 压测瓶颈的完整排查过程，包括最初的假设、排除过程、关键证据，以及最终确定瓶颈在 notifications 表同步写入上的原因。

2. 压测场景

本次关注的是 follow 接口：

PUT /api/v1/users/{userId}/follow
Authorization: Bearer <accessToken>

对应的核心业务流程大致如下：

用户发起关注请求
  ├─ 校验不能关注自己
  ├─ 按稳定顺序锁定当前用户和目标用户
  ├─ 校验目标用户状态
  ├─ 插入 follows 关注关系
  ├─ 更新当前用户 following_count
  ├─ 更新目标用户 fan_count
  ├─ 写用户资料变更 outbox
  ├─ 创建关注通知
  ├─ 写 timeline follow backfill outbox
  ├─ 判断是否大 V并更新缓存
  └─ 返回 follow 响应

代码中 follow 主流程位于：

src/main/java/com/autmaple/weibo/follow/service/FollowService.java

其中核心同步事务是：

@Transactional
public FollowResponse follow(Long currentUserId, Long targetUserId) {
    ...
}

3. 初始现象

压测时观察到：

QPS ≈ 90
应用 CPU ≈ 20%
MySQL CPU ≈ 50%

直觉上，如果 CPU 没有打满，系统似乎还应该能继续提升吞吐。但实际 QPS 却几乎不再上涨。

这说明瓶颈很可能不是 CPU 型瓶颈，而是等待型瓶颈，例如：

数据库连接池等待；
MySQL 行锁等待；
commit / fsync 等待；
磁盘 I/O 等待；
Kafka / Redis / 下游组件等待；
压测脚本自身限速。

4. 第一阶段：排查压测脚本是否限制了 QPS

最开始怀疑是 k6 脚本的 think time 限制了请求产生速率。

在部分 k6 脚本中，存在类似配置：

const THINK_TIME_SECONDS = parseNonNegativeNumber(__ENV.THINK_TIME_SECONDS, 1);

如果每个 VU 每次请求后都 sleep 1 秒，那么 QPS 上限近似为：

QPS ≈ VU / (请求耗时 + think time)

例如 100 VU、think time 1 秒、请求耗时 100ms 时：

QPS ≈ 100 / 1.1 ≈ 90.9

这与 QPS 卡在 90 左右非常接近。

但本次实际使用的是 recent-poster-follow-benchmark.k6.js，它的 think time 默认已经是 0：

const THINK_TIME_SECONDS = parseNonNegativeNumber(
  __ENV.WEIBO_RECENT_POSTER_THINK_TIME_SECONDS,
  0
);

即使显式加上：

WEIBO_RECENT_POSTER_THINK_TIME_SECONDS=0

QPS 仍然没有变化。

因此可以排除：

压测脚本 think time 限制 QPS

5. 第二阶段：怀疑数据库锁等待

由于 follow 接口会对当前用户和目标用户加锁：

lockUsersInStableOrder(currentUserId, targetUserId);

底层 SQL 是：

@Select("SELECT * FROM users WHERE id = #{userId} FOR UPDATE")
User selectByIdForUpdate(@Param("userId") Long userId);

follow 成功后还会更新两个计数字段：

userRepository.incrementFollowingCount(currentUserId);
userRepository.incrementFanCount(target.getId());

因此，第二个怀疑方向是：

users 表行锁竞争 / fan_count 热点更新

尤其是在大量用户关注少量目标用户时，目标用户的 fan_count 更新可能形成热点行锁。

如果是这个问题，常见现象是：

CPU 不高；
QPS 不上升；
接口延迟升高；
MySQL 中出现 row lock wait；
Hikari 连接池 active 接近上限，pending 增加。

不过这还只是推测，需要进一步看 MySQL 当前到底在执行什么 SQL。

6. 第三阶段：查看 SHOW PROCESSLIST

压测过程中执行：

SHOW PROCESSLIST;

得到的关键现象是，大量连接都处于：

Query, update, INSERT INTO notifications ...

部分连接处于：

waiting for handler commit, commit

简化后的典型输出如下：

Id     User  DB     Command  Time  State                       Info
15424  root  weibo  Query    6     update                      INSERT INTO notifications ...
15426  root  weibo  Query    6     update                      INSERT INTO notifications ...
15439  root  weibo  Query    6     update                      INSERT INTO notifications ...
15501  root  weibo  Query    0     waiting for handler commit  commit
15517  root  weibo  Query    0     waiting for handler commit  commit
15601  root  weibo  Query    11    update                      INSERT INTO notifications ...

这个结果非常关键。

如果瓶颈是 users 行锁，通常会看到大量连接卡在：

SELECT ... FOR UPDATE
UPDATE users ...
Waiting for row lock

但实际大量连接集中在：

INSERT INTO notifications
commit

因此瓶颈方向开始从 users 行锁，转向：

notifications 表写入 / commit 等待

7. follow 为什么会同步写 notifications？

在 FollowService.follow() 中，新增关注成功后会同步创建关注通知：

notificationService.createFollowNotification(currentUserId, targetUserId);

而 NotificationService.createFollowNotification() 是强制参与外层事务的：

@Transactional(propagation = Propagation.MANDATORY)
public void createFollowNotification(Long actorId, Long recipientId) {
    createNotification(CreateNotificationCommand.builder()
            .actorId(actorId)
            .recipientId(recipientId)
            .type(NotificationTypeEnum.FOLLOW)
            .targetType(NotificationTargetTypeEnum.USER)
            .targetId(actorId)
            .build());
}

也就是说，follow 请求必须等待关注通知写入 notifications 表完成后，整个事务才能提交，HTTP 请求才能返回。

当前链路实际上是：

follow HTTP 请求
  ├─ insert follows
  ├─ update users counters
  ├─ insert user profile outbox
  ├─ INSERT notifications        ← 同步阻塞点
  ├─ insert timeline outbox
  └─ commit

更重要的是，用户行锁是在事务前半段就拿到的。如果 notifications 插入很慢，会延长整个 follow 事务的持锁时间，从而进一步放大并发等待。

8. 第四阶段：查看 performance_schema 表 I/O 等待

为了进一步确认 notifications 表是否真的慢，执行：

SELECT
    object_schema,
    object_name,
    index_name,
    count_star,
    sum_timer_wait
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = 'weibo'
  AND object_name = 'notifications'
ORDER BY sum_timer_wait DESC;

执行结果：

weibo,notifications,,219851,112137458454293840
weibo,notifications,uk_notifications_dedup,439704,149128403458860
weibo,notifications,idx_notifications_recipient_read_created,222821,8033491369320
weibo,notifications,PRIMARY,0,0
weibo,notifications,idx_notifications_recipient_created,0,0
weibo,notifications,idx_notifications_actor_created,0,0
weibo,notifications,idx_notifications_post,0,0
weibo,notifications,idx_notifications_comment,0,0

performance_schema 中 sum_timer_wait 通常单位是皮秒：

1 秒 = 1,000,000,000,000 ps

其中最关键的一行是：

index_name = NULL
count_star = 219851
sum_timer_wait = 112137458454293840

换算后：

总等待时间 ≈ 112137 秒
平均每次 ≈ 112137 / 219851 ≈ 0.51 秒

也就是说：

notifications 表基础行 I/O 平均等待约 510ms / 次

对比唯一索引：

uk_notifications_dedup:
149128403458860 ps / 439704 ≈ 0.34ms / 次

这说明：

不是 uk_notifications_dedup 这个索引查询本身慢，
而是 notifications 表基础写入 / commit 等待非常重。

9. 为什么 CPU 不高但 QPS 上不去？

这次问题的关键点在于：

瓶颈不是 CPU 计算，而是数据库写入/提交等待。

MySQL CPU 只有 50%，并不代表数据库没有瓶颈。

常见的等待型瓶颈包括：

redo log flush；
binlog flush；
group commit 等待；
磁盘 fsync 延迟；
InnoDB handler commit；
表数据页写入；
脏页刷盘；
高并发小事务提交排队。

这些等待不会表现为 CPU 打满，而会表现为：

应用线程等待数据库响应
MySQL 线程等待存储引擎提交
数据库连接长期被占用
HTTP 请求延迟升高
QPS 到达平台期

这也解释了为什么：

应用 CPU 20%
MySQL CPU 50%
QPS 却只有 90 左右

10. notifications 表为什么写入成本高？

notifications 表结构中有多个索引：

PRIMARY KEY (id),
KEY idx_notifications_recipient_read_created (recipient_id, read_flag, created_at, id),
KEY idx_notifications_recipient_created (recipient_id, created_at, id),
KEY idx_notifications_actor_created (actor_id, created_at),
KEY idx_notifications_post (post_id),
KEY idx_notifications_comment (comment_id)

后续还新增了唯一去重索引：

UNIQUE KEY uk_notifications_dedup (
  recipient_id,
  actor_id,
  type,
  target_type,
  target_id
)

每插入一条通知，MySQL 都需要维护：

1 个主键索引
多个二级索引
1 个唯一去重索引
事务日志
binlog
commit

在高并发 follow 压测中，每个有效 follow 都要同步写一条 notification，这会把 follow 接口吞吐绑定到 notifications 表写入能力上。

11. 最终结论

结合以下证据：

WEIBO_RECENT_POSTER_THINK_TIME_SECONDS=0 后 QPS 无变化，排除脚本 sleep 限速；
SHOW PROCESSLIST 中大量连接卡在 INSERT INTO notifications；
出现 waiting for handler commit；
performance_schema 显示 notifications 表基础行 I/O 平均等待约 510ms；
应用和 MySQL CPU 都未打满，符合等待型瓶颈特征；

可以确定：

follow QPS 卡在 90 左右的主要瓶颈，是 FollowService 在同步事务内创建关注通知，
导致大量请求阻塞在 notifications 表插入和 commit 阶段。

更准确地说：

同步关注通知写入将 follow HTTP 主链路与 notifications 表最终写入吞吐强耦合，
notifications 表写入/提交等待拖长 follow 事务，
进一步占用数据库连接和用户行锁，
最终导致 QPS 无法继续提升。

12. 解决方案

12.1 不推荐只做索引优化

虽然 notifications 表索引较多，写入成本确实存在，但这次 performance_schema 数据显示：

主要等待在基础行写入 / commit，
不是某个单独索引查询。

因此，删除一两个索引可能有帮助，但不是根本解决方案。

根本问题是：

follow 请求必须同步等待 notifications 写入完成。

只要这个同步关系存在，follow QPS 就仍然会受通知表写入吞吐限制。

12.2 推荐方案：关注通知异步化

关注通知是 follow 成功后的派生副作用，不应该阻塞关注主流程。

推荐将当前链路：

follow HTTP 请求
  ├─ insert follows
  ├─ update users counters
  ├─ INSERT notifications
  └─ commit

改为：

follow HTTP 请求
  ├─ insert follows
  ├─ update users counters
  ├─ insert notification outbox
  └─ commit

Debezium / Kafka
  └─ notification consumer
       └─ INSERT notifications

也就是：

FollowService 不再直接写 notifications，
而是在 follow 事务内写 notification outbox event，
由 Kafka consumer 异步创建最终通知。

这样，通知系统慢时，影响的是：

通知延迟
Kafka lag
consumer backlog

而不是：

follow HTTP QPS
follow HTTP latency
用户关注主链路

13. 为什么这个方案适合当前项目？

项目中已经有 outbox CDC 基础设施：

domain_event_outbox
Debezium Outbox Router
Kafka topic
notification event listener
DLT / replay 机制
notification interaction event 处理链路

互动通知已经类似地通过 outbox 异步处理：

PostInteractionService
  └─ NotificationInteractionOutboxService
       └─ domain_event_outbox
            └─ Kafka
                 └─ NotificationInteractionEventListener
                      └─ NotificationService
                           └─ notifications

因此 follow 通知可以复用已有链路，新增类似：

USER_FOLLOWED event

让 consumer 将其映射为原来的 FOLLOW 通知语义：

actorId = 关注者
recipientId = 被关注者
type = FOLLOW
targetType = USER
targetId = 关注者

14. 异步化后的正确性要求

14.1 通知最终一致

follow 成功后，通知不一定立即出现在通知列表中。

这属于预期行为：

关注关系是强一致主数据
通知是最终一致派生数据

14.2 重复消费必须幂等

Kafka / CDC 是至少一次投递，consumer 可能重复消费。

因此异步创建通知必须保证：

同一个 follower 对同一个 followee 的 FOLLOW 通知最多只有一条

当前 notifications 表已有唯一去重索引：

UNIQUE KEY uk_notifications_dedup (
  recipient_id,
  actor_id,
  type,
  target_type,
  target_id
)

可以继续依赖这个唯一键和 duplicate key handling 来保证幂等。

14.3 notification consumer 失败不能影响 follow 关系

异步化后，如果 notification consumer 失败：

follow 关系已经提交
通知事件进入 retry / DLT / replay

不应该回滚已经成功的关注关系。

15. 后续验证指标

改造完成后，需要重新压测并对比以下指标。

follow HTTP 侧

QPS 是否明显提升；
P95 / P99 是否下降；
Hikari active / pending 是否下降；
SHOW PROCESSLIST 中是否不再大量出现 INSERT INTO notifications；
follow 日志中的 elapsedMs 是否降低。

notification 异步侧

notification topic lag；
notification consumer QPS；
consumer 处理耗时；
DLT 数量；
最终 notifications 写入是否能在压测结束后回落；
通知列表中 FOLLOW 通知是否最终可见。

MySQL 侧

notifications 表写入是否仍慢；
慢是否只影响异步 consumer；
waiting for handler commit 是否减少；
Hikari pending 是否消失；
redo/binlog/disk I/O 是否仍是潜在瓶颈。

16. 总结

这次问题的关键教训是：

CPU 没打满，不代表系统没有瓶颈。

对于高并发写接口，QPS 上不去往往是等待型瓶颈：

行锁等待；
连接池等待；
redo/binlog flush；
commit 等待；
磁盘 I/O；
同步副作用写入。

本次 follow 压测中，最终确认的瓶颈是：

同步 FOLLOW 通知写入 notifications 表。

解决方向不是简单增加机器 CPU，也不是只优化索引，而是调整链路设计：

主链路只处理关注关系和必要 outbox，
通知作为派生副作用异步创建。

最终目标是让系统退化方式从：

通知表写入慢 → follow 接口慢 → QPS 上不去

变成：

通知表写入慢 → notification lag 增长 → follow 接口仍可正常完成

这也是事件驱动和 outbox CDC 在高并发业务系统中的核心价值：把非强一致派生工作从用户请求主链路中解耦出来。

Outbox Pattern、CDC 与幂等消费：构建可靠事件驱动系统

Thu, 16 Jul 2026 14:05:25 +0800

在微服务和事件驱动架构中，一个非常常见的业务场景是：

修改数据库中的业务数据。
向 Kafka、RocketMQ 等消息中间件发送一条消息。
下游服务消费消息，并执行后续业务逻辑。

例如，用户提交订单后，订单服务需要：

在数据库中创建订单；
发送“订单已创建”事件；
库存服务收到事件后扣减库存；
积分服务收到事件后增加积分；
通知服务收到事件后发送通知。

看起来只是一次数据库操作加一次消息发送，但这里隐藏着一个非常关键的问题：

如何保证数据库事务和消息发送的一致性？

如果数据库写入成功，但消息发送失败，下游服务就永远无法感知这次业务变化。

如果消息发送成功，但数据库事务回滚，下游服务却可能处理一条实际上并不存在的业务数据。

为了解决这些问题，工程中经常组合使用以下三种机制：

Outbox Pattern：保证业务数据和事件记录的一致性
CDC：可靠地捕获数据库中的事件变化
幂等消费：解决消息重复投递和重复处理问题

这三者并不是互相替代的关系，而是分别解决可靠消息链路中的不同问题。

一、问题背景：数据库事务和消息发送为什么难以保持一致

假设订单服务需要创建订单并发送消息：

@Transactional
public void createOrder(CreateOrderCommand command) {
    Order order = new Order();
    order.setOrderNo(command.getOrderNo());
    order.setStatus("CREATED");

    orderRepository.save(order);

    kafkaTemplate.send(
            "order-created-topic",
            order.getOrderNo(),
            new OrderCreatedEvent(order.getId(), order.getOrderNo())
    );
}

这段代码看起来被 @Transactional 包裹，但需要注意：

Spring 数据库事务只能控制数据库操作，通常无法直接控制 Kafka 或 RocketMQ 的消息发送。

数据库事务和消息中间件属于两个独立系统，它们具有各自的事务边界。

因此可能出现以下异常情况。

1. 数据库提交成功，消息发送失败

执行顺序如下：

1. INSERT INTO orders 成功
2. 数据库事务提交成功
3. 发送 Kafka 消息失败

最终结果：

数据库：存在订单
Kafka：没有订单事件

下游库存、积分、通知等服务无法感知订单已经创建。

2. 消息发送成功，数据库事务回滚

执行顺序如下：

1. INSERT INTO orders 暂时成功
2. Kafka 消息发送成功
3. 数据库事务因为异常回滚

最终结果：

数据库：不存在订单
Kafka：存在订单事件

下游服务会基于一条无效消息执行后续逻辑。

3. 应用在临界点崩溃

即使采用“先提交数据库，再发送消息”的方式，也会存在临界点问题：

1. 数据库提交成功
2. 应用进程崩溃
3. 消息发送逻辑没有执行

这种问题并不能通过简单的重试完全解决，因为应用重启后，可能已经不知道哪些业务数据尚未发送消息。

二、为什么 Kafka ACK 不能解决数据库和消息的一致性问题

Kafka ACK 解决的是：

Kafka Producer 发送消息时，消息是否已经被 Kafka Broker 接收并持久化。

例如：

acks=all

表示 Producer 需要等待所有同步副本确认后，才认为发送成功。

ACK 可以提高 Kafka 内部的消息可靠性，但它无法解决数据库事务和 Kafka 事务之间的一致性。

原因是：

数据库事务 ≠ Kafka ACK

即使 Kafka 返回 ACK，也只能说明：

Kafka 已经成功保存消息

它无法说明：

数据库事务一定已经成功提交

同样，数据库事务提交成功，也无法保证 Kafka 一定收到消息。

因此：

Kafka ACK 解决的是消息在 Kafka 内部是否可靠写入的问题，而 Outbox Pattern 解决的是业务数据和事件记录是否原子提交的问题。

三、Outbox Pattern 是什么

Outbox Pattern，通常翻译为：

事务发件箱模式

其核心思想是：

不在业务事务中直接向消息中间件发送消息，而是把需要发送的事件先写入数据库中的 Outbox 表。

业务数据和 Outbox 事件记录放在同一个本地数据库事务中提交。

例如，创建订单时同时执行：

INSERT INTO orders (...);

INSERT INTO outbox_event (...);

由于这两条 SQL 位于同一个数据库事务中，因此它们具备原子性：

要么全部成功
要么全部失败

这样就能保证：

只要业务数据成功提交，就一定存在一条对应的待发送事件。

四、Outbox Pattern 的整体流程

完整流程如下：

客户端
  |
  v
订单服务
  |
  | 本地事务
  |-------------------------------|
  | 1. 写入 orders                |
  | 2. 写入 outbox_event          |
  |-------------------------------|
  |
  v
数据库
  |
  | CDC 或轮询程序读取 Outbox
  v
Kafka / RocketMQ
  |
  v
下游消费者
  |
  | 幂等处理
  v
库存服务 / 积分服务 / 通知服务

可以将这条可靠消息链路拆成三个阶段：

业务数据 -> Outbox 表 -> 消息中间件 -> 消费者

其中：

阶段	主要机制	解决的问题
业务数据写入 Outbox	本地数据库事务	业务数据与事件记录的一致性
Outbox 发送到 MQ	CDC 或轮询	事件可靠发布
消费者处理消息	幂等消费	重复投递、重复处理

五、Outbox 表设计

一个典型的 Outbox 表可以设计为：

CREATE TABLE outbox_event (
    id BIGINT PRIMARY KEY,
    event_id VARCHAR(64) NOT NULL,
    aggregate_type VARCHAR(64) NOT NULL,
    aggregate_id VARCHAR(64) NOT NULL,
    event_type VARCHAR(128) NOT NULL,
    topic VARCHAR(128) NOT NULL,
    event_key VARCHAR(128),
    payload JSON NOT NULL,
    status VARCHAR(32) NOT NULL DEFAULT 'PENDING',
    retry_count INT NOT NULL DEFAULT 0,
    next_retry_at DATETIME NULL,
    created_at DATETIME NOT NULL,
    published_at DATETIME NULL,
    updated_at DATETIME NOT NULL,

    UNIQUE KEY uk_event_id (event_id),
    KEY idx_status_retry (
        status,
        next_retry_at,
        created_at
    ),
    KEY idx_aggregate (
        aggregate_type,
        aggregate_id
    )
);

各字段含义如下：

字段	含义
`id`	数据库主键
`event_id`	全局唯一事件 ID
`aggregate_type`	聚合类型，例如 `ORDER`
`aggregate_id`	聚合根 ID，例如订单 ID
`event_type`	事件类型，例如 `OrderCreated`
`topic`	目标消息 Topic
`event_key`	Kafka 消息 Key
`payload`	事件消息体
`status`	事件发送状态
`retry_count`	已重试次数
`next_retry_at`	下一次重试时间
`created_at`	事件创建时间
`published_at`	事件发布时间
`updated_at`	更新时间

1. event_id

event_id 是事件的全局唯一标识，通常使用：

UUID；
雪花算法 ID；
数据库分布式 ID；
ULID。

例如：

01JY1N5H2J3Q8A5W9M7K2D4P6R

消费者可以通过 event_id 判断事件是否已经处理过。

2. aggregate_type 和 aggregate_id

这两个字段用于标识事件属于哪个业务聚合。

例如：

aggregate_type = ORDER
aggregate_id   = 100001

表示这条事件属于订单 100001。

它们可用于：

排查同一个业务对象产生的所有事件；
维护同一聚合内的消息顺序；
构造 Kafka 消息 Key；
做事件追踪和审计。

3. event_type

event_type 表示事件的业务类型，例如：

OrderCreated
OrderPaid
OrderCancelled
OrderCompleted

建议使用明确的过去式命名，因为领域事件通常表示：

某件事情已经发生。

4. payload

payload 保存完整的事件内容，例如：

{
  "eventId": "01JY1N5H2J3Q8A5W9M7K2D4P6R",
  "eventType": "OrderCreated",
  "eventVersion": 1,
  "occurredAt": "2026-07-16T10:30:00Z",
  "data": {
    "orderId": 100001,
    "orderNo": "ORD202607160001",
    "userId": 20001,
    "amount": 199.00
  }
}

建议事件中至少包含：

eventId
eventType
eventVersion
occurredAt
data

必要时还可以增加：

traceId
tenantId
source
correlationId
causationId

六、Spring Boot 中实现 Outbox Pattern

1. 订单实体

public class Order {

    private Long id;

    private String orderNo;

    private Long userId;

    private BigDecimal amount;

    private String status;

    private LocalDateTime createdAt;
}

2. Outbox 事件实体

public class OutboxEvent {

    private Long id;

    private String eventId;

    private String aggregateType;

    private String aggregateId;

    private String eventType;

    private String topic;

    private String eventKey;

    private String payload;

    private String status;

    private Integer retryCount;

    private LocalDateTime nextRetryAt;

    private LocalDateTime createdAt;

    private LocalDateTime publishedAt;

    private LocalDateTime updatedAt;
}

3. 在同一个事务中写入业务数据和 Outbox

@Service
@RequiredArgsConstructor
public class OrderService {

    private final OrderMapper orderMapper;

    private final OutboxEventMapper outboxEventMapper;

    private final ObjectMapper objectMapper;

    @Transactional
    public Long createOrder(CreateOrderCommand command) {
        Order order = new Order();
        order.setOrderNo(command.orderNo());
        order.setUserId(command.userId());
        order.setAmount(command.amount());
        order.setStatus("CREATED");
        order.setCreatedAt(LocalDateTime.now());

        orderMapper.insert(order);

        String eventId = UUID.randomUUID().toString();

        OrderCreatedEvent event = new OrderCreatedEvent(
                eventId,
                order.getId(),
                order.getOrderNo(),
                order.getUserId(),
                order.getAmount(),
                Instant.now()
        );

        OutboxEvent outboxEvent = new OutboxEvent();
        outboxEvent.setId(generateId());
        outboxEvent.setEventId(eventId);
        outboxEvent.setAggregateType("ORDER");
        outboxEvent.setAggregateId(order.getId().toString());
        outboxEvent.setEventType("OrderCreated");
        outboxEvent.setTopic("order-created-topic");
        outboxEvent.setEventKey(order.getId().toString());
        outboxEvent.setPayload(serialize(event));
        outboxEvent.setStatus("PENDING");
        outboxEvent.setRetryCount(0);
        outboxEvent.setCreatedAt(LocalDateTime.now());
        outboxEvent.setUpdatedAt(LocalDateTime.now());

        outboxEventMapper.insert(outboxEvent);

        return order.getId();
    }

    private String serialize(Object value) {
        try {
            return objectMapper.writeValueAsString(value);
        } catch (JsonProcessingException exception) {
            throw new IllegalStateException(
                    "Failed to serialize outbox event",
                    exception
            );
        }
    }

    private long generateId() {
        return ThreadLocalRandom.current().nextLong(
                1,
                Long.MAX_VALUE
        );
    }
}

这里最重要的不是具体代码，而是事务边界：

@Transactional
public Long createOrder(...) {
    // 写业务表
    orderMapper.insert(order);

    // 写 Outbox 表
    outboxEventMapper.insert(outboxEvent);
}

只要它们使用的是同一个数据库和同一个事务管理器，就可以保证：

订单成功 -> Outbox 事件一定存在
订单失败 -> Outbox 事件一定不存在

七、Outbox 事件如何发送到消息中间件

Outbox 表中的事件需要被转发到 Kafka、RocketMQ 等消息中间件。

常见方案有两种：

定时轮询 Outbox 表；
使用 CDC 监听数据库变更日志。

八、方案一：定时轮询 Outbox 表

轮询方案通常由应用中的定时任务完成：

1. 查询状态为 PENDING 的事件
2. 向消息中间件发送消息
3. 发送成功后更新为 PUBLISHED
4. 发送失败则增加 retry_count
5. 达到最大次数后进入 DEAD 状态

示例：

@Component
@RequiredArgsConstructor
public class OutboxPublisher {

    private final OutboxEventMapper outboxEventMapper;

    private final KafkaTemplate<String, String> kafkaTemplate;

    @Scheduled(fixedDelay = 1000)
    public void publish() {
        List<OutboxEvent> events =
                outboxEventMapper.selectPendingEvents(100);

        for (OutboxEvent event : events) {
            publishEvent(event);
        }
    }

    private void publishEvent(OutboxEvent event) {
        try {
            kafkaTemplate.send(
                    event.getTopic(),
                    event.getEventKey(),
                    event.getPayload()
            ).get();

            outboxEventMapper.markPublished(
                    event.getId(),
                    LocalDateTime.now()
            );
        } catch (Exception exception) {
            outboxEventMapper.markFailed(
                    event.getId(),
                    LocalDateTime.now()
            );
        }
    }
}

查询 SQL：

SELECT *
FROM outbox_event
WHERE status = 'PENDING'
  AND (
      next_retry_at IS NULL
      OR next_retry_at <= NOW()
  )
ORDER BY created_at ASC
LIMIT 100;

1. 轮询方案的优点

实现简单；
不依赖额外的 CDC 组件；
应用代码可完全控制重试机制；
容易理解和排查；
适用于中小规模系统。

2. 轮询方案的缺点

会周期性查询数据库；
实时性取决于轮询周期；
多实例并发时容易重复扫描；
需要自行处理锁、重试、状态和死信；
发送成功与状态更新之间仍然存在临界点。

最后一个问题尤其重要。

假设执行流程如下：

1. Kafka 消息发送成功
2. 应用进程崩溃
3. Outbox 状态没有更新为 PUBLISHED

应用重启后，会再次读取这条 PENDING 记录并重新发送消息。

因此：

即使使用 Outbox，也不能保证消息绝对只发送一次。

Outbox 通常提供的是：

At Least Once
至少一次投递

而不是：

Exactly Once
精确一次投递

九、多实例轮询时如何避免并发处理

如果服务部署了多个实例，多个实例可能同时查询到同一批 Outbox 事件。

例如：

实例 A 查询到事件 1001
实例 B 也查询到事件 1001

最终可能造成重复发送。

常见解决方案包括：

悲观锁；
SELECT ... FOR UPDATE SKIP LOCKED；
抢占式状态更新；
分片扫描；
分布式锁。

1. 使用 SKIP LOCKED

MySQL 8 可以使用：

SELECT *
FROM outbox_event
WHERE status = 'PENDING'
ORDER BY created_at
LIMIT 100
FOR UPDATE SKIP LOCKED;

处理流程：

@Transactional
public List<OutboxEvent> claimEvents(int limit) {
    List<OutboxEvent> events =
            outboxEventMapper.selectForUpdateSkipLocked(limit);

    for (OutboxEvent event : events) {
        outboxEventMapper.markProcessing(event.getId());
    }

    return events;
}

不同实例会跳过已经被其他事务锁定的记录。

2. 使用抢占式更新

也可以先把事件从 PENDING 更新为 PROCESSING：

UPDATE outbox_event
SET status = 'PROCESSING',
    updated_at = NOW()
WHERE id = ?
  AND status = 'PENDING';

只有更新行数为 1 的实例获得处理权。

int affectedRows =
        outboxEventMapper.claimEvent(event.getId());

if (affectedRows == 0) {
    return;
}

这种写法实际上使用数据库状态作为轻量级竞争锁。

3. PROCESSING 状态需要超时恢复

如果实例抢到任务后崩溃，事件可能永久停留在 PROCESSING。

因此需要设置处理超时。

例如：

UPDATE outbox_event
SET status = 'PENDING',
    updated_at = NOW()
WHERE status = 'PROCESSING'
  AND updated_at < NOW() - INTERVAL 5 MINUTE;

或者在查询时直接把超时任务视为可重试任务。

十、CDC 是什么

CDC 是 Change Data Capture 的缩写，中文通常称为：

变更数据捕获

CDC 通过读取数据库的事务日志，捕获数据库中的数据变更。

不同数据库有不同的变更日志：

数据库	变更日志
MySQL	Binlog
PostgreSQL	WAL
SQL Server	Transaction Log
Oracle	Redo Log
MongoDB	Oplog / Change Stream

以 MySQL 为例，当 Outbox 表插入一条记录时：

INSERT INTO outbox_event (...);

这次变更会被写入 MySQL Binlog。

CDC 工具读取 Binlog 后，就可以把这条数据库变更转换成消息，并发送到 Kafka。

常见 CDC 工具

常见的 CDC 工具有：

Debezium；
Canal；
Maxwell；
Flink CDC；
AWS DMS；
Kafka Connect JDBC Source。

在 Outbox 场景中，Debezium 是非常典型的实现方案。

十一、CDC 与 Outbox Pattern 的关系

Outbox Pattern 和 CDC 解决的是两个不同阶段的问题。

Outbox Pattern 解决：

如何保证业务数据和事件记录一起提交。

CDC 解决：

如何把已经提交到 Outbox 表中的事件可靠地发送到消息系统。

它们的关系可以表示为：

业务事务
   |
   | 同一个数据库事务
   v
业务表 + Outbox 表
   |
   | CDC 监听 Binlog
   v
Kafka

因此，CDC 并不是 Outbox Pattern 的替代品。

如果直接监听业务表，也可以产生消息，但会面临一些问题：

很难区分业务变更意图；
数据库字段和消息协议强耦合；
一次业务操作可能涉及多张表；
UPDATE 很难表达具体领域事件；
删除操作可能缺少完整业务上下文；
数据修复 SQL 可能误触发业务事件。

例如，订单状态从：

CREATED -> PAID

确实可以推断为 OrderPaid。

但如果管理员执行了一次历史数据修复：

UPDATE orders
SET status = 'PAID'
WHERE id = 100001;

CDC 无法天然判断这究竟是：

正常支付；
数据补偿；
人工修复；
测试操作。

因此更推荐：

由业务代码显式写入领域事件到 Outbox 表，CDC 只负责可靠搬运。

十二、基于 Debezium 的 Outbox 架构

典型架构如下：

Spring Boot
   |
   | 本地事务
   v
MySQL
   |
   | Binlog
   v
Debezium Connector
   |
   v
Kafka Connect
   |
   v
Kafka Topic
   |
   v
消费者

业务代码只需要：

写业务表
写 Outbox 表

不需要负责：

查询 PENDING 事件
发送 Kafka
更新发送状态
管理发送线程

Debezium 会读取数据库日志并将 Outbox 记录发送到 Kafka。

CDC 方案的优点

基于数据库事务日志，数据库压力较小；
不需要持续轮询业务表；
实时性通常更高；
不需要应用自行维护发送线程；
能自然捕获所有已提交记录；
适合中大型事件驱动架构。

CDC 方案的缺点

需要部署 Kafka Connect、Debezium 等组件；
运维复杂度更高；
需要管理 Binlog、WAL 等日志；
需要处理 Schema 变更；
需要监控 CDC 位点和延迟；
仍然可能产生重复消息。

需要再次强调：

CDC 也不能天然保证消费者只收到一次消息。

CDC Connector 发生重启、位点提交失败、Kafka 写入确认异常等情况时，都可能重新发送部分消息。

因此消费者仍然必须实现幂等。

十三、为什么消息重复几乎不可避免

在分布式系统中，很多操作存在这样的不确定状态：

操作可能已经成功，但调用方没有收到成功响应。

例如消费者处理 Kafka 消息：

1. 消费者执行数据库事务成功
2. 消费者进程崩溃
3. Kafka Offset 尚未提交
4. 消费者重启后重新消费

消息被再次投递。

再例如 Outbox Publisher：

1. 消息发送到 Kafka 成功
2. Publisher 没有收到 ACK
3. Publisher 认为发送失败
4. Publisher 再次发送

Kafka 中会出现两条相同事件。

因此可靠消息系统通常选择：

至少一次投递 + 幂等消费

而不是追求整个链路上的绝对精确一次。

十四、什么是幂等消费

幂等表示：

对同一个操作执行一次和执行多次，最终产生的业务结果相同。

数学形式可以表示为：

f(f(x)) = f(x)

在消息消费场景中：

同一条消息被消费一次

和：

同一条消息被消费多次

最终业务结果应当一致。

例如，“设置订单状态为已支付”通常具有一定幂等性：

UPDATE orders
SET status = 'PAID'
WHERE id = 100001;

执行一次和执行多次，最终状态都是 PAID。

但“账户余额增加 100 元”不是天然幂等的：

UPDATE account
SET balance = balance + 100
WHERE user_id = 20001;

如果重复执行两次，余额会增加 200 元。

十五、幂等消费的常见实现方案

常见方案包括：

唯一约束；
消费记录表；
业务状态机；
乐观锁；
Redis 去重；
使用业务唯一键；
天然幂等 SQL。

其中最可靠的通常是：

数据库唯一约束 + 本地事务。

十六、方案一：消费记录表

创建一张消息消费记录表：

CREATE TABLE consumed_event (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    consumer_group VARCHAR(128) NOT NULL,
    event_id VARCHAR(64) NOT NULL,
    event_type VARCHAR(128) NOT NULL,
    consumed_at DATETIME NOT NULL,

    UNIQUE KEY uk_consumer_event (
        consumer_group,
        event_id
    )
);

联合唯一键：

UNIQUE KEY uk_consumer_event (
    consumer_group,
    event_id
)

表示：

同一个消费者组只能处理同一个事件一次。

之所以需要加入 consumer_group，是因为同一条事件可能需要被多个不同业务消费者分别处理。

例如：

OrderCreated

可能同时被以下消费者处理：

inventory-service
points-service
notification-service

这些消费者都应该处理一次，因此不能只对 event_id 建全局唯一约束。

消费代码示例

@Service
@RequiredArgsConstructor
public class OrderCreatedConsumer {

    private final ConsumedEventMapper consumedEventMapper;

    private final InventoryService inventoryService;

    @KafkaListener(
            topics = "order-created-topic",
            groupId = "inventory-service"
    )
    @Transactional
    public void consume(String message) {
        OrderCreatedEvent event = deserialize(message);

        ConsumedEvent consumedEvent = new ConsumedEvent();
        consumedEvent.setConsumerGroup("inventory-service");
        consumedEvent.setEventId(event.eventId());
        consumedEvent.setEventType("OrderCreated");
        consumedEvent.setConsumedAt(LocalDateTime.now());

        try {
            consumedEventMapper.insert(consumedEvent);
        } catch (DuplicateKeyException exception) {
            return;
        }

        inventoryService.reserveInventory(
                event.orderId(),
                event.items()
        );
    }
}

执行流程如下：

1. 插入 consumed_event
2. 执行业务逻辑
3. 提交数据库事务

如果消息第一次消费：

consumed_event 插入成功
业务逻辑执行成功
事务提交

如果消息重复消费：

consumed_event 唯一键冲突
直接返回
不再执行业务逻辑

为什么消费记录和业务操作必须在同一个事务中

错误写法：

public void consume(OrderCreatedEvent event) {
    if (consumedEventMapper.exists(event.eventId())) {
        return;
    }

    inventoryService.reserveInventory(event);

    consumedEventMapper.insert(event.eventId());
}

这段代码存在多个问题。

问题一：先查后写存在并发竞争

两个消费线程可能同时执行：

线程 A：查询，不存在
线程 B：查询，不存在
线程 A：执行业务逻辑
线程 B：执行业务逻辑

最终业务重复执行。

因此不能只依赖：

SELECT 后再判断

必须依赖数据库唯一约束兜底。

问题二：业务成功，消费记录写入失败

执行顺序：

1. 扣减库存成功
2. 写入 consumed_event 失败
3. 消息重新投递
4. 再次扣减库存

因此消费记录和业务操作必须放入同一个本地事务：

@Transactional
public void consume(...) {
    insertConsumedEvent();
    executeBusinessLogic();
}

只有这样才能保证：

消费记录成功 + 业务处理成功

或者：

消费记录失败 + 业务处理回滚

十七、方案二：通过业务唯一键实现幂等

有些业务本身已经具有唯一业务标识。

例如，支付服务处理第三方支付回调时，可以使用：

payment_transaction_no

作为唯一键。

表结构：

CREATE TABLE payment_record (
    id BIGINT PRIMARY KEY,
    payment_transaction_no VARCHAR(128) NOT NULL,
    order_id BIGINT NOT NULL,
    amount DECIMAL(18, 2) NOT NULL,
    created_at DATETIME NOT NULL,

    UNIQUE KEY uk_payment_transaction_no (
        payment_transaction_no
    )
);

消费者直接尝试插入：

try {
    paymentRecordMapper.insert(paymentRecord);
} catch (DuplicateKeyException exception) {
    return;
}

如果支付流水号已经存在，就说明这笔支付已经处理过。

这种方案的优点是：

无需额外消费记录表；
幂等约束直接体现业务语义；
数据库唯一索引强一致；
适合订单号、支付流水号、退款单号等场景。

十八、方案三：基于状态机实现幂等

订单状态更新通常可以通过状态机约束。

例如，只允许订单从 CREATED 更新为 PAID：

UPDATE orders
SET status = 'PAID',
    paid_at = NOW()
WHERE id = ?
  AND status = 'CREATED';

应用根据更新行数判断是否处理成功：

int affectedRows =
        orderMapper.markPaid(orderId);

if (affectedRows == 0) {
    return;
}

第一次消费：

CREATED -> PAID
affectedRows = 1

重复消费：

当前状态已经是 PAID
affectedRows = 0

这种方法不仅可以防止重复消费，还可以防止非法状态流转。

例如：

CANCELLED -> PAID

不应该被允许。

状态机方案的注意事项

只有当重复执行的业务操作可以通过状态流转限制时，状态机方案才适用。

例如：

订单支付
订单取消
订单完成

通常比较适合。

但以下业务不一定适合只通过状态机去重：

增加积分
发送优惠券
记录行为日志
发送短信

因为这些操作可能没有天然的唯一状态转换。

十九、方案四：乐观锁

可以给业务表增加版本号：

ALTER TABLE orders
ADD COLUMN version INT NOT NULL DEFAULT 0;

更新时带上版本号：

UPDATE orders
SET status = 'PAID',
    version = version + 1
WHERE id = ?
  AND status = 'CREATED'
  AND version = ?;

如果更新行数为 0，说明：

订单状态已变化；
数据已经被其他线程修改；
当前消息可能已经被处理；
版本号已经过期。

乐观锁适合解决并发更新，但需要注意：

乐观锁本身并不等价于完整的消息幂等机制。

它主要解决的是同一业务记录的并发修改问题，不一定能识别“这条具体事件是否已经处理过”。

二十、方案五：Redis 去重

也可以使用 Redis 保存已消费事件 ID：

String key =
        "consumed:event:inventory-service:" + event.eventId();

Boolean success = redisTemplate.opsForValue()
        .setIfAbsent(
                key,
                "1",
                Duration.ofDays(7)
        );

if (!Boolean.TRUE.equals(success)) {
    return;
}

inventoryService.reserveInventory(event);

对应 Redis 命令：

SET consumed:event:inventory-service:EVENT_ID 1 NX EX 604800

这种方案速度快，但存在一致性问题。

例如：

1. Redis SET NX 成功
2. 业务数据库处理失败
3. Redis 中已经标记为已消费
4. 消息重试时被直接跳过

最终业务消息丢失。

反过来也可能出现：

1. 业务处理成功
2. Redis 写入失败
3. 消息重试
4. 业务重复执行

因此 Redis 去重更适合：

对强一致性要求不高的通知消息；
日志、埋点等可容忍少量异常的场景；
作为数据库幂等机制之前的快速过滤层；
明确可接受有限时间窗口去重的场景。

对于支付、库存、账务等核心业务，不应只依赖 Redis。

二十一、数据库幂等和 Kafka Offset 的事务边界

消费者通常需要完成两件事：

1. 执行业务数据库事务
2. 提交 Kafka Offset

但这两个动作通常不属于同一个事务。

推荐处理顺序是：

1. 消费消息
2. 执行业务数据库事务
3. 数据库事务提交成功
4. 提交 Kafka Offset

如果在第 3 步和第 4 步之间崩溃：

数据库业务已经成功
Offset 没有提交

消息会再次被消费。

这正是为什么消费者必须幂等。

不推荐先提交 Offset 再处理业务：

1. 提交 Offset
2. 处理业务
3. 业务失败

此时 Kafka 会认为消息已经消费成功，消息可能永久丢失。

因此可靠消费的基本原则是：

先完成业务，再确认消息；允许消息重复，不允许消息丢失。

二十二、Outbox 同样可能重复发送消息

很多开发者误以为：

使用了 Outbox，就不会重复发送消息

这是错误的。

假设轮询程序执行：

1. 读取 Outbox 事件
2. 发送 Kafka 成功
3. 更新 Outbox 状态之前应用崩溃

Outbox 状态仍然是：

PENDING

应用恢复后会再次发送。

CDC 同样可能由于 Connector 重启、位点回退等原因重新发送。

因此完整的可靠链路必须接受这个事实：

消息可能重复

并通过幂等消费把重复影响消除。

二十三、消息顺序问题

Outbox Pattern、CDC 和幂等消费主要解决可靠性问题，但不自动保证消息顺序。

例如同一个订单产生两条事件：

OrderCreated
OrderCancelled

如果消费者先收到：

OrderCancelled

后收到：

OrderCreated

可能导致错误状态。

1. 使用相同的消息 Key

Kafka 可以保证：

同一个 Partition 内消息有序。

因此可以使用 aggregate_id 作为消息 Key：

kafkaTemplate.send(
        "order-event-topic",
        orderId.toString(),
        payload
);

同一个订单的事件会进入同一个 Partition。

2. 增加 aggregate_version

事件中增加聚合版本号：

{
  "eventId": "event-10002",
  "aggregateId": "order-10001",
  "aggregateVersion": 3,
  "eventType": "OrderCancelled"
}

消费者记录已经处理的最大版本号：

last_processed_version = 2

只有当：

event.aggregateVersion = last_processed_version + 1

时才处理。

对于小于等于当前版本的事件，可以认为是重复或过期消息。

3. 不要把全局有序作为默认目标

Kafka 只能在单个 Partition 内保证顺序。

如果为了全局有序而只使用一个 Partition，会严重限制吞吐量。

更合理的目标通常是：

同一个业务聚合内有序
不同业务聚合之间并行

例如：

同一个订单内有序
不同订单之间无需有序

二十四、消息版本兼容

事件一旦发送到消息中间件，就可能被多个消费者长期依赖。

因此事件结构需要考虑版本演进。

建议增加：

{
  "eventType": "OrderCreated",
  "eventVersion": 2
}

版本升级时尽量保持向后兼容。

例如，原事件：

{
  "orderId": 100001,
  "amount": 199.00
}

新增字段：

{
  "orderId": 100001,
  "amount": 199.00,
  "currency": "CNY"
}

通常是向后兼容的。

但删除字段、修改字段类型、改变字段语义可能造成消费者失败。

不推荐：

{
  "amount": "199.00 CNY"
}

因为原来的 amount 从数字变成了字符串。

更好的做法是新增字段：

{
  "amount": 199.00,
  "currency": "CNY"
}

二十五、失败重试和死信队列

消费者处理失败后，需要配置合理的重试策略。

推荐使用指数退避：

第 1 次：1 秒后
第 2 次：5 秒后
第 3 次：30 秒后
第 4 次：5 分钟后

不建议无限快速重试，否则可能导致：

CPU 占用过高；
消息积压；
数据库持续承压；
日志大量刷屏；
阻塞同一 Partition 后续消息。

超过最大重试次数后，可以进入死信队列：

order-created-topic
    |
    | 多次消费失败
    v
order-created-topic.DLT

死信消息中建议保留：

原始消息
eventId
eventType
消费组
失败原因
异常堆栈
重试次数
首次失败时间
最后失败时间

二十六、Outbox 数据清理

Outbox 表会不断增长，因此需要设计清理机制。

例如，删除 30 天前已经成功发送的事件：

DELETE FROM outbox_event
WHERE status = 'PUBLISHED'
  AND published_at < NOW() - INTERVAL 30 DAY
LIMIT 1000;

建议分批删除，不要一次删除大量数据：

每次删除 1000 条
循环执行
每轮适当休眠

否则可能造成：

长事务；
锁等待；
Binlog 急剧增长；
主从复制延迟；
数据库 IO 峰值。

如果事件具有审计价值，也可以迁移到历史表：

outbox_event
    |
    v
outbox_event_archive

或者存入低成本对象存储。

二十七、消费记录表清理

consumed_event 同样会持续增长。

但清理消费记录需要谨慎，因为记录删除后，历史消息如果重新投递，可能再次被处理。

清理策略需要结合：

Kafka 消息保留时间；
最大允许重放时间；
业务数据生命周期；
灾难恢复策略；
消息补偿周期。

例如：

Kafka 保留消息 7 天
业务最多重放 15 天
consumed_event 保留 30 天

消费记录的保留时间应该明显大于消息可能被重新投递的时间窗口。

对于支付、账务等核心数据，也可以永久保留业务唯一流水，而不是依赖可清理的通用消费记录。

二十八、监控指标

可靠消息链路不能只实现功能，还必须具备可观测性。

Outbox 指标

建议监控：

PENDING 事件数量
PROCESSING 事件数量
FAILED 事件数量
DEAD 事件数量
最老 PENDING 事件等待时间
平均发布延迟
发送成功率
重试次数
每秒发布事件数

其中最重要的通常是：

最老未发送事件年龄

如果最老事件已经等待 30 分钟，即使 PENDING 数量并不多，也说明发布链路可能出现异常。

CDC 指标

建议监控：

CDC Connector 状态
Binlog/WAL 位点
源数据库与 Kafka 的延迟
Connector 重启次数
消息发送失败次数
Schema 解析失败次数
任务是否处于 RUNNING 状态

消费者指标

建议监控：

Consumer Lag
消费成功率
消费失败率
单条消息处理耗时
重复事件数量
幂等冲突数量
重试队列长度
死信队列数量
最老未消费消息年龄

二十九、完整代码流程示例

1. 生产端事务

@Transactional
public void createOrder(CreateOrderCommand command) {
    Order order = createOrderEntity(command);
    orderMapper.insert(order);

    OrderCreatedEvent event = new OrderCreatedEvent(
            UUID.randomUUID().toString(),
            order.getId(),
            order.getOrderNo(),
            Instant.now()
    );

    OutboxEvent outboxEvent = OutboxEvent.builder()
            .id(idGenerator.nextId())
            .eventId(event.eventId())
            .aggregateType("ORDER")
            .aggregateId(order.getId().toString())
            .eventType("OrderCreated")
            .topic("order-event-topic")
            .eventKey(order.getId().toString())
            .payload(toJson(event))
            .status("PENDING")
            .retryCount(0)
            .createdAt(LocalDateTime.now())
            .updatedAt(LocalDateTime.now())
            .build();

    outboxEventMapper.insert(outboxEvent);
}

事务提交后，数据库中一定同时存在：

orders 记录
outbox_event 记录

2. CDC 读取 Outbox

MySQL Binlog
    |
    v
Debezium
    |
    v
Kafka order-event-topic

消息 Key 使用：

aggregate_id

例如：

这样同一个订单的事件可以进入同一个 Kafka Partition。

3. 消费端幂等处理

@Service
@RequiredArgsConstructor
public class InventoryOrderEventConsumer {

    private static final String CONSUMER_GROUP =
            "inventory-service";

    private final ConsumedEventMapper consumedEventMapper;

    private final InventoryService inventoryService;

    @KafkaListener(
            topics = "order-event-topic",
            groupId = CONSUMER_GROUP
    )
    @Transactional
    public void consume(OrderCreatedEvent event) {
        try {
            consumedEventMapper.insert(
                    new ConsumedEvent(
                            null,
                            CONSUMER_GROUP,
                            event.eventId(),
                            "OrderCreated",
                            LocalDateTime.now()
                    )
            );
        } catch (DuplicateKeyException exception) {
            return;
        }

        inventoryService.reserveByOrder(
                event.orderId()
        );
    }
}

执行结果：

第一次收到：
消费记录插入成功
库存预占成功
事务提交

第二次收到：
消费记录唯一键冲突
直接返回
库存不会重复预占

三十、常见错误设计

错误一：业务事务中直接发送 MQ

@Transactional
public void createOrder() {
    orderMapper.insert(order);
    kafkaTemplate.send(topic, message);
}

问题：

数据库事务和 Kafka 发送不属于同一个原子事务

错误二：事务提交后再发送，但没有补偿机制

orderService.createOrder();

kafkaTemplate.send(topic, message);

问题：

数据库提交后应用可能崩溃
消息没有发送，也无法自动发现

错误三：认为 Outbox 可以保证消息只发送一次

Outbox 只能保证：

业务数据和事件记录同时存在

它不能保证：

事件绝不重复发送

错误四：消费者先查再处理

if (exists(eventId)) {
    return;
}

executeBusiness();
insertConsumedEvent(eventId);

问题：

存在并发竞争窗口

必须使用：

唯一索引

作为最终防线。

错误五：消费记录和业务操作不在同一个事务

insertConsumedEvent();
executeBusiness();

如果第二步失败，但第一步已经提交，消息重试时会被错误跳过。

错误六：仅依赖 Redis 做核心业务幂等

Redis 和业务数据库之间缺少本地事务，容易出现状态不一致。

核心资金、库存、支付业务应优先使用数据库唯一约束或业务状态机。

错误七：把技术消息直接暴露为业务事件

直接把整张数据库表的 CDC 变更发送给所有消费者，会让下游系统与数据库结构强耦合。

例如：

{
  "before": {
    "status": 0
  },
  "after": {
    "status": 1
  },
  "op": "u"
}

下游必须知道：

status = 0 表示什么
status = 1 表示什么

数据库字段一旦变化，所有消费者都可能受到影响。

更好的方式是发送明确的业务事件：

{
  "eventType": "OrderPaid",
  "eventVersion": 1,
  "data": {
    "orderId": 100001,
    "paidAt": "2026-07-16T10:30:00Z"
  }
}

三十一、轮询 Outbox 和 CDC 应该如何选择

可以根据系统规模和基础设施选择。

适合使用轮询的场景

系统规模较小；
消息量不高；
不希望维护 Kafka Connect；
对秒级延迟可以接受；
团队希望先快速落地；
已经有成熟的定时任务平台。

适合使用 CDC 的场景

消息量较大；
对实时性要求较高；
已经使用 Kafka Connect；
团队具备 CDC 运维能力；
需要标准化事件发布链路；
多个服务都需要 Outbox 能力；
希望减少应用内消息发布代码。

三十二、三者分别解决什么问题

可以用一张表总结：

机制	解决的问题	不能解决的问题
Outbox Pattern	业务数据和事件记录的一致性	消息重复、消费者重复处理
CDC	可靠捕获和发布数据库变更	消息绝不重复、消费幂等
幂等消费	消除重复消息带来的业务影响	生产端事件缺失
Kafka ACK	Kafka Broker 内部写入可靠性	数据库和 Kafka 的原子一致性
Kafka Offset	记录消费者读取进度	业务处理是否重复
重试机制	临时故障恢复	永久性业务错误
死信队列	隔离持续失败的消息	自动修复业务数据

三十三、推荐的企业级实现原则

在实际项目中，可以遵循以下原则。

1. 业务数据和 Outbox 使用同一个本地事务

业务表写入
Outbox 表写入
必须原子提交

2. 每条事件必须有全局唯一 event_id

event_id

需要从生产端一直透传到消费端。

3. 采用至少一次投递模型

不要假设消息不会重复。

At Least Once + Idempotent Consumer

通常是更现实、更可靠的工程方案。

4. 消费者必须默认实现幂等

不要等到生产环境出现重复消费后再补幂等。

重复消息不是异常现象，而是可靠消息系统的正常边界情况。

5. 数据库唯一约束必须作为最终防线

应用代码判断只能作为优化，不能代替数据库唯一约束。

应用判断：提高可读性或减少异常
数据库唯一键：保证并发正确性

6. 幂等记录和业务操作必须处于同一个事务

否则会出现：

标记成功但业务失败

或者：

业务成功但标记失败

7. 使用 aggregate_id 作为 Kafka Key

保证同一个业务聚合内的事件进入同一个 Partition。

orderId
userId
paymentId

都可以作为消息 Key，具体取决于聚合边界。

8. 设计重试、死信和人工补偿机制

可靠消息系统不能只考虑成功路径。

需要明确处理：

临时失败
永久失败
毒消息
消费超时
死信重放
人工补偿
事件重放

9. 事件协议必须版本化

推荐字段：

{
  "eventId": "...",
  "eventType": "...",
  "eventVersion": 1,
  "aggregateId": "...",
  "occurredAt": "...",
  "traceId": "...",
  "data": {}
}

10. 为整个链路建立可观测性

应该能够通过 eventId 查询：

事件何时产生
是否写入 Outbox
CDC 是否捕获
写入哪个 Topic
消费者是否收到
是否重复消费
是否处理成功
是否进入死信队列

三十四、最终架构

一个完整、可靠的事件驱动架构可以表示为：

┌──────────────────────┐
│     Order Service    │
│                      │
│  1. 写入 orders      │
│  2. 写入 outbox      │
└──────────┬───────────┘
           │
           │ 同一个本地事务
           v
┌──────────────────────┐
│        MySQL         │
│                      │
│ orders               │
│ outbox_event         │
└──────────┬───────────┘
           │
           │ Binlog
           v
┌──────────────────────┐
│ Debezium / CDC       │
└──────────┬───────────┘
           │
           v
┌──────────────────────┐
│        Kafka         │
│ order-event-topic    │
└──────────┬───────────┘
           │
           v
┌──────────────────────┐
│ Inventory Consumer   │
│                      │
│ consumed_event       │
│ inventory_business   │
│ 同一个本地事务       │
└──────────────────────┘

这套架构中：

Outbox 保证事件不会因为业务事务边界而缺失
CDC 保证已提交事件可以被可靠捕获
Kafka 提供持久化和分发能力
幂等消费解决重复投递问题
重试和死信机制解决消费失败问题
监控和追踪保证系统可以被运维

总结

Outbox Pattern、CDC 和幂等消费是构建可靠事件驱动系统的三个核心组成部分。

Outbox Pattern 的核心是：

将业务数据和事件记录写入同一个本地数据库事务。

CDC 的核心是：

读取数据库事务日志，将已经提交的 Outbox 事件可靠地发送到消息中间件。

幂等消费的核心是：

即使同一条消息被重复投递，也只产生一次有效业务结果。

三者组合后的完整语义是：

业务数据和事件记录原子提交
        +
事件至少一次可靠发布
        +
消费者幂等处理
        =
最终一致的事件驱动系统

需要特别理解的是：

Outbox 不是为了实现整个分布式链路的精确一次，而是把无法控制的“双写问题”，转换成可恢复、可重试、可观测的单库事务问题。

工程实践中，不应该把目标定义为：

消息永远不重复

更合理的目标是：

消息可以重复，但业务结果不能重复

这也是绝大多数可靠消息系统最终采用的设计：

At Least Once Delivery
        +
Idempotent Consumer
        =
Effectively Once

为什么 Kafka ACK 不能替代 Outbox 模式

Wed, 15 Jul 2026 18:21:22 +0800

前言

在使用 Kafka 构建事件驱动系统时，一个非常常见的误解是：

Kafka 已经支持 ACK 确认机制，只要生产者收到 Kafka 的发送确认，就能够保证数据库操作和消息发送的一致性，因此没有必要再使用 Outbox。

这个结论看起来很合理。

Kafka Producer 可以通过 acks=all 确认消息已经写入 Kafka；Kafka Consumer 也可以在业务处理成功后再提交 Offset。既然生产端和消费端都有确认机制，为什么还需要额外设计一张 Outbox 表？

问题在于：

Kafka ACK 只能确认 Kafka 内部的消息写入结果，无法保证数据库事务与 Kafka 消息发送之间的原子性。

Outbox Pattern 解决的是数据库事务和消息发送的一致性问题
Kafka ACK 解决的是消息是否已经被 Kafka 接收并持久化的问题。

两者解决的根本不是同一个问题。

一、先看一个典型业务场景

假设我们有一个订单服务。

用户创建订单时，需要完成两个操作：

将订单写入 MySQL；
向 Kafka 发送一条 OrderCreated 事件。

伪代码如下：

@Transactional
public void createOrder(CreateOrderCommand command) {
    Order order = new Order();
    order.setUserId(command.getUserId());
    order.setAmount(command.getAmount());

    orderRepository.save(order);

    kafkaTemplate.send(
        "order-created-topic",
        order.getId(),
        new OrderCreatedEvent(order.getId())
    );
}

业务希望实现下面的语义：

订单创建成功等价于数据库中存在订单，并且 Kafka 中一定存在 OrderCreated 事件

也就是说：

数据库提交成功，消息必须发送成功
数据库回滚，消息不能被发送

这实际上是在要求两个不同系统之间保持原子性：

MySQL
Kafka

理想状态是：

要么全部成功
要么全部失败

但普通的本地事务只能控制 MySQL，不能同时控制 Kafka。

二、Kafka ACK 到底确认了什么？

Kafka Producer 发送消息时，可以通过 acks 参数控制 Broker 的确认条件。

常见配置如下：

spring:
  kafka:
    producer:
      acks: all

Kafka 的 acks 主要有三个取值：

配置	含义
`acks=0`	Producer 不等待 Broker 确认
`acks=1`	Leader 写入本地日志后返回成功
`acks=all`	Leader 等待 ISR 中满足条件的副本完成同步后返回成功

使用：

acks=all

能够显著提高消息的可靠性。

它能够回答的问题是：

这条消息是否已经按照 Kafka 的可靠性要求写入 Broker？

但是它无法回答：

这条 Kafka 消息对应的数据库事务是否已经提交？

Kafka Broker 并不知道 MySQL 的事务状态。

对于 Kafka 来说，它只负责处理这条消息：

OrderCreated(orderId=1001)

它不知道：

order_id = 1001

对应的订单记录是否已经成功写入数据库。

因此，Kafka ACK 能确认的是：

Kafka 消息写入成功

它不能确认：

数据库事务与 Kafka 消息同时成功

三、最核心的问题：双写一致性

同时写入数据库和 Kafka，本质上属于“双写”。

一次业务操作
   ├── 写 MySQL
   └── 写 Kafka

只要两个操作不处于同一个原子事务中，就一定存在中间状态。

无论先写数据库还是先发送 Kafka，都存在失败窗口。

四、先写数据库，再发送 Kafka

第一种常见实现是：

@Transactional
public void createOrder(CreateOrderCommand command) {
    Order order = orderRepository.save(...);

    kafkaTemplate.send(
        "order-created-topic",
        new OrderCreatedEvent(order.getId())
    );
}

逻辑顺序是：

1. 写入数据库
2. 发送 Kafka
3. 提交数据库事务

或者在某些实现中：

1. 写入数据库
2. 提交数据库事务
3. 发送 Kafka

这两种顺序都存在问题。

场景一：数据库成功，Kafka 发送失败

执行过程如下：

1. MySQL 事务提交成功
2. 发送 Kafka
3. 网络超时或 Kafka 不可用
4. 消息发送失败

最终状态：

MySQL：订单存在
Kafka：没有 OrderCreated 消息

这意味着下游系统无法感知订单创建。

例如：

库存服务没有扣减库存；
积分服务没有发放积分；
通知服务没有发送通知；
搜索系统没有建立订单索引。

即使使用：

acks=all

也无法解决这个问题。

因为此时 Kafka 根本没有返回成功 ACK。

数据库已经提交，而消息发送失败。Kafka ACK 只能告诉你“发送失败了”，却不能自动撤销已经提交的数据库事务。

场景二：Kafka 发送成功，数据库事务回滚

执行过程如下：

1. 写入订单数据
2. 发送 Kafka
3. Kafka 返回 ACK
4. 后续业务逻辑抛出异常
5. MySQL 事务回滚

最终状态：

MySQL：订单不存在
Kafka：存在 OrderCreated 消息

下游消费者收到消息后，可能开始处理一个根本不存在的订单。

例如：

  graph TD
    A[库存服务收到 OrderCreated] --> B[尝试锁定库存]
    B --> C[订单服务数据库中却不存在该订单]

这里 Kafka ACK 完全正常。

Kafka 确实成功保存了消息，因此返回 ACK 没有任何问题。

真正的问题是：

Kafka 消息已经提交，但数据库事务最终回滚了。

Kafka ACK 无法预知未来的数据库事务是否会回滚。

五、先发送 Kafka，再提交数据库，同样不安全

有些开发者会尝试调整顺序：

@Transactional
public void createOrder(CreateOrderCommand command) {
    kafkaTemplate.send(
        "order-created-topic",
        new OrderCreatedEvent(...)
    ).get();

    orderRepository.save(...);
}

执行顺序变成：

1. 发送 Kafka
2. 等待 Kafka ACK
3. 写入数据库
4. 提交事务

这样虽然可以确保 Kafka 发送成功后再继续写数据库，但仍然存在问题。

执行过程可能是：

1. Kafka 消息发送成功
2. Kafka 返回 ACK
3. 数据库写入失败
4. 数据库事务回滚

最终状态仍然是：

MySQL：没有订单
Kafka：存在 OrderCreated 消息

Kafka ACK 只能证明：

Kafka 已经接收了消息

不能证明：

接下来的数据库操作一定成功

因此，仅仅调整执行顺序无法消除双写问题。

六、为什么捕获异常后补偿也不可靠？

一种常见做法是：

try {
    orderRepository.save(order);
    kafkaTemplate.send(...).get();
} catch (Exception exception) {
    // 执行补偿逻辑
}

或者：

try {
    kafkaTemplate.send(...).get();
    orderRepository.save(order);
} catch (Exception exception) {
    // 删除消息或者回滚订单
}

这种方式的问题是，补偿本身也可能失败。

例如：

  graph TD
    A[数据库提交成功] --> B[Kafka 发送失败]
    B --> C[准备执行数据库补偿删除]
    C --> D[应用进程崩溃]

最终依然是：

数据库中存在订单
Kafka 中没有消息

再比如：

  graph TD
    A[Kafka 发送成功] --> B[数据库提交失败]
    B --> C[准备发送一条取消事件]
    C --> D[服务器断电]

最终依然会留下不一致状态。

普通的 try-catch 只能处理当前线程中能够捕获的异常，无法覆盖：

JVM 崩溃；
服务器宕机；
容器被强制终止；
网络中断；
进程被 kill -9；
数据库连接突然断开；
Kafka 返回 ACK 后应用进程立即退出。

双写问题最难处理的地方，不是普通异常，而是：

两个操作之间存在不可消除的故障窗口。

七、Kafka ACK 不等于业务事务提交

可以把 Kafka ACK 理解为 Kafka 自己的局部确认。

Kafka 返回 ACK 的含义类似于：

我 Kafka 已经按照你的配置接收并保存了这条消息。

但它不会承诺：

你的数据库事务也已经成功提交。

因为 Kafka 无法控制 MySQL。

同样，MySQL 提交成功的含义是：

数据库中的修改已经提交。

但 MySQL 也不会承诺：

Kafka 中对应的消息一定已经存在。

因为 MySQL 无法控制 Kafka。

因此，系统中实际存在两个独立的提交点：

MySQL COMMIT
Kafka ACK

两个提交点之间一定存在时间差。

  graph TD
    A[MySQL COMMIT] --> B[故障窗口]
    B --> C[Kafka ACK]

或者：

  graph TD
    A[Kafka ACK] --> B[故障窗口]
    B --> C[MySQL COMMIT]

只要故障发生在这个窗口内，就会出现数据不一致。

八、Kafka ACK 还可能存在“不确定结果”

除了明确成功和明确失败之外，分布式系统中还存在第三种状态：

结果未知

例如：

1. Producer 将消息发送给 Kafka
2. Kafka 成功写入消息
3. Kafka 返回 ACK
4. ACK 在网络中丢失
5. Producer 等待超时

此时 Kafka 中的真实状态是：

消息已经写入

但 Producer 观察到的状态是：

发送超时

Producer 无法确定消息到底有没有成功。

于是 Producer 可能重试：

第一次消息：已经成功写入
第二次消息：重试后再次写入

如果没有幂等机制，就可能产生重复消息。

即使启用了 Kafka 幂等生产者：

spring:
  kafka:
    producer:
      properties:
        enable.idempotence: true

它主要解决的也是 Producer 重试导致的 Kafka 内部重复写入问题。

它依然无法保证：

MySQL 事务和 Kafka 消息原子提交

这再次说明：

Kafka 的可靠性机制主要作用于 Kafka 内部，而 Outbox 解决的是跨系统的一致性问题。

九、Outbox Pattern 是什么？

Outbox Pattern，也叫事务发件箱模式。

核心思想是：

不在业务事务中直接发送 Kafka，而是将“业务数据”和“待发送消息”写入同一个数据库事务。

例如，订单服务有两张表：

orders
outbox_event

创建订单时：

@Transactional
public void createOrder(CreateOrderCommand command) {
    Order order = new Order();
    order.setUserId(command.getUserId());
    order.setAmount(command.getAmount());

    orderRepository.save(order);

    OutboxEvent event = new OutboxEvent();
    event.setAggregateType("ORDER");
    event.setAggregateId(order.getId().toString());
    event.setEventType("OrderCreated");
    event.setPayload(toJson(new OrderCreatedEvent(order.getId())));
    event.setStatus("PENDING");

    outboxEventRepository.save(event);
}

此时本地事务中只操作 MySQL：

BEGIN

INSERT INTO orders ...
INSERT INTO outbox_event ...

COMMIT

由于订单记录和 Outbox 事件位于同一个数据库事务中，因此可以实现原子性：

要么订单和事件记录同时提交
要么订单和事件记录同时回滚

这解决了最关键的问题：

数据库中不会出现“订单存在但没有事件记录”的状态

十、Outbox 如何把消息发送到 Kafka？

Outbox 表中的消息提交成功后，由独立的消息发布器负责发送到 Kafka。

常见实现方式有两种：

轮询 Outbox 表；
使用 CDC 监听数据库变更。

十一、方案一：定时轮询 Outbox 表

发布器定期查询待发送事件：

SELECT id,
       aggregate_type,
       aggregate_id,
       event_type,
       payload
FROM outbox_event
WHERE status = 'PENDING'
ORDER BY id
LIMIT 100;

发送成功后更新状态：

UPDATE outbox_event
SET status = 'SENT',
    sent_at = NOW()
WHERE id = ?;

示例代码：

@Scheduled(fixedDelay = 1000)
public void publishEvents() {
    List<OutboxEvent> events =
        outboxEventRepository.findPendingEvents(100);

    for (OutboxEvent event : events) {
        try {
            kafkaTemplate.send(
                event.getTopic(),
                event.getAggregateId(),
                event.getPayload()
            ).get();

            outboxEventRepository.markAsSent(event.getId());
        } catch (Exception exception) {
            outboxEventRepository.recordFailure(
                event.getId(),
                exception.getMessage()
            );
        }
    }
}

如果 Kafka 暂时不可用：

Outbox 事件仍然保留在数据库中

下一次轮询可以继续重试。

因此，系统将：

一次不可靠的即时双写

转换为：

一次可靠的本地事务
+
一个可持久化、可重试的异步发送过程

十二、方案二：CDC

CDC 是 Change Data Capture，即变更数据捕获。

可以通过 Debezium 等工具监听数据库 Binlog。

执行过程如下：

  graph TD
    A[业务事务] --> B[写入 orders]
    B --> C[写入 outbox_event]
    C --> D[提交 MySQL 事务]
    D --> E[Binlog 记录变更]
    E --> F[Debezium 捕获 Outbox 记录]
    F --> G[发送到 Kafka]

这种方案通常不需要应用程序主动轮询数据库。

架构如下：

┌──────────────────┐
│  Order Service   │
└────────┬─────────┘
         │ 本地事务
         ▼
┌──────────────────┐
│      MySQL       │
│                  │
│ orders           │
│ outbox_event     │
└────────┬─────────┘
         │ Binlog
         ▼
┌──────────────────┐
│     Debezium     │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│      Kafka       │
└──────────────────┘

CDC Outbox 通常具有以下优势：

实时性更高；
减少数据库轮询；
应用逻辑更简单；
更适合大规模事件驱动架构。

但它也会增加基础设施复杂度。

十三、Outbox 为什么比 ACK 更可靠？

Outbox 的关键不是“发送 Kafka 时更加可靠”，而是：

将必须保持一致的两个数据写入，收敛到同一个本地数据库事务中。

原来的双写模型：

MySQL + Kafka

变成：

MySQL 业务表 + MySQL Outbox 表

因为它们在同一个数据库中，可以使用同一个本地事务：

BEGIN

INSERT INTO orders ...
INSERT INTO outbox_event ...

COMMIT

此时不会存在：

订单提交成功，但事件记录丢失

之后从 Outbox 发送 Kafka，即使失败，也可以通过持久化状态不断重试。

这是一种非常重要的架构思想：

不要试图让两个无法原子提交的系统强行同时成功，而是先在一个可靠事务中记录事实，再异步传播这个事实。

十四、Kafka ACK 在 Outbox 中仍然有价值

需要注意的是，使用 Outbox 并不意味着 Kafka ACK 没有价值。

Outbox 和 Kafka ACK 不是互斥关系，而是互补关系。

在 Outbox 发布器中，仍然需要等待 Kafka ACK：

kafkaTemplate.send(
    topic,
    key,
    payload
).get();

只有收到 Kafka 的成功确认后，才能将 Outbox 事件标记为已发送。

正确流程是：

  graph TD
    A[读取 PENDING 事件] --> B[发送 Kafka]
    B --> C[等待 Kafka ACK]
    C --> D[更新为 SENT]

因此：

Outbox 负责保证业务数据和事件记录的一致性
Kafka ACK 负责确认事件是否成功写入 Kafka

两者职责如下：

机制	解决的问题
数据库本地事务	业务表与 Outbox 表原子提交
Outbox	数据库状态变更与消息发送最终一致
Kafka ACK	确认 Kafka 是否成功接收消息
Kafka 幂等 Producer	降低 Producer 重试产生重复消息的风险
消费者幂等	避免重复消费造成重复业务处理

所以正确的理解不是：

ACK 和 Outbox 二选一

而是：

Outbox + ACK + 重试 + 幂等

十五、Outbox 也无法天然保证消息只发送一次

Outbox 通常保证的是：

At Least Once

也就是至少发送一次，而不是严格的 Exactly Once。

考虑下面的场景：

1. 发布器读取 Outbox 事件
2. 成功发送到 Kafka
3. Kafka 返回 ACK
4. 发布器准备更新状态为 SENT
5. 应用进程崩溃

此时：

Kafka：消息已经存在
Outbox：状态仍然是 PENDING

应用重启后，会再次发送这条消息。

于是 Kafka 中可能出现重复事件。

这说明 Outbox 解决的是：

消息不能丢

但通常不会直接保证：

消息绝不重复

因此下游消费者必须具备幂等能力。

十六、消费者如何实现幂等？

每条事件都应该具有唯一标识：

{
  "eventId": "01JXABCDEF123456",
  "eventType": "OrderCreated",
  "aggregateId": "1001",
  "occurredAt": "2026-07-15T10:30:00Z",
  "payload": {
    "orderId": 1001
  }
}

消费者处理前，先检查 eventId 是否已经处理。

例如建立事件消费记录表：

CREATE TABLE consumed_event (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    event_id VARCHAR(64) NOT NULL,
    consumer_name VARCHAR(128) NOT NULL,
    consumed_at DATETIME NOT NULL,
    UNIQUE KEY uk_event_consumer (
        event_id,
        consumer_name
    )
);

消费时：

@Transactional
public void handle(OrderCreatedEvent event) {
    boolean inserted = consumedEventRepository.tryInsert(
        event.getEventId(),
        "inventory-service"
    );

    if (!inserted) {
        return;
    }

    inventoryService.reserve(event.getOrderId());
}

依靠唯一索引：

event_id + consumer_name

避免同一消费者重复处理同一事件。

十七、Kafka Consumer ACK 也不能替代 Outbox

有时开发者提到的 ACK，并不是 Producer 的 acks，而是消费者手动确认。

例如：

@KafkaListener(topics = "order-created-topic")
public void consume(
        OrderCreatedEvent event,
        Acknowledgment acknowledgment) {

    orderHandler.handle(event);

    acknowledgment.acknowledge();
}

消费者手动提交 Offset 能解决的问题是：

业务处理失败时，不要过早提交消费位点

它控制的是：

消费者是否认为这条消息已经处理完成

但它依然与生产端的数据库和 Kafka 双写无关。

消费者 ACK 发生在消息已经进入 Kafka 之后：

  graph TD
    A[生产者写数据库] --> B[生产者发送 Kafka]
    B --> C[Kafka 保存消息]
    C --> D[消费者读取消息]
    D --> E[消费者提交 ACK]

如果消息根本没有成功发送到 Kafka，消费者就没有机会处理，更谈不上提交 ACK。

因此，消费者 ACK 解决的是消费可靠性问题，而 Outbox 解决的是生产端事件发布一致性问题。

十八、几种机制分别解决什么问题？

可以通过下面这张表进行区分。

机制	作用范围	主要解决的问题
Kafka Producer ACK	Producer 到 Kafka	消息是否成功写入 Kafka
Kafka Producer Retry	Producer 到 Kafka	临时故障下自动重试
Kafka Idempotent Producer	Kafka 内部	降低重试导致的重复写入
Kafka Transaction	Kafka 内部或 Kafka 到 Kafka	多个 Kafka 写入及 Offset 提交的一致性
Consumer Offset Commit	Kafka Consumer	控制消息消费进度
Consumer Manual ACK	Kafka Consumer	业务处理成功后再提交位点
Outbox Pattern	数据库到消息系统	业务数据与事件发布最终一致
消费者幂等	消费者业务层	防止重复消息造成重复业务操作

这些机制各自解决不同层面的问题，不能简单互相替代。

十九、Kafka Transaction 能不能替代 Outbox？

Kafka 支持事务生产者，例如：

kafkaTemplate.executeInTransaction(operations -> {
    operations.send("topic-a", messageA);
    operations.send("topic-b", messageB);
    return true;
});

Kafka Transaction 可以保证：

多条 Kafka 消息要么都可见，要么都不可见

也可以在消费—处理—再生产模型中，实现：

消费 Offset 提交
+
发送新的 Kafka 消息

之间的原子性。

例如：

  graph TD
    A[Kafka Topic A] --> B[Consumer]
    B --> C[Kafka Topic B]

Kafka Transaction 很适合 Kafka 内部的流式处理。

但是普通 Kafka Transaction 不能直接把 MySQL 本地事务纳入同一个原子提交中。

系统仍然存在：

MySQL COMMIT
Kafka Transaction COMMIT

两个独立提交点。

因此：

Kafka Transaction

不能天然保证：

MySQL + Kafka

的跨系统原子性。

只要业务核心数据存储在 MySQL、PostgreSQL 等外部数据库中，Outbox 仍然是非常常见且可靠的解决方案。

二十、Spring 的事务同步回调能替代 Outbox 吗？

有些项目会使用：

TransactionSynchronizationManager.registerSynchronization(
    new TransactionSynchronization() {
        @Override
        public void afterCommit() {
            kafkaTemplate.send(...);
        }
    }
);

这种做法可以确保：

只有数据库事务提交成功后，才发送 Kafka

它确实避免了：

数据库回滚，但 Kafka 消息已经发送

但仍然无法解决：

  graph TD
    A[数据库已经提交] --> B[应用崩溃]
    B --> C[afterCommit 逻辑未执行]

或者：

  graph TD
    A[数据库已经提交] --> B[发送 Kafka 失败]

最终状态仍然可能是：

数据库有数据
Kafka 无消息

所以 afterCommit 适合：

缓存清理；
本地通知；
非关键异步操作；
允许偶尔丢失的逻辑。

但对于订单、支付、库存等不能丢失的领域事件，afterCommit 不能代替 Outbox。

二十一、典型 Outbox 表设计

一个相对完整的 Outbox 表可以设计如下：

CREATE TABLE outbox_event (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,

    event_id VARCHAR(64) NOT NULL,
    aggregate_type VARCHAR(64) NOT NULL,
    aggregate_id VARCHAR(64) NOT NULL,
    event_type VARCHAR(128) NOT NULL,

    topic VARCHAR(128) NOT NULL,
    message_key VARCHAR(128) DEFAULT NULL,
    payload JSON NOT NULL,

    status VARCHAR(32) NOT NULL DEFAULT 'PENDING',
    retry_count INT NOT NULL DEFAULT 0,
    next_retry_at DATETIME DEFAULT NULL,
    sent_at DATETIME DEFAULT NULL,

    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,

    UNIQUE KEY uk_event_id (event_id),
    KEY idx_publish_scan (
        status,
        next_retry_at,
        id
    ),
    KEY idx_aggregate (
        aggregate_type,
        aggregate_id
    )
);

字段说明：

字段	作用
`event_id`	事件唯一标识，用于幂等
`aggregate_type`	聚合类型，例如 `ORDER`
`aggregate_id`	聚合根 ID，例如订单 ID
`event_type`	事件类型，例如 `OrderCreated`
`topic`	Kafka Topic
`message_key`	Kafka 消息 Key
`payload`	事件内容
`status`	发送状态
`retry_count`	重试次数
`next_retry_at`	下次重试时间
`sent_at`	成功发送时间

状态可以定义为：

PENDING
PROCESSING
SENT
FAILED

二十二、轮询 Outbox 时需要注意并发问题

如果部署了多个消息发布器实例，必须避免多个实例同时发送同一条事件。

可以使用数据库行锁：

SELECT *
FROM outbox_event
WHERE status = 'PENDING'
  AND (
      next_retry_at IS NULL
      OR next_retry_at <= NOW()
  )
ORDER BY id
LIMIT 100
FOR UPDATE SKIP LOCKED;

处理流程：

1. 开启事务
2. 使用 FOR UPDATE SKIP LOCKED 获取任务
3. 将状态改为 PROCESSING
4. 提交事务
5. 发送 Kafka
6. 成功后改为 SENT
7. 失败后恢复为 PENDING 或改为 FAILED

也可以通过条件更新抢占任务：

UPDATE outbox_event
SET status = 'PROCESSING',
    updated_at = NOW()
WHERE id = ?
  AND status = 'PENDING';

只有受影响行数为 1 的实例才能继续处理。

但即便有任务抢占机制，仍然不能完全消除“发送成功但状态更新失败”带来的重复消息，所以消费者幂等依然不可省略。

二十三、失败重试不能无限立即执行

如果 Kafka 长时间不可用，发布器不能无间隔地重试。

可以使用指数退避：

第 1 次失败：10 秒后重试
第 2 次失败：30 秒后重试
第 3 次失败：1 分钟后重试
第 4 次失败：5 分钟后重试
第 5 次失败：30 分钟后重试

示例：

private Duration calculateBackoff(int retryCount) {
    long seconds = Math.min(
        1800,
        (long) Math.pow(2, retryCount) * 10
    );

    return Duration.ofSeconds(seconds);
}

超过最大重试次数后，可以将事件标记为：

FAILED

并触发告警或进入人工补偿流程。

二十四、Outbox 需要做好监控

Outbox 不只是增加一张表，还需要配套可观测性。

至少应监控以下指标：

outbox_pending_count
outbox_failed_count
outbox_publish_success_total
outbox_publish_failure_total
outbox_publish_latency
outbox_oldest_pending_age

其中非常关键的是：

最老一条 PENDING 事件已经积压了多久

因为即使待发送数量不多，也可能有某一条关键事件长期无法发送。

建议设置告警：

PENDING 数量超过阈值
FAILED 数量大于 0
最老待发送事件超过 5 分钟
连续发送失败率过高

二十五、什么时候不一定需要 Outbox？

并不是所有 Kafka 消息都必须使用 Outbox。

如果消息属于以下类型，可以根据业务容忍度简化：

日志消息；
非关键埋点；
用户行为分析；
可丢失的监控事件；
非关键缓存刷新通知；
可以通过定时任务重新计算的数据。

例如：

用户打开了某个页面

即使偶尔丢失一条埋点，通常不会破坏核心业务状态。

此时直接发送 Kafka，并结合 ACK 和重试，可能已经足够。

但如果消息承载的是关键业务事实，例如：

订单已创建；
支付已成功；
库存已锁定；
退款已完成；
账户余额已变更；
优惠券已核销；

那么消息丢失通常会造成严重的数据不一致。

这类场景更适合使用 Outbox。

二十六、什么时候应该优先使用 Outbox？

当系统同时满足以下条件时，应该认真考虑 Outbox：

1. 核心业务数据写入数据库
2. 数据变更后必须发布事件
3. 事件不能丢失
4. 数据库与 Kafka 不属于同一个事务资源
5. 可以接受最终一致性

典型场景包括：

订单创建 → 库存锁定
支付成功 → 订单状态更新
退款成功 → 账户余额恢复
用户注册 → 初始化用户权益
商品更新 → 搜索索引同步

这些场景的共同特点是：

消息不是附加通知，而是业务状态传播链路的一部分。

二十七、正确的系统设计应该是什么？

一个完整的可靠事件发布链路通常包括：

  graph TD
    A[业务本地事务] --> B[业务表 + Outbox 表原子写入]
    B --> C[Outbox Publisher 或 CDC]
    C --> D[Kafka ACK 确认]
    D --> E[失败重试]
    E --> F[Kafka 消费者]
    F --> G[消费者幂等处理]
    G --> H[成功后提交 Offset]

对应的可靠性机制如下：

数据库本地事务保证业务记录和事件记录不会分离
Outbox 保证消息发送失败后仍然能够重试
Kafka ACK 确认消息是否成功写入 Kafka
Producer Retry 处理临时网络和 Broker 故障
消费者幂等处理至少一次投递带来的重复消息
Offset Commit 控制消费者处理进度

缺少任何一个环节，都可能留下可靠性缺口。

二十八、总结

Kafka ACK 和 Outbox 的根本区别在于它们解决的问题不同。

Kafka ACK 解决的是：

消息有没有成功写入 Kafka

Outbox 解决的是：

数据库业务状态和待发布事件能否保持一致

Kafka ACK 无法替代 Outbox，原因包括：

Kafka ACK 无法控制数据库事务；
数据库提交和 Kafka ACK 是两个独立提交点；
两个提交点之间存在不可消除的故障窗口；
数据库提交后 Kafka 可能发送失败；
Kafka 发送成功后数据库可能回滚；
应用进程可能在任意中间状态崩溃；
Producer 收到超时时，消息结果甚至可能是不确定的。

Outbox 的核心价值是：

先用本地事务可靠记录业务事实，
再通过可重试机制把业务事实传播到 Kafka。

最终，一个可靠的事件驱动系统通常不是只依赖某一种机制，而是组合使用：

本地事务
+ Outbox
+ Kafka ACK
+ 失败重试
+ 消费者幂等
+ 可观测性

因此，面对“为什么 Kafka ACK 不能替代 Outbox”这个问题，最准确的回答是：

Kafka ACK 只能证明 Kafka 接收了消息，不能证明数据库事务和 Kafka 消息同时成功。Outbox 通过将业务数据和事件记录写入同一个本地事务，解决了数据库与消息系统之间的双写一致性问题。