kafka异步发送中的确认模式有什么影响？

Question

当我们使用异步调用发送消息时，确认模式（“0”、“1”、“all”）是否有任何影响send()？

我尝试测量发送调用延迟（即通过记录调用send()方法之前和之后的时间）并观察到 ​​(异步发送，acks=1) 和 (异步发送，acks=all) 花费相同的时间。

然而，吞吐量数字存在明显差异。

producer.send(record, new ProducerCallback(record));

acks=all我认为即使在异步模式下使用时发送调用也会被阻塞。有人可以解释一下确认模式（“0”、“1”、“全部”）在异步模式下如何工作吗？

Answer 1

根据文档：

public Future send(ProducerRecord记录，Callback回调)

将记录异步发送到主题，并在确认发送后调用提供的回调。发送是异步的 ，一旦记录已存储在等待发送的记录缓冲区中，此方法将立即返回。这允许并行发送许多记录，而不会在每条记录之后阻塞等待响应。

因此，有一件事可以肯定，异步“发送”并不真正关心“acks”配置是什么。它所做的就是将消息推送到缓冲区中。一旦此缓冲区开始处理（由 linger.ms 和 batch.size 属性控制），就会检查“acks”。

如果 acks=0 -> 直接触发并忘记。制作人不会等待确认。

如果 acks=1-> 当消息成功写入领导者时，代理会发送确认。

如果 acks=all -> 当消息成功写入所有副本时，代理会发送确认。

在 1 和 all 的情况下，这将成为阻塞调用，因为生产者将等待确认，但是，您可能不会注意到这一点，因为它发生在并行线程上。在 acks=all 的情况下，预计 ack 到达的时间会比 acks=1 的时间稍长（网络延迟和副本数量是明显的原因）。

此外，您应该在异步生产者中配置“重试”属性，以便如果确认失败（由于任何原因，例如数据包损坏/丢失），生产者知道应该再次尝试发送消息多少次（增加交货保证）。

最后：“但是，吞吐量数字存在明显差异。” -- 这是事实，因为从代理到生产者线程存在确认延迟。

希望有帮助！:)