51cto kafka优化 kafka 调优参数

转载

mob64ca14163a4f 2024-02-18 19:53:49

文章标签 51cto kafka优化 kafka batch 生产者数据 文章分类 架构后端开发

当我们谈论 Kafka 性能调优时，需要考虑很少的配置参数。因此，为了提高性能，最重要的配置是控制磁盘刷新速率的配置。

此外，我们可以根据组件划分这些配置。因此，让我们先谈谈Producer。因此，在生产者方面需要注意的最重要的配置是

Compression
Batch size
Sync or Async

而且，在消费者方面，重要的配置是

Fetch size

虽然，当我们考虑批处理大小时，总是会困惑多大batch size是最佳的。我们可以说，大批量大小可能是伟大的高吞吐量，它伴随着延迟问题。这意味着延迟和吞吐量成反比。

在高吞吐量的情况下，可以具有低延迟，为此我们必须为使用队列时间或刷新间隔选择适当的batch size，以找到所需的正确平衡。

51cto kafka优化 kafka 调优参数_生产者

3. 优化 Kafka 以实现最佳性能

更具体地说，调优涉及两个重要的指标：延迟度量值和吞吐量度量。延迟度量值是指处理一个事件需要多长时间，同样，在特定时间范围内到达的事件数量，即吞吐量度量值。因此，大多数系统都针对延迟或吞吐量进行了优化，而 Apache Kafka 则同时平衡了两者。此外，我们可以说，一个经过良好调整的 Kafka 系统只有足够的代理来处理主题吞吐量，因为接收信息时处理信息需要延迟。

a. 调整`kafka Producer`

正如我们知道的，Kafka使用异步发布/订阅模型。虽然我们的生产者调用 send（） 命令，但返回的结果是未来。将来提供的方法检查过程中信息的状态。此外，当批次准备就绪时，生产者会将其发送给Broker。基本上，Broker等待事件，然后，接收结果，并进一步响应事务已完成。

对于延迟和吞吐量，两个参数对于 Kafka 性能调整尤其重要

i. 批次大小
batch.size 以总字节为单位测量批处理大小，而不是消息数。这意味着在向 Kafka Broker发送消息之前，它控制要收集的数据字节数。因此，在不超出可用内存的情况下，请尽可能高地设置此内存。默认值为 16KB。

但是，如果我们增加缓冲区的大小，它可能永远不会充满。根据其他触发器（如以ms为单位的停留时间），生产者最终将发送信息。尽管通过将缓冲区批处理大小设置得过高，我们可能会影响内存使用，这不会影响延迟。

此外，如果我们的Producer一直发送，我们可能获得最好的吞吐量。此外，如果生产者经常闲置，我们可能无法编写足够的数据来保证当前的资源分配。

ii. Linger Time
为了在异步模式下缓冲数据，linger.ms设置最大时间。让我们用一个例子来理解它，一个设置为 100 批 100 毫秒的消息，要一次发送。在这里，缓冲会增加消息传递延迟，但这提高了吞吐量。

但是，默认情况下，生产者不会等待。因此，它发送缓冲区时，数据可用。

此外，我们可以将linger.ms = 5，并在一个批处理中发送更多消息，而不是立即发送。这样，发送的记录将最多增加 5 毫秒的延迟，但也会减少发送的请求数，即使系统中的负载不保证延迟。

因此，为了提高我们的生产商的延迟和更高的吞吐量，提高linger.ms。

b. 调整kafka Broker

正如我们知道的，主题被划分为分区。此外，每个分区都有一个leader,此外，使用多个副本时，大多数分区都写入了领导。然而，如果领导人不能适当平衡，那么与其他人相比，他们有可能过度劳累。
因此，根据我们的系统或数据的关键性，我们希望确保有足够的复制集来保存数据。建议从每个物理存储磁盘一个分区和每个分区一个使用者开始。

c. 调整Kafka消费者

基本上，Kafka 消费者可以创建吞吐量问题。主题的使用者数必须等于分区数。因为，要处理所有需要跟上生产者需要的消费者，我们需要足够的分区。

在同一使用者组中，使用者在它们之间拆分分区。因此，向组添加更多使用者可以提高性能，同时添加更多使用者组不会影响性能。

此外，我们使用 -replica.high.watermark.checkpoint.interval.ms的方式可能会影响吞吐量。此外，我们可以标记从分区读取信息时读取信息的最后一点。这样，我们有一个检查点，如果我们必须返回并查找丢失的数据，则无需重读先前数据即可从该检查点前进。因此，如果我们为每个事件设置检查点水印，我们永远不会丢失一条消息，但它会显著影响性能。此外，我们具有安全边际，对吞吐量的影响小得多，如果相反，我们设置它以检查每一百条消息的偏移量。

4. Kafka调优中的生产服务器配置

根据群集环境和计算机配置的可用性，以下是一些配置参数及其值，我们可以修改这些参数 |

a. num.replica.fetchers

此参数定义将将数据从leader复制到follwer的线程数。根据线程的可用性，我们可以修改此参数的值。如果我们有可用的线程，则使用副本提取器的数量以并行完成复制非常重要。

b. replica.fetch.max.bytes

此参数是有关我们希望从每个提取请求中的任何分区提取的数据量。增加此参数的值是件好事，这样有助于在关注者中快速创建副本。

c. replica.socket.receive.buffer.bytes

如果我们可用于创建副本的线程较少，我们可以增加缓冲区的大小。此外，如果复制线程与传入消息速率相比速度较慢，则有助于保存更多数据。

d. num.partitions 当卡夫卡在生活，我们应该照顾这个配置。我们可以具有并行级别并并行写入数据，这将自动增加吞吐量。
了解 Storm Kafka 与配置和代码集成
但是，如果系统配置无法处理，则增加分区数可能会降低我们的性能和吞吐量。基本上，如果系统没有足够的线程或只有单个磁盘，那么创建大量分区以提供更好的吞吐量是没有意义的。因此，我们可以说，为主题创建更多的分区直接取决于可用的线程和磁盘。

e. num.io.threads 基本上，我们群集中有多少磁盘，这决定了 I/O 线程的设置值。此外，服务器使用这些线程来执行请求。因此，许多线程必须依赖于磁盘的多个线程。