Kafka保障消息有序场景下哪种生产者配置组合性能更优

在可接受消息重复但必须严格保障消息顺序的业务场景下，enable.idempotence = true + max.in.flight.requests.per.connection = 5的配置组合实际运行性能远高于关闭幂等性+在途请求数为1的配置，是生产环境的优先选择。

两种配置均能满足严格消息顺序的要求，具体配置如下：

• 配置1（高性能方案）

enable.idempotence = true
max.in.flight.requests.per.connection = 5

• 配置2（低性能串行方案）

enable.idempotence = false
max.in.flight.requests.per.connection = 1

配置2的性能瓶颈非常明显 #

max.in.flight.requests.per.connection=1本质是强制生产者串行发送消息：同一时间连接上只能有1个未收到Broker确认的请求，必须等前一批消息完全收到ACK之后，才能发送下一批。这种模式下网络往返的等待时间会被完全浪费，哪怕带宽很充足，吞吐量也会被网络延迟卡得非常低，跨可用区、跨机房部署的场景下性能损失会被放大数倍。

配置1的性能收益远大于额外开销 #

1. 幂等性带来的性能损耗几乎可以忽略：幂等性的实现逻辑非常轻量，只是生产者给每个发往分区的消息批次附加一个单调递增的序列号，Broker端在内存里做简单的序列号校验去重，整个过程没有额外的磁盘IO，CPU开销占比通常不到1%，完全感知不到。
2. 5个在途请求的管道化发送收益极高：允许同时存在5个未确认的请求后，生产者不用等待前序请求的ACK返回就可以持续发下一批消息，能把网络带宽充分利用起来，这部分带来的吞吐量提升是数倍到十倍级别的，完全覆盖幂等性的微小开销。

在常规的Kafka 2.0+版本（目前绝大多数生产环境的使用版本）下，同硬件、同网络、同消息大小的压测场景中：

• 配置1的吞吐量通常是配置2的3~10倍，消息发送的平均延迟、P99延迟都比配置2更低
• 配置1还额外提供了消息不重复的能力，哪怕业务可以接受重复，这个附加能力也不会带来额外负担

注意：如果使用Kafka 1.x及更早的版本，开启幂等性时需要把max.in.flight.requests.per.connection设为1才能保证重试时不乱序，就没有这个性能优势了，但这类过老的版本目前已经极少在生产环境使用。

内容的提问来源于stack exchange，提问作者YFl