5月28日 08:24

Kafka 如何保证消息的顺序性？

Kafka 在 Partition 级别保证消息顺序，不保证 Topic 级别的全局顺序

Kafka 的顺序性保证是面试高频考点。核心结论：Kafka 只在同一个 Partition 内保证消息的写入和消费顺序一致，跨 Partition 没有顺序保证。 如果业务需要严格顺序，必须把相关消息路由到同一个 Partition。

一、Partition 内为什么有序

每个 Partition 本质上是一个追加写入的日志（append-only log），每条消息分配一个单调递增的 offset。Consumer 按 offset 顺序拉取，因此分区内天然有序。

java
// Producer 发送时指定 Key，相同 Key 的消息进入同一 Partition
ProducerRecord<String, String> record = new ProducerRecord<>(
    "order-topic",
    orderId,       // Key — 决定分区路由
    orderEvent     // Value
);
producer.send(record);

Kafka 默认分区策略：有 Key 则 hash(key) % numPartitions，无 Key 则轮询（round-robin）或粘性分区。

二、跨 Partition 为什么无序

一个 Topic 通常有多个 Partition，不同 Partition 的消息并行写入和消费，无法保证先后关系。

示例：订单创建消息进入 Partition-0，支付消息进入 Partition-1，Consumer 可能先读到支付消息。

shell
Partition-0: [订单创建] [发货通知]
Partition-1: [支付成功] [签收确认]
       ↓ 并行消费，顺序不可控

三、如何保证业务上的顺序性

方法 1：用相同的 Key 路由到同一 Partition（最常用）

java
// 同一订单的所有事件使用 orderId 作为 Key
producer.send(new ProducerRecord<>("order-topic", orderId, event));

优点：简单、无需额外代码；缺点：同一 Key 的消息无法并行处理，可能成为热点。

方法 2：自定义分区器

java
public class OrderPartitioner implements Partitioner {
    @Override
    public int partition(String topic, Object key, byte[] keyBytes,
                         Object value, byte[] valueBytes, Cluster cluster) {
        // 按业务规则路由：如按用户ID所在区域分区
        String userId = (String) key;
        int regionCode = getUserIdRegion(userId);
        return regionCode % cluster.partitionCountForTopic(topic);
    }
}

配置方式：

properties
partitioner.class=com.example.OrderPartitioner

方法 3：单分区 Topic

bash
# 创建只有一个 Partition 的 Topic
kafka-topics.sh --create --topic strict-order-topic \
  --partitions 1 --replication-factor 3

全局有序但吞吐极低，仅适用于顺序性要求极严且流量小的场景。

四、容易踩的坑

1. Producer 端重试导致乱序

Producer 开启重试（retries > 0）时，如果 max.in.flight.requests.per.connection > 1，第一批消息失败重试后可能排在第二批后面，造成乱序。

properties
# 严格顺序场景下必须这样配置
retries=2147483647
max.in.flight.requests.per.connection=1
enable.idempotence=true

开启幂等（enable.idempotence=true）后，Kafka 2.0+ 可以在 max.in.flight.requests.per.connection <= 5 的情况下保证分区内顺序，因为 Broker 端会按序列号去重排序。

2. Consumer Rebalance 导致重复消费

Rebalance 发生时，Consumer 可能重复消费已处理的消息。如果业务处理非幂等，就会出现数据不一致。解决方案：消费端做好幂等（数据库唯一键、Redis 去重表等）。

3. 多线程消费打乱顺序

java
// 错误：多线程处理同一 Partition 的消息会乱序
while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
    for (ConsumerRecord<String, String> record : records) {
        executor.submit(() -> process(record)); // 顺序无法保证
    }
}

正确做法：按 Key hash 到同一线程处理，保证同 Key 消息的顺序。

java
// 按 Key 分配到固定线程
int threadIndex = Math.abs(record.key().hashCode()) % threadCount;
executors[threadIndex].submit(() -> process(record));

五、性能与顺序的取舍

方案	顺序性	吞吐量	适用场景
单 Partition	全局有序	低	账户流水、状态机
Key 路由同 Partition	Key 维度有序	中	订单状态、用户事件
多 Partition 无 Key	无序	高	日志采集、指标上报

大多数业务只需要同一业务实体维度有序（如同订单、同用户），通过合理设置 Key 即可兼顾顺序与性能。

追问

Q: Kafka 能否做到全局有序？为什么不用？ 技术上可以——单分区 + 单 Producer + 单 Consumer。但吞吐量受限于单机，无法水平扩展，只适合流量极低的场景（如金融账户变更日志）。

Q: enable.idempotence 具体怎么保证顺序的？ Producer 为每个 <PID, Partition> 维护递增的 Sequence Number，Broker 端按 SN 排序写入。即使请求乱序到达，Broker 也会按 SN 重排后再落盘，保证日志中消息有序。

Q: 消费端如何保证 Exactly-Once 语义？ Kafka 提供 Consumer 端的 exactly-once 需要配合事务：将消费和写入放在同一个 Kafka 事务中，或者使用幂等 + 手动提交 offset + 业务去重表的组合方案。

标签：Kafka