我正在考虑设置重试机制来覆盖网络信号，我认为如果重试机制覆盖几分钟，比如 2 到 5 分钟，就足以解决轻微的网络问题。
根据这个question的答案和文档，要设置的配置主要是retries、max.in.flight.requests.per.connection（建议kafka设置为1）、retry.backoff.ms和delivery.timeout.ms。
我担心将 max.in.flight.requests.per.connection 设置为 1 可能会影响性能？有人有这方面的经验吗？ kafka 生产者与代理集群的默认连接数是多少？我在网上找不到有关它的信息。
【问题讨论】：
标签： java apache-kafka kafka-producer-api
max.in.flight.requests.per.connection确实，这是关于生产者性能的最重要的配置参数之一，特别是生产者的吞吐量和延迟。此参数控制生产者在阻塞之前将发送到单个连接上的特定分区的最大未确认请求数。
换句话说，它将发送一个请求，并且在收到确认之前，它不会向代理发送另一个请求（针对该分区）。作为建议，如果您不要求对所有消息进行排序，请不要将此参数设置为 1。
关于retries 及其与此参数的链接：
允许重试而不设置 max.in.flight.requests.per.connection 为 1 可能会改变记录的顺序，因为如果两个 批次被发送到单个分区，第一个失败并且是 重试但第二次成功，则第二批中的记录 可能首先出现。
所以不是真的建议kafka设置为1；建议当您需要订购交货时。如果您不要求发生这种情况，请不要将 max.in.flight.requests.per.connection 设置为 1，因为您的生产者的吞吐量确实会降低。
在简历中：仅将其设置为一个如果您正在寻找事件的有序交付。
In this test，当将max.in.flight.requests 从 1 增加到 2 时，吞吐量和延迟显示出可观的改善。
acks这里还涉及另一个参数，以及您已经引用的那些，acks 集的数量。
例如，acks = 0 将使retries 和max.in.flight 参数完全不相关，因为生产者不会等待来自任何代理的任何确认，并且会假设每个请求都是成功。就像一个 UDP 发送者。
与acks=0:
1- retries 不生效，因为无法知道是否发生任何故障。
2- max.in.flight 不会生效，因为没有任何可能的未确认请求。
将 acks 设置为高于 0，例如，acks=2，也会对性能产生直接影响，因为要将请求识别为成功，必须从集群接收到 2 个acks .这意味着，例如，仅指定 1 个正在运行的请求的生产者的阻塞时间通常会增加，因为它必须在解除阻塞并能够发送下一个请求之前等待 2 个 ack 消息 对于那个分区。
Idempotence关于您的问题还有另一个概念，即幂等生产者。这可能是实现性能和效率之间平衡的最佳选择。
假设您设置了一些retries 以保证消息正确到达。代理收到消息，当它向您发送ack 时，网络错误使您的生产者无法接收它。如果设置了重试，producer 将再次发送相同的消息，在代理中创建 duplicate 消息。
Kafka 0.11.0 包括对幂等和事务性的支持 生产者的能力。 幂等交付确保 消息只传递一次到特定主题分区 在单个生产者的生命周期内
幂等生产者具有唯一的生产者 ID 并使用序列 ID 对于每条消息，允许代理确保它正在提交 以每个分区为基础的有序消息，没有重复。
这个幂等生产者，在较新版本的 Kafka 客户端中，默认为 5 max.in.flight.requests，从“旧”方式提高性能以确保交付顺序。这也是幂等生产者的最大值（从 1 到 5 是飞行中请求的有效范围），如果您需要有序、安全的管道，同时保持生产者的高性能，这是恢复的最佳选择。
幂等生产者引出了exactly once semantics 概念，在链接中进行了更深入的解释。
Design for max.in.flight > 1 with idempotence enabled在简历中，您应该判断您的用例的要求是什么。像这样的问题：
是否需要订购交货？
重复消息是否可以接受？
您是否重视吞吐量和延迟到某些消息丢失/无序可以接受的程度？
幂等生产者是否可以满足您的要求，以便在性能和消息排序/成功请求保证之间取得平衡？
This presentation 或多或少地恢复了这些配置对生产者端的影响，值得一看。
【讨论】：