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

Question

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

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

但是，吞吐量数字存在明显差异。

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

我认为即使在异步模式下使用acks=all，发送调用也会被阻止。有人能解释一下确认模式（'0','1','all'）在异步模式下是如何工作的吗？

Answer 1

根据docs：

公共未来发送（ProducerRecord记录， 回调回调）

异步发送一条记录到一个主题并调用提供的 确认发送后的回调。发送是异步的 该方法将在记录完成后立即返回 存储在等待发送的记录缓冲区中。这允许 并行发送许多记录而不阻塞等待 每一条都回复。

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

如果 acks=0 -> 开火然后忘记。生产者不会等待确认。

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

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

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

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

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

希望对您有所帮助！ :)