Kafka 只能保证“分区内顺序”（Partition-level ordering）， 不能保证：
- 全局顺序
- 跨分区顺序
- 多消费者之间的顺序
原因：Kafka 的核心并发单位是 分区（Partition），每个分区内部日志是追加写的天然有序结构。
面试官想听到的第一句话： Kafka 的消息顺序保证是：单个分区内严格有序，分区之间无序。
因为每个 Partition 在磁盘上就是一条 append-only log：
offset: 0 → 1 → 2 → 3 → ...
生产者写入和 broker 执行顺序都是物理追加，所以天然有序。
消费者读取 Partition 时只能顺序读取 offset，因此消费顺序就是写入顺序。
这是面试官经常追问的重点。
多个 partition 会被多个 consumer 并发消费，顺序必然被打乱。
Kafka Consumer Group 中：
- 一个分区最多只能被一个 consumer 消费
- 但如果你人为绕过 consumer group，用多线程乱读 offset，也会乱序。
如果消费者使用异步提交并有失败重试，可能重复消费某些消息，也可能跳过部分消费顺序。
即便 partition 顺序正确，消费者内部若多线程异步处理，也很容易耗时不同导致乱序。
面试官想听“方法 + 原理 + 适用场景”，下面按场景分级：
最简单、最可靠的保证顺序方法
缺点：吞吐量受限（Kafka 的高并发来自多分区）。 适合场景：
- 订单状态流转
- 物流轨迹
- 支付状态
- 用户行为按用户顺序处理
例如：
partition = hash(order_id) % N
partition = hash(user_id) % N
这样保证：
- 同一个订单的消息必然落在同一个分区
- 同一个用户的行为按顺序消费
- 整体仍然可以水平扩展分区数量
是大多数互联网公司最常用的做法。
即便一个 partition 对应一个 consumer，但 consumer 内部不能用异步线程并发处理，否则顺序又会乱。
策略：
- Consumer 内部使用同步处理模型（单线程消费）
- 或者同 key 的消息放入同一个处理队列（disruptor/ring buffer）
如果顺序极其重要，可以使用：
- 幂等写模型（更新操作冪等，顺序无关）
- 通过版本号判断先后（事件时间戳、逻辑版本）
- 重放日志确保最终一致顺序
适合多业务源事件交错场景，例如电商交易流水。
这是 Kafka 设计理念：
-
高吞吐来自多分区并行处理
-
如果保证全局顺序，那只能：
- 单分区
- 单 broker
- 单 consumer → Kafka 立即退化为一个普通队列
-
Kafka 的目标是：
- 分布式
- 高吞吐
- 可水平扩展 → 必须牺牲全局顺序
因此 Kafka 做出的选择是： 保证分区有序，而分区数量由业务控制。
Kafka 的消息顺序保证是：单分区内严格有序。
因为每个分区是追加写日志，消费者按 offset 顺序读取。
如果需要业务顺序，可以通过“按 key 分区”把同一业务实体路由到同一分区。
想要全局顺序，就只能用单分区，但会损失吞吐。
实际落地通常用：按 order_id / user_id 分区 + 单线程消费保持顺序。