这完全是合理的情况，不用怀疑自己的操作——虽然直觉上acks=-1（等待所有同步副本确认）应该比acks=0（不等待任何确认）慢，但你的参数组合刚好触发了一系列让acks=-1更高效的机制，我来逐个拆解：

1. LZ4压缩与大批次的协同放大效应 #

你设置了batch.size=2000000（2MB）和compression.type=lz4，这两个参数是核心关键：

• 当使用acks=-1时，生产者在等待Broker副本确认的间隙，有足够的时间积累更多消息，把批次填到接近设定的batch.size上限。大批次的500字节消息重复度高，经过LZ4压缩后能最大化消除冗余数据，压缩比会显著提升，最终传输的数据量被大幅压缩。
• 而acks=0时，生产者无需等待确认，会更“急于”发送消息，可能批次还没填满就被触发发送（比如达到默认的linger.ms时间，或消息数量触发阈值）。小批次的压缩比极低，导致每次网络传输的有效数据占比下降，同时高频次的小请求会让Broker的连接、磁盘IO调度等开销占比升高，反而拉低了整体吞吐量。

2. max.in.flight.requests.per.connection=1的反向作用 #

这个参数限制了每个连接最多同时存在1个未完成的请求：

• 在acks=0场景下，虽然生产者可以连续发送请求，但因为批次小，每个请求携带的数据量有限，高频次的小请求反而让网络带宽和Broker资源没有被充分利用。
• 在acks=-1场景下，虽然需要等待确认，但每个请求都是填满的大批次，单次传输的数据量足够大，即使请求频率低，整体的有效数据传输量反而更高，完全抵消了等待确认的延迟。

3. Kafka 1.1.0的版本特性加持 #

Kafka 1.1.0针对生产者和副本同步做了不少针对性优化：

• 副本之间的同步流程更高效，acks=-1时Broker返回确认的延迟比旧版本更低；
• 生产者的批次管理逻辑更智能，在等待确认时能更高效地积累新消息，不会因为等待而阻塞消息的收集。

验证建议 #

如果想验证这个逻辑，可以尝试把batch.size调小（比如设置为100000即100KB），再对比acks=0和acks=-1的吞吐量。此时因为批次太小，压缩收益可以忽略，acks=0的吞吐量应该会回到比acks=-1更高的预期状态，这也能反向证明之前的结论。

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