不同 acks=0,1,-1 的生产者吞吐量答案

【问题标题】：Producer throughput with varying acks=0,1,-1不同 acks=0,1,-1 的生产者吞吐量
【发布时间】：2021-07-18 20:21:53
【问题描述】：

我一直在为我的项目使用 kafka 集群进行一些性能测试。我对发送调用和生产者的“acks”属性有疑问。我观察到下面的数字与下面的发送调用调用。这是一个简单的火灾和忘记呼叫。

producer.send(record); // fire and forget call

该主题有 5 个分区，我看到下面的结果具有不同的 ack 值和复制因子。 kafka 集群有 5 个节点以默认值运行并使用本地磁盘

acks             Replication factor=1              Replication factor=3
0                  1330k msgs/sec                    1260k msgs/sec
1                  1220k msgs/sec                    1200k msgs/sec
-1(all)            1220k msgs/sec                    325k msgs/sec

正如您所见，随着 acks 值从 0 变为 all，生产者吞吐量降低。我无法理解的是，如果生产者发送调用本质上是触发并忘记（见上文）并且生产者不等待任何确认，那么为什么生产者吞吐量会随着我们转向更强的确认保证而下降？

任何关于 Acks 和生产者发送调用如何在 Kakfa 内部工作的见解将不胜感激。

附：我曾在 kafka 用户邮件列表上问过这个问题，但没有得到回复，所以在 SO 上问这个问题。

【问题讨论】：

标签： java apache-kafka kafka-producer-api

【解决方案1】：

您在send 方法中没有回调这一事实并不意味着它在底层级别上是一劳永逸的。您已经为生产者配置了 3 个不同级别的 ack，它们决定了“即发即弃”状态。 acks = 0 表示生产者发送消息但不等待代理的任何确认；这是真正的“一劳永逸”。如您所见，它提供了更高的吞吐量。当 acks = 1 时，生产者等待 ack。此 ack 由代理（生产者连接到该代理并托管领导者副本）发送。当然，这不是“一劳永逸”。当 acks = -1 时，生产者等待 ack。如上所述，此 ack 由代理发送，但仅在将消息复制到其他代理上的所有副本追随者之后。当然，在这种情况下，如果您增加复制因子，吞吐量会降低，因为在“领导者”代理将 ack 返回给生产者之前，消息需要被更多代理（min.insync.replicas）复制。请注意，在复制因子 = 1 时，ack = 1 和 ack = -1 具有相同的吞吐量，因为只有一个副本（领导者），因此无需复制到跟随者。

【讨论】：

我也不明白。 send 方法 javadocs 说“异步向主题发送记录...”，它如何在内部等待以支持 acks=all 保证？
生产者作为内部缓冲区，因为发送消息是批量发送的。当经过特定时间 (linger.ms) 或达到特定大小 (batch.size) 时，发送具有更多消息的批次。从客户端的角度来看，它始终是异步的，因为消息只是进入将发送消息的生产者缓冲区。
@ppatierno 我认为您的回答不正确，因为问题是关于吞吐量而不是延迟，请参阅我的回答

【解决方案2】：

这是关于 kafka 如何处理生产请求的内容。首先，KafkaProducer.send 默认是异步的。 KafkaProducer 已经承担了大量工作来批量处理您的生产请求并将其发送给代理。代理将响应产生响应，这反过来又需要等待来自远程关注者的 min.insync.replicas。就是这个原因。

【讨论】：

如果 send 调用是异步的并立即返回，那么 acks 如何影响它？如果生产者等待响应，那么它是如何异步的？

【解决方案3】：

我认为接受的答案是错误的，因为问题是关于吞吐量而不是延迟，并且根据融合书 Kafka: the definitive guide ：

如果我们的客户端代码等待来自服务器的回复（通过调用发送消息时返回的 Future 对象的 get() 方法）它显然会显着增加延迟（至少通过网络往返）。如果客户端使用回调，延迟将被隐藏，但吞吐量将受到飞行中消息数量的限制（即，生产者在收到回复之前将发送多少条消息服务器）。

因此，如果使用 acks=1,all 的异步生产者，则吞吐量取决于 max.in.flight.requests.per.connection ：客户端将发送的未确认请求的最大数量阻塞前的单连接

【讨论】：