Kafka 如何保证消息顺序？

先说结论

Kafka 的顺序保证边界是单个分区。同一业务实体的事件使用稳定 Key 进入同一分区，生产端保持兼容的幂等与重试配置，消费端对该分区按 offset 顺序处理，才能形成局部有序链路。

全 Topic 全局有序通常只能使用单分区，会牺牲吞吐和扩展性，业务更应明确真正需要排序的实体范围。

相同 Key 由分区器稳定路由，但增加分区数会改变哈希映射，扩容期间同一 Key 可能进入不同分区。可使用固定路由策略、版本化 Topic 或在消费者按业务版本校验。

Kafka 保证的是“同一个分区中，Leader 追加的记录有确定 offset 顺序”。要把它扩展成业务实体顺序，需要同时满足：同一实体稳定映射到同一分区、生产端不把同一实体的事件并发乱发、消费者不打破分区内处理顺序、失败重试不让旧事件覆盖新状态。

订单 1001：CREATED -> PAID -> SHIPPED
      使用 key=1001 -> 同一分区 -> offset 10/11/12

不同订单不需要互相有序，才能通过多个分区并行处理。若业务真的要求全局序列，例如全局账本号，通常应由专门的序列化服务或单分区边界承载，并接受吞吐限制。

网络异常时生产者重试可能让前一批还未确认、后一批先到达，从而出现重排风险。幂等生产者和正确的 in-flight 配置可在单会话单分区内帮助保持顺序；具体参数要使用匹配的客户端版本，不能只单独修改某一个值。应用层也应按实体顺序发出事件，不能在多个线程无序构造同一订单的状态变更。

for (ConsumerRecord<String, Event> record : records) {
    executor.submit(() -> process(record));
}

这会让同一分区相邻 offset 在不同线程完成，业务副作用很容易乱序，且不能简单提交最高拉取位点。可选方案是每分区串行处理、按 key 哈希到固定 worker 并跟踪连续完成 offset，或把事件转换成带版本的状态机更新。方案越并行，位点管理越复杂。

即便传输顺序正确，事件可能来自多个 Topic、历史回放、数据库 CDC、跨区域复制或人工补偿，业务仍会看到乱序。事件应带实体 ID、单调版本或发生序号，消费者只接受“期望下一版本”或版本更高的状态；遇到缺口可短暂缓冲、回查事实源、延迟重试或跳过并告警。

不能只用事件时间排序，分布式时钟和网络延迟无法保证因果关系。业务版本才是更可靠的顺序依据。

增加分区可以提高新消息并行度，却会让默认 hash 分区规则重新映射。强依赖每个 key 历史顺序的 Topic，应提前预留分区、用一致性映射、创建新版本 Topic 并迁移，或让消费者按版本做防御。扩容是架构事件，不是无副作用的调参。

同一分区内若把消息无约束提交到并行线程，完成顺序仍会打乱。可按业务 Key 分发到固定工作队列，或串行处理分区并通过增加分区扩展总吞吐；位点提交要跟随连续完成边界。

消息按发送时间排序不等于业务因果顺序，不同服务的时钟与网络延迟都不可靠。即使传输有序，失败重试和业务幂等也可能导致旧事件再次出现。

事件携带实体版本号，消费者只接受预期新版本，对缺口进行短暂缓冲、重试或回查；策略取决于允许等待多久和能否跳过缺失版本。

在同组同一时刻，一个分区只分配给一个 consumer 实例；但应用内部若再异步拆分，就可能打破顺序。需要把线程模型也纳入保证条件。

可能。失败消息进入重试 Topic 后再回来，原分区后续消息可能已处理。应根据实体版本、暂停分区、按 key 串行或补偿状态机选择策略。

这样所有消息进入一个分区，顺序最强但吞吐和可用性都被单分区限制，通常只适用于极低流量或真正全局顺序的场景。