Java on FelixHao's Blog

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 通过将业务数据和事件记录写入同一个本地事务，解决了数据库与消息系统之间的双写一致性问题。

Redis Sorted Set 的典型使用场景

Tue, 30 Jun 2026 16:31:57 +0800

一、Sorted Set 是什么？

Redis Sorted Set，也叫 ZSet，是一种有序集合数据结构。

它和普通 Set 一样，成员不能重复；但不同的是，Sorted Set 中的每个成员都会关联一个 score 分数，Redis 会根据 score 对成员进行排序。

Sorted Set 非常适合处理以下类型的数据：

排行榜
延时队列
滑动窗口限流
按时间范围清理数据
热门数据统计
权重排序
范围查询

基本结构可以理解为：

key -> [
  member1 -> score1,
  member2 -> score2,
  member3 -> score3
]

例如：

rank:user:score -> [
  user:1001 -> 95,
  user:1002 -> 88,
  user:1003 -> 76
]

二、常用命令

1. 添加元素：ZADD

ZADD key score member

示例：

ZADD rank:user:score 95 user:1001
ZADD rank:user:score 88 user:1002
ZADD rank:user:score 76 user:1003

一次添加多个：

ZADD rank:user:score 95 user:1001 88 user:1002 76 user:1003

2. 查询元素分数：ZSCORE

ZSCORE rank:user:score user:1001

3. 获取排名：ZRANK / ZREVRANK

ZRANK 按照分数从小到大排名：

ZRANK rank:user:score user:1001

ZREVRANK 按照分数从大到小排名：

ZREVRANK rank:user:score user:1001

排行榜场景通常使用 ZREVRANK。

4. 获取指定排名范围：ZRANGE / ZREVRANGE

按照分数从小到大获取：

ZRANGE rank:user:score 0 9 WITHSCORES

按照分数从大到小获取：

ZREVRANGE rank:user:score 0 9 WITHSCORES

5. 按分数范围查询：ZRANGEBYSCORE

ZRANGEBYSCORE rank:user:score 80 100 WITHSCORES

查询分数在 80 到 100 之间的用户。

6. 删除指定元素：ZREM

ZREM rank:user:score user:1003

7. 按分数范围删除：ZREMRANGEBYSCORE

ZREMRANGEBYSCORE rank:user:score 0 60

删除分数在 0 到 60 之间的元素。

三、典型使用场景

场景一：排行榜系统

排行榜是 Sorted Set 最典型的使用场景。

例如游戏积分榜、文章热度榜、用户贡献榜、商品销量榜等，都可以使用 Sorted Set 实现。

业务需求

假设我们要实现一个用户积分排行榜：

用户积分越高，排名越靠前
可以查询 Top N 用户
可以查询某个用户的排名
可以更新用户积分

Redis 数据结构设计

key: rank:user:score
member: userId
score: 用户积分

例如：

rank:user:score -> [
  1001 -> 950,
  1002 -> 880,
  1003 -> 760
]

Redis 操作示例

添加用户积分：

ZADD rank:user:score 950 1001
ZADD rank:user:score 880 1002
ZADD rank:user:score 760 1003

查询积分排行榜 Top 10：

ZREVRANGE rank:user:score 0 9 WITHSCORES

查询用户排名：

ZREVRANK rank:user:score 1001

注意：Redis 返回的排名从 0 开始，如果要展示给用户，需要 +1。

展示排名 = Redis排名 + 1

查询用户积分：

ZSCORE rank:user:score 1001

增加用户积分：

ZINCRBY rank:user:score 50 1001

删除用户：

ZREM rank:user:score 1003

Java 示例

使用 Spring Data Redis：

@Service
public class UserRankService {

    private static final String USER_SCORE_RANK_KEY = "rank:user:score";

    private final StringRedisTemplate stringRedisTemplate;

    public UserRankService(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    /**
     * 设置用户积分
     */
    public void setScore(Long userId, double score) {
        stringRedisTemplate.opsForZSet()
                .add(USER_SCORE_RANK_KEY, String.valueOf(userId), score);
    }

    /**
     * 增加用户积分
     */
    public void incrementScore(Long userId, double delta) {
        stringRedisTemplate.opsForZSet()
                .incrementScore(USER_SCORE_RANK_KEY, String.valueOf(userId), delta);
    }

    /**
     * 查询 Top N 用户
     */
    public Set<ZSetOperations.TypedTuple<String>> topN(int n) {
        return stringRedisTemplate.opsForZSet()
                .reverseRangeWithScores(USER_SCORE_RANK_KEY, 0, n - 1);
    }

    /**
     * 查询用户排名
     */
    public Long getRank(Long userId) {
        Long rank = stringRedisTemplate.opsForZSet()
                .reverseRank(USER_SCORE_RANK_KEY, String.valueOf(userId));

        if (rank == null) {
            return null;
        }

        return rank + 1;
    }

    /**
     * 查询用户积分
     */
    public Double getScore(Long userId) {
        return stringRedisTemplate.opsForZSet()
                .score(USER_SCORE_RANK_KEY, String.valueOf(userId));
    }
}

场景二：滑动窗口限流

Sorted Set 非常适合实现滑动窗口限流。

业务需求

假设接口要求：

同一个用户 60 秒内最多请求 100 次

可以使用当前时间戳作为 score，每次请求进来时：

删除窗口期之前的请求记录
统计当前窗口内的请求数量
判断是否超过限制
如果没有超过限制，则写入本次请求记录

Redis 数据结构设计

key: rate_limit:user:{userId}
member: requestId 或 timestamp + random
score: 当前请求时间戳

示例：

rate_limit:user:1001 -> [
  request:001 -> 1710000000000,
  request:002 -> 1710000000200,
  request:003 -> 1710000000500
]

Redis 操作示例

删除 60 秒之前的请求：

ZREMRANGEBYSCORE rate_limit:user:1001 0 1710000000000

统计当前窗口内请求数：

ZCARD rate_limit:user:1001

添加当前请求：

ZADD rate_limit:user:1001 1710000060000 request:1710000060000

设置过期时间：

EXPIRE rate_limit:user:1001 120

Java 示例

@Service
public class SlidingWindowRateLimiter {

    private final StringRedisTemplate stringRedisTemplate;

    public SlidingWindowRateLimiter(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    /**
     * 滑动窗口限流
     *
     * @param userId 用户 ID
     * @param windowSeconds 时间窗口，单位：秒
     * @param maxRequests 最大请求次数
     * @return 是否允许访问
     */
    public boolean isAllowed(Long userId, int windowSeconds, int maxRequests) {
        String key = "rate_limit:user:" + userId;

        long now = System.currentTimeMillis();
        long windowStart = now - windowSeconds * 1000L;

        ZSetOperations<String, String> zSetOps = stringRedisTemplate.opsForZSet();

        // 1. 删除窗口之前的请求记录
        zSetOps.removeRangeByScore(key, 0, windowStart);

        // 2. 统计当前窗口内的请求数
        Long count = zSetOps.zCard(key);

        if (count != null && count >= maxRequests) {
            return false;
        }

        // 3. 添加当前请求记录
        String requestId = now + ":" + UUID.randomUUID();
        zSetOps.add(key, requestId, now);

        // 4. 设置过期时间，避免 key 长期存在
        stringRedisTemplate.expire(key, Duration.ofSeconds(windowSeconds * 2L));

        return true;
    }
}

注意事项

上面的实现存在多个 Redis 操作，在高并发场景下可能会有并发问题。

生产环境中建议使用 Lua 脚本保证原子性。

Lua 脚本版本

local key = KEYS[1]
local now = tonumber(ARGV[1])
local window_start = tonumber(ARGV[2])
local max_requests = tonumber(ARGV[3])
local request_id = ARGV[4]
local expire_seconds = tonumber(ARGV[5])

redis.call('ZREMRANGEBYSCORE', key, 0, window_start)

local count = redis.call('ZCARD', key)

if count >= max_requests then
    return 0
end

redis.call('ZADD', key, now, request_id)
redis.call('EXPIRE', key, expire_seconds)

return 1

Java 调用示例：

@Service
public class LuaRateLimiter {

    private final StringRedisTemplate stringRedisTemplate;

    public LuaRateLimiter(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    public boolean isAllowed(Long userId, int windowSeconds, int maxRequests) {
        String key = "rate_limit:user:" + userId;

        long now = System.currentTimeMillis();
        long windowStart = now - windowSeconds * 1000L;

        String requestId = now + ":" + UUID.randomUUID();

        String luaScript = """
                local key = KEYS[1]
                local now = tonumber(ARGV[1])
                local window_start = tonumber(ARGV[2])
                local max_requests = tonumber(ARGV[3])
                local request_id = ARGV[4]
                local expire_seconds = tonumber(ARGV[5])

                redis.call('ZREMRANGEBYSCORE', key, 0, window_start)

                local count = redis.call('ZCARD', key)

                if count >= max_requests then
                    return 0
                end

                redis.call('ZADD', key, now, request_id)
                redis.call('EXPIRE', key, expire_seconds)

                return 1
                """;

        DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
        redisScript.setScriptText(luaScript);
        redisScript.setResultType(Long.class);

        Long result = stringRedisTemplate.execute(
                redisScript,
                List.of(key),
                String.valueOf(now),
                String.valueOf(windowStart),
                String.valueOf(maxRequests),
                requestId,
                String.valueOf(windowSeconds * 2L)
        );

        return result != null && result == 1L;
    }
}

场景三：延时队列

Sorted Set 也可以用来实现一个简单的延时队列。

业务需求

例如订单创建后，如果 30 分钟内未支付，需要自动关闭订单。

可以将任务的执行时间作为 score，将任务 ID 或任务内容作为 member。

消费者不断查询：

score <= 当前时间戳

的任务，然后执行任务。

Redis 数据结构设计

key: delay:queue:order
member: orderId
score: 任务执行时间戳

示例：

delay:queue:order -> [
  order:1001 -> 1710001800000,
  order:1002 -> 1710001900000
]

Redis 操作示例

添加延时任务：

ZADD delay:queue:order 1710001800000 order:1001

查询到期任务：

ZRANGEBYSCORE delay:queue:order 0 1710001800000 LIMIT 0 10

删除已处理任务：

ZREM delay:queue:order order:1001

Java 示例

@Service
public class DelayQueueService {

    private static final String ORDER_DELAY_QUEUE_KEY = "delay:queue:order";

    private final StringRedisTemplate stringRedisTemplate;

    public DelayQueueService(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    /**
     * 添加延时任务
     */
    public void addDelayTask(Long orderId, Duration delay) {
        long executeTime = System.currentTimeMillis() + delay.toMillis();

        stringRedisTemplate.opsForZSet()
                .add(ORDER_DELAY_QUEUE_KEY, String.valueOf(orderId), executeTime);
    }

    /**
     * 拉取到期任务
     */
    public Set<String> pollDueTasks(int limit) {
        long now = System.currentTimeMillis();

        return stringRedisTemplate.opsForZSet()
                .rangeByScore(ORDER_DELAY_QUEUE_KEY, 0, now, 0, limit);
    }

    /**
     * 删除任务
     */
    public void removeTask(Long orderId) {
        stringRedisTemplate.opsForZSet()
                .remove(ORDER_DELAY_QUEUE_KEY, String.valueOf(orderId));
    }
}

消费者示例：

@Component
public class OrderDelayTaskConsumer {

    private final DelayQueueService delayQueueService;
    private final OrderService orderService;

    public OrderDelayTaskConsumer(DelayQueueService delayQueueService,
                                  OrderService orderService) {
        this.delayQueueService = delayQueueService;
        this.orderService = orderService;
    }

    @Scheduled(fixedDelay = 1000)
    public void consume() {
        Set<String> orderIds = delayQueueService.pollDueTasks(10);

        if (orderIds == null || orderIds.isEmpty()) {
            return;
        }

        for (String orderId : orderIds) {
            boolean removed = removeTaskSafely(orderId);

            if (!removed) {
                continue;
            }

            orderService.closeOrderIfUnpaid(Long.valueOf(orderId));
        }
    }

    private boolean removeTaskSafely(String orderId) {
        // 简化示例，实际生产中建议使用 Lua 脚本实现“查询 + 删除”的原子性
        delayQueueService.removeTask(Long.valueOf(orderId));
        return true;
    }
}

更安全的 Lua 删除方式

为了避免多个消费者重复消费同一个任务，可以使用 Lua 脚本实现：

查询到期任务
删除该任务
返回任务 ID

local key = KEYS[1]
local now = tonumber(ARGV[1])
local limit = tonumber(ARGV[2])

local tasks = redis.call('ZRANGEBYSCORE', key, 0, now, 'LIMIT', 0, limit)

for i, task in ipairs(tasks) do
    redis.call('ZREM', key, task)
end

return tasks

场景四：清理历史数据或过期数据

Sorted Set 适合保存带有时间属性的数据，例如：

用户积分变更记录
用户搜索记录
用户浏览历史
接口访问日志
最近登录记录
最近操作记录

如果只想保留最近一段时间的数据，可以用时间戳作为 score，然后定期删除过期数据。

业务需求

例如保留用户最近 7 天的浏览记录。

Redis 数据结构设计

key: user:browse:history:{userId}
member: 商品 ID 或文章 ID
score: 浏览时间戳

示例：

user:browse:history:1001 -> [
  product:1 -> 1710000000000,
  product:2 -> 1710000100000,
  product:3 -> 1710000200000
]

Redis 操作示例

添加浏览记录：

ZADD user:browse:history:1001 1710000200000 product:3

删除 7 天前的数据：

ZREMRANGEBYSCORE user:browse:history:1001 0 1709395400000

查询最近浏览记录：

ZREVRANGE user:browse:history:1001 0 19 WITHSCORES

Java 示例

@Service
public class BrowseHistoryService {

    private final StringRedisTemplate stringRedisTemplate;

    public BrowseHistoryService(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    /**
     * 添加浏览记录
     */
    public void addBrowseRecord(Long userId, Long productId) {
        String key = "user:browse:history:" + userId;
        String member = "product:" + productId;

        long now = System.currentTimeMillis();

        stringRedisTemplate.opsForZSet().add(key, member, now);

        // 保留最近 7 天的数据
        long sevenDaysAgo = now - Duration.ofDays(7).toMillis();

        stringRedisTemplate.opsForZSet()
                .removeRangeByScore(key, 0, sevenDaysAgo);

        // 设置过期时间，避免冷数据长期占用内存
        stringRedisTemplate.expire(key, Duration.ofDays(8));
    }

    /**
     * 查询最近浏览记录
     */
    public Set<ZSetOperations.TypedTuple<String>> listRecentBrowseRecords(Long userId, int limit) {
        String key = "user:browse:history:" + userId;

        return stringRedisTemplate.opsForZSet()
                .reverseRangeWithScores(key, 0, limit - 1);
    }
}

场景五：热门内容统计

Sorted Set 可以用来统计文章、视频、帖子、商品等内容的热度。

业务需求

比如一个社区系统中，需要统计帖子热度：

浏览一次，加 1 分
点赞一次，加 5 分
评论一次，加 10 分
收藏一次，加 20 分

最后根据热度分数进行排序。

Redis 数据结构设计

key: hot:post:rank
member: postId
score: 热度分

Redis 操作示例

浏览加分：

ZINCRBY hot:post:rank 1 post:1001

点赞加分：

ZINCRBY hot:post:rank 5 post:1001

评论加分：

ZINCRBY hot:post:rank 10 post:1001

收藏加分：

ZINCRBY hot:post:rank 20 post:1001

查询热门帖子 Top 20：

ZREVRANGE hot:post:rank 0 19 WITHSCORES

Java 示例

@Service
public class PostHotRankService {

    private static final String HOT_POST_RANK_KEY = "hot:post:rank";

    private final StringRedisTemplate stringRedisTemplate;

    public PostHotRankService(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    public void increaseViewScore(Long postId) {
        incrementScore(postId, 1);
    }

    public void increaseLikeScore(Long postId) {
        incrementScore(postId, 5);
    }

    public void increaseCommentScore(Long postId) {
        incrementScore(postId, 10);
    }

    public void increaseFavoriteScore(Long postId) {
        incrementScore(postId, 20);
    }

    private void incrementScore(Long postId, double score) {
        stringRedisTemplate.opsForZSet()
                .incrementScore(HOT_POST_RANK_KEY, "post:" + postId, score);
    }

    public Set<ZSetOperations.TypedTuple<String>> listHotPosts(int limit) {
        return stringRedisTemplate.opsForZSet()
                .reverseRangeWithScores(HOT_POST_RANK_KEY, 0, limit - 1);
    }
}

场景六：最近联系人或最近会话列表

IM 系统、私信系统、客服系统中，经常需要展示最近会话列表。

Sorted Set 可以用来维护用户的最近会话。

业务需求

用户发送或接收消息后，将会话 ID 放入 Sorted Set，并使用最新消息时间作为 score。

这样查询最近会话时，只需要按照 score 倒序查询即可。

Redis 数据结构设计

key: user:recent:chat:{userId}
member: conversationId
score: 最新消息时间戳

示例：

user:recent:chat:1001 -> [
  conversation:2001 -> 1710000200000,
  conversation:2002 -> 1710000300000
]

Redis 操作示例

更新最近会话：

ZADD user:recent:chat:1001 1710000300000 conversation:2002

查询最近 20 个会话：

ZREVRANGE user:recent:chat:1001 0 19 WITHSCORES

删除某个会话：

ZREM user:recent:chat:1001 conversation:2002

Java 示例

@Service
public class RecentChatService {

    private final StringRedisTemplate stringRedisTemplate;

    public RecentChatService(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    /**
     * 更新最近会话
     */
    public void updateRecentChat(Long userId, Long conversationId) {
        String key = "user:recent:chat:" + userId;
        String member = "conversation:" + conversationId;

        long now = System.currentTimeMillis();

        stringRedisTemplate.opsForZSet()
                .add(key, member, now);
    }

    /**
     * 查询最近会话
     */
    public Set<ZSetOperations.TypedTuple<String>> listRecentChats(Long userId, int limit) {
        String key = "user:recent:chat:" + userId;

        return stringRedisTemplate.opsForZSet()
                .reverseRangeWithScores(key, 0, limit - 1);
    }

    /**
     * 删除会话
     */
    public void removeRecentChat(Long userId, Long conversationId) {
        String key = "user:recent:chat:" + userId;
        String member = "conversation:" + conversationId;

        stringRedisTemplate.opsForZSet()
                .remove(key, member);
    }
}

场景七：按权重排序的推荐列表

在推荐系统中，可以将推荐分数作为 score，将内容 ID 作为 member。

例如：

商品推荐
文章推荐
视频推荐
用户推荐
搜索结果排序

Redis 数据结构设计

key: recommend:user:{userId}
member: itemId
score: 推荐分数

示例：

recommend:user:1001 -> [
  item:1 -> 98.5,
  item:2 -> 87.2,
  item:3 -> 76.8
]

Redis 操作示例

写入推荐结果：

ZADD recommend:user:1001 98.5 item:1
ZADD recommend:user:1001 87.2 item:2
ZADD recommend:user:1001 76.8 item:3

查询推荐列表：

ZREVRANGE recommend:user:1001 0 9 WITHSCORES

移除低分推荐：

ZREMRANGEBYSCORE recommend:user:1001 0 60

Java 示例

@Service
public class RecommendService {

    private final StringRedisTemplate stringRedisTemplate;

    public RecommendService(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    /**
     * 添加推荐内容
     */
    public void addRecommendItem(Long userId, Long itemId, double score) {
        String key = "recommend:user:" + userId;
        String member = "item:" + itemId;

        stringRedisTemplate.opsForZSet()
                .add(key, member, score);
    }

    /**
     * 查询推荐内容
     */
    public Set<ZSetOperations.TypedTuple<String>> listRecommendItems(Long userId, int limit) {
        String key = "recommend:user:" + userId;

        return stringRedisTemplate.opsForZSet()
                .reverseRangeWithScores(key, 0, limit - 1);
    }

    /**
     * 移除低分推荐
     */
    public void removeLowScoreItems(Long userId, double minScore) {
        String key = "recommend:user:" + userId;

        stringRedisTemplate.opsForZSet()
                .removeRangeByScore(key, 0, minScore);
    }
}

场景八：签到记录

Sorted Set 也可以用来记录用户签到历史。

不过需要注意，如果只是判断某一天是否签到，Bitmap 可能更节省空间；如果需要按照时间范围查询签到记录，Sorted Set 会更灵活。

Redis 数据结构设计

key: user:checkin:{userId}
member: yyyy-MM-dd
score: 签到时间戳

示例：

user:checkin:1001 -> [
  2024-03-01 -> 1709222400000,
  2024-03-02 -> 1709308800000
]

Redis 操作示例

添加签到记录：

ZADD user:checkin:1001 1709222400000 2024-03-01

判断某天是否签到：

ZSCORE user:checkin:1001 2024-03-01

查询最近签到记录：

ZREVRANGE user:checkin:1001 0 6 WITHSCORES

删除 1 年前的签到记录：

ZREMRANGEBYSCORE user:checkin:1001 0 1677686400000

Java 示例

@Service
public class CheckInService {

    private final StringRedisTemplate stringRedisTemplate;

    public CheckInService(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    /**
     * 签到
     */
    public void checkIn(Long userId) {
        String key = "user:checkin:" + userId;

        LocalDate today = LocalDate.now();
        long now = System.currentTimeMillis();

        stringRedisTemplate.opsForZSet()
                .add(key, today.toString(), now);
    }

    /**
     * 判断某天是否签到
     */
    public boolean hasCheckIn(Long userId, LocalDate date) {
        String key = "user:checkin:" + userId;

        Double score = stringRedisTemplate.opsForZSet()
                .score(key, date.toString());

        return score != null;
    }

    /**
     * 查询最近签到记录
     */
    public Set<ZSetOperations.TypedTuple<String>> listRecentCheckIn(Long userId, int limit) {
        String key = "user:checkin:" + userId;

        return stringRedisTemplate.opsForZSet()
                .reverseRangeWithScores(key, 0, limit - 1);
    }
}

四、Sorted Set 使用建议

1. score 的设计非常重要

Sorted Set 的排序能力来自 score，所以设计 score 时要结合业务场景。

常见设计方式：

场景	score 设计
排行榜	积分、金额、数量
延时队列	执行时间戳
滑动窗口限流	请求时间戳
浏览历史	浏览时间戳
热门内容	热度分
推荐系统	推荐分数
最近会话	最新消息时间戳

2. member 要保证唯一性

Sorted Set 中的 member 是唯一的。

如果重复添加同一个 member，Redis 不会新增一条记录，而是更新它的 score。

例如：

ZADD rank:user:score 100 user:1001
ZADD rank:user:score 200 user:1001

最终只有一条记录：

user:1001 -> 200

如果需要记录多次请求、多次操作、多次事件，member 需要设计成唯一值。

例如滑动窗口限流中，不建议直接用时间戳作为 member，因为同一毫秒内可能有多个请求。

推荐写法：

String requestId = now + ":" + UUID.randomUUID();

3. 注意控制集合大小

Sorted Set 数据量过大会占用较多内存。

对于时间窗口、历史记录、浏览记录这类数据，建议定期清理。

例如：

ZREMRANGEBYSCORE user:browse:history:1001 0 1709395400000

也可以只保留最近 N 条：

ZREMRANGEBYRANK user:browse:history:1001 0 -101

这条命令的含义是：只保留分数最高的 100 条记录，删除其余更老的数据。

4. 高并发场景下使用 Lua 脚本保证原子性

如果一个业务逻辑需要多个 Redis 命令组合完成，就要考虑并发问题。

例如滑动窗口限流：

删除过期请求 -> 统计当前请求数 -> 写入当前请求

这三个操作如果不是原子的，在高并发下可能会导致限流不准确。

推荐使用 Lua 脚本：

redis.call('ZREMRANGEBYSCORE', key, 0, window_start)
local count = redis.call('ZCARD', key)
if count >= max_requests then
    return 0
end
redis.call('ZADD', key, now, request_id)
return 1

5. 根据访问模式设计 key

常见 key 设计：

rank:user:score
rate_limit:user:{userId}
delay:queue:order
user:browse:history:{userId}
hot:post:rank
user:recent:chat:{userId}
recommend:user:{userId}
user:checkin:{userId}

设计 key 时建议遵循：

业务名:模块名:维度:{id}

例如：

user:browse:history:1001
post:hot:rank
rate_limit:user:1001

五、Sorted Set 与其他 Redis 数据结构的选择

需求	推荐数据结构	原因
只需要去重	Set	更简单
需要排序	Sorted Set	支持 score 排序
需要排行榜	Sorted Set	天然支持排名
需要时间范围查询	Sorted Set	时间戳可作为 score
需要简单队列	List	操作简单
需要延时队列	Sorted Set	执行时间可作为 score
需要计数器	String	使用 INCR 即可
需要签到压缩存储	Bitmap	空间更省
需要字段对象	Hash	适合对象结构

六、总结

Redis Sorted Set 的核心能力是：

唯一 member + 可排序 score

它适合所有需要“排序”“排名”“范围查询”“按时间清理”的业务场景。

典型场景包括：

排行榜
滑动窗口限流
延时队列
历史数据清理
热门内容统计
最近会话列表
推荐列表
签到记录

在实际开发中，Sorted Set 最常见的两类 score 设计是：

1. 使用业务分数作为 score：排行榜、热度榜、推荐排序
2. 使用时间戳作为 score：限流、延时队列、历史记录、最近会话

如果业务中存在以下需求，就可以优先考虑 Sorted Set：

需要排序
需要排名
需要按分数范围查询
需要按时间范围查询
需要清理过期数据
需要查询 Top N 数据

Sorted Set 是 Redis 中非常实用的数据结构，掌握它可以很好地解决很多高频业务问题。

Java on FelixHao's Blog

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

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

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

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

3. 应用在临界点崩溃

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

三、Outbox Pattern 是什么

四、Outbox Pattern 的整体流程

五、Outbox 表设计

1. event_id

2. aggregate_type 和 aggregate_id

3. event_type

4. payload

六、Spring Boot 中实现 Outbox Pattern

1. 订单实体

2. Outbox 事件实体

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

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

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

1. 轮询方案的优点

2. 轮询方案的缺点

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

1. 使用 SKIP LOCKED

2. 使用抢占式更新

3. PROCESSING 状态需要超时恢复

十、CDC 是什么

常见 CDC 工具

十一、CDC 与 Outbox Pattern 的关系

十二、基于 Debezium 的 Outbox 架构

CDC 方案的优点

CDC 方案的缺点

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

十四、什么是幂等消费

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

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

消费代码示例

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

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

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

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

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

状态机方案的注意事项

十九、方案四：乐观锁

二十、方案五：Redis 去重

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

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

二十三、消息顺序问题

1. 使用相同的消息 Key

2. 增加 aggregate_version

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

二十四、消息版本兼容

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

二十六、Outbox 数据清理

二十七、消费记录表清理

二十八、监控指标

Outbox 指标

CDC 指标

消费者指标

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

1. 生产端事务

2. CDC 读取 Outbox

3. 消费端幂等处理

三十、常见错误设计

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

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

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

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

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

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

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

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

适合使用轮询的场景

适合使用 CDC 的场景

推荐演进路线

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

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

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

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

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