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

Question

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

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

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

acks=all

我认为，即使在异步模式下，使用producer.send(record, new ProducerCallback(record)); 也会阻止发送呼叫。有人可以解释确认模式（“ 0”，“ 1”，“全部”）在异步模式下如何工作吗？

Answer 1

根据docs：

  

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

     

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

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

如果acks = 0->射击并忘记。生产者不会等待确认。

如果acks = 1->成功在领导者上写消息后，代理将发送确认。

如果acks = all->在所有副本上成功写入消息后，代理将发送确认。

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

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

最后：“但是，吞吐量数字有明显的区别。” -的确如此，因为从代理到生产者线程的确认延迟。

希望有帮助！ ：）