Kafka 客户端的最佳实践

制作人可用性

• 设置retries为指示生产者在代理故障转移期间重试发送失败的消息。对于大多数用例，我们建议使用整数最大值或类似的高值。不这样做将破坏 Kafka 的高可用性。

• 设置delivery.timeout.ms为指定从发送消息到收到代理确认之间的总时间上限。这应反映消息有效期的业务要求。将时间限制设置得足够高，以允许足够的重试次数来完成故障转移操作。对于大多数用例，我们建议将值设置为 60 秒或更高。

• 设置request.timeout.ms为尝试重新发送之前单个请求应等待的最大值。对于大多数用例，我们建议将值设置为 10 秒或更高。

• 设置retry.backoff.ms为配置重试之间的延迟，以避免重试风暴和对可用性的影响。对于大多数用例，我们建议最小值为 200 毫秒。

• 设置acks=all为配置高耐久性；这应与服务器端的配置一致，RF=3并min.isr=2确保中的所有分区都ISR确认写入。也就是说，在单个经纪商离线期间min.isr，这是2。

消费者可用性

• 对于新的或重新创建的消费者组，auto.offset.reset将其设置为 “latest初始值”。这样可以避免因占用整个主题而增加集群负载的风险。

• 使用auto.commit.interval.ms时设置enable.auto.commit。我们建议大多数用例的最小值为 5 秒，以避免额外负载的风险。

• 在消费者的消息处理代码中实现异常处理，以处理瞬态错误，例如断路器或带指数退缩的睡眠。不这样做可能会导致应用程序崩溃，从而导致过度重新平衡。

• 设置isolation.level为控制交易消息的读取方式：

  默认情况下，我们建议始终read_uncommitted隐式设置。某些客户端实现中缺少此功能。

  使用分层存储read_uncommitted时，我们建议使用值。

• 设置client.rack为使用最近的副本读取。我们建议将设置为，az id 以最大限度地减少网络流量成本和延迟。请参阅通过机架感知降低您的 Amazon MSK 消费者的网络流量成本。

消费者再平衡

• 设置session.timeout.ms为大于应用程序启动时间的值，包括实现的任何启动抖动。对于大多数用例，我们建议将值设置为 60 秒。

• 设置heartbeat.interval.ms为微调小组协调员如何看待消费者是健康的。对于大多数用例，我们建议将值设置为 10 秒。

• 在应用程序中设置关机挂钩以干净地关闭使用者SIGTERM，而不是依靠会话超时来识别消费者何时离开群组。Kstream 应用程序可以internal.leave.group.on.close将值设置为。true

• 设置group.instance.id为消费者组内的不同值。理想情况下，是主机名、任务 ID 或 pod ID。我们建议在故障排除期间始终将其设置为更具确定性的行为和更好的客户端/服务器日志关联。

• 设置group.initial.rebalance.delay.ms为与平均部署时间一致的值。这可以阻止部署期间的持续再平衡。

• 设置partition.assignment.strategy为使用粘性赋值器。我们建议使用StickyAssignor或CooperativeStickyAssignor。

制作人表演

• 设置linger.ms为控制制作人等待批次填充的时间。对于 Kafka 来说，较小的批处理会消耗大量的计算成本，因为它们可以同时转化为更多的线程和 I/O 操作。我们建议使用以下值。

  包括低延迟在内的所有用例的最小值均为 5 毫秒。

  对于大多数用例，我们建议将更高的值设置为 25 毫秒。

  我们建议不要在低延迟用例中使用零值。（无论是因为 IO 开销的原因，零值通常都会导致延迟）。

• 设置为控制发送batch.size到集群的批次大小。我们建议将其增加到 64KB 或 128KB 的值。

• buffer.memory在使用较大的批量大小时进行设置。对于大多数用例，我们建议将值设置为 64MB。

• 设置send.buffer.bytes为控制用于接收字节的TCP缓冲区。我们建议将值设置为 -1，以便操作系统在高延迟网络上运行生产者时管理此缓冲区。

• 设置 compression.type 以控制批次的压缩。我们建议 lz4 或 zstd 在高延迟网络上运行生产者。

消费者表现

• 设置fetch.min.bytes为控制有效的最小提取大小，以减少提取次数和集群负载。

  对于所有用例，我们建议最小值为 32 字节。

  对于大多数用例，我们建议使用更高的值 128 字节。

• 设置 fetch.max.wait.ms 以确定在忽略 fetch.min.bytes 之前，你的消费者需要等待多长时间。对于大多数用例，我们建议将值设置为 1000 毫秒。

• 我们建议使用者的数量至少等于分区的数量。

• 设置receive.buffer.bytes为控制用于接收字节的TCP缓冲区。我们建议将值设置为 -1，以便操作系统在高延迟网络上运行消费者时管理此缓冲区。

客户端连接

在 Kafka 集群上，连接生命周期会产生计算和内存成本。一次创建的连接过多会导致负载，从而影响 Kafka 集群的可用性。这种可用性影响通常会导致应用程序创建更多的连接，从而导致级联故障，从而导致完全中断。如果以合理的速度创建，则可以实现大量连接。

我们建议采取以下缓解措施来管理高连接创建率：

• 确保您的应用程序部署机制不会同时重启所有生产者/使用者，而最好是小批量重启。

• 在应用程序层，开发人员应确保在创建管理员客户端、生产者客户端或使用者客户端之前执行随机抖动（随机休眠）。

• 在关闭连接时SIGTERM，应执行随机休眠以确保并非所有 Kafka 客户端同时关闭。随机睡眠应在SIGKILL发生前的超时时间内。

  例 示例 A (Java)

  sleepInSeconds(randomNumberBetweenOneAndX);
                          this.kafkaProducer = new KafkaProducer<>(this.props);

  例 示例 B (Java)

  Runtime.getRuntime().addShutdownHook(new Thread(() -> {
      sleepInSeconds(randomNumberBetweenOneAndTwentyFive);
      kafkaProducer.close(Duration.ofSeconds(5));
  });

• 在应用程序层，开发人员应确保每个应用程序只以单例模式创建一次客户端。例如，使用 lambda 时，客户端应在全局范围内创建，而不是在方法处理程序中创建。

• 我们建议监控连接数，以保持稳定为目标。在部署和代理故障转移期间，连接creation/close/shift正常。

制作人指标

• 字节速率

• record-send-rate

• records-per-request-avg

• acks-latency-avg

• request-latency-avg

• request-latency-max

• record-error-rate

• record-retry-rate

• 错误率

消费者指标

• records-consumed-rate

• bytes-consumed-rate

• 获取速率

• records-lag-max

• record-error-rate

• fetch-error-rate

• 民意调查率

• rebalance-latency-avg

• 承诺率

通用指标

• connection-close-rate

• connection-creation-rate

• 连接次数