在Kafka中，当开启重试机制（retries > 0）且允许并发发送时，确实极易产生乱序问题。

乱序产生的原因：假设Producer并发发送了消息A和消息B到同一个Partition。消息A因为网络抖动发送失败，而消息B发送成功。随后Producer对消息A进行重试并成功。此时，Partition中保存的顺序就变成了 B -> A，打破了原有的绝对保序要求。

为了在并发发送且开启重试的场景下保证单Partition绝对保序，可以通过以下两种维度的方案来解决：

---

方案一：开启 Producer 的幂等性（推荐，现代 Kafka 标准做法）

从 Kafka 0.11 版本开始引入了幂等性（Idempotence）机制。这不仅能解决重复发送的问题，还能完美解决开启重试后的乱序问题，同时不影响并发吞吐量。

1. 配置方法

在 Producer 端进行如下配置：

• enable.idempotence = true （开启幂等性。注意：Kafka 3.0 及以上版本默认已开启）。
• acks = all （或 -1，开启幂等性必须设置为 all）。
• max.in.flight.requests.per.connection <= 5 （必须小于等于5，通常建议保持默认值 5）。
• retries > 0 （开启重试，建议设为 Integer.MAX_VALUE，交由 delivery.timeout.ms 控制总时长）。

2. 底层保序原理

开启幂等性后，Kafka 会为每个 Producer 分配一个唯一的 PID（Producer ID），并为发送到特定 Partition 的每条消息分配一个单调递增的 Sequence Number（序列号）。

• Broker 端会在内存中维护每个 <PID, Partition> 的最新序列号。
• 如果 Broker 收到的消息序列号不等于 期望的序列号（即当前最大序列号 + 1），Broker 会拒绝该消息。
• 场景推演：消息A（Seq=1）和消息B（Seq=2）并发发送。A失败，B到达Broker。Broker期望收到 Seq=1，但收到了 Seq=2（消息B），因此会将B暂存在内存（或抛出 OutOfOrderSequenceException 让 Producer 重试 B）。当 A 重试成功（Seq=1被接受）后，B（Seq=2）才会被成功追加。从而在保证并发（in.flight > 1）的同时，实现了绝对保序。

---

方案二：限制单连接的并发请求数（传统做法，牺牲吞吐量）

如果你的 Kafka 版本非常老（0.11 之前），或者出于某些特殊原因无法开启幂等性，只能通过限制并发来保序。

1. 配置方法

• max.in.flight.requests.per.connection = 1
• retries > 0

2. 原理与代价

• 原理：这个参数控制 Producer 和 Broker 建立的单个 TCP 连接上，最多允许几个未收到响应（unacknowledged）的请求。设为 1 意味着，在消息A收到 Broker 的成功响应之前，消息B根本不会被发送出去。如果 A 失败，Producer 会一直重试 A，直到成功后才发送 B。
• 代价：严重降低吞吐量。Producer 退化成了同步发送模式，无法利用网络流水线（Pipeline）优势。

---

⚠️ 极易被忽视的业务层（应用端）乱序陷阱

仅仅配置 Kafka Producer 是不够的。“绝对保序”最大的敌人往往在调用 kafkaProducer.send() 之前的业务代码里。

如果你在业务端使用了多线程来构建消息并调用 send() 方法，那么在进入 Kafka Producer 的缓冲区之前，消息的顺序可能就已经乱了。

应用层的保序要求：

1. 单线程发送：对于同一个 Partition 的消息，必须由同一个业务线程顺序调用 producer.send()。
2. 异步回调处理：由于 send() 是异步的，如果在回调函数（Callback）中处理失败逻辑（而不是靠 Kafka 内部的 retries），极易引发乱序。必须完全依赖 Kafka 自身的 retries 机制，业务代码不要手动重试。
3. 如果业务必须多线程处理：需要在业务层做“基于 Partition Key 的哈希分发”，将属于同一个 Partition 的消息丢入同一个内存队列，由单一的消费者线程去调用 Kafka 的 send()。

总结建议

为了实现单Partition绝对保序 + 开启重试 + 并发发送：

1. 业务代码：确保属于同一 Partition 的消息由单线程严格按顺序调用 send()。
2. Producer 配置：
   • enable.idempotence=true
   • acks=all
   • max.in.flight.requests.per.connection=5
   • retries=2147483647 (或足够大的数)
3. Consumer 提示：消费端也必须单线程顺序消费该 Partition，或者在拉取到消息后，根据 Key 进行本地 Hash 投递给不同的线程处理，否则消费端的多线程依然会导致处理乱序。