Kafka 重试配置和性能影响

如何解决Kafka 重试配置和性能影响

我正在考虑设置重试机制来解决网络故障，我认为如果重试机制涵盖几分钟，比如 2-5 分钟，那对于轻微的网络问题就足够了。 根据对此 question 和文档的回答，要设置的配置主要是 retries、max.in.flight.requests.per.connection（建议 kafka 设置为 1）、retry.backoff.ms 和 { {1}}。

我担心将 delivery.timeout.ms 设置为 1 可能会影响性能吗？任何人都有这方面的经验？ kafka 生产者与代理集群的默认连接数是多少？我在网上找不到相关信息。

解决方法

max.in.flight.requests.per.connection

事实上，这是关于生产者性能的最重要的配置参数之一，特别是生产者的吞吐量和延迟。此参数控制在阻塞之前，生产者将在单个连接上向特定分区发送的未确认请求的最大数量。

换句话说，它将发送单个请求，并且在收到确认之前，它不会向代理发送另一个请求（针对该分区）。作为建议，如果您不需要对所有消息进行排序，请不要将此参数设置为 1。

关于 retries 及其与此参数的链接：

允许重试而不设置 max.in.flight.requests.per.connection to 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 将再次发送相同的消息，在代理中创建一个重复消息。

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 或多或少恢复了这些配置对生产者方面的影响，值得一看。