Apache Kafka(六)- High Throughput Producer

泄露秘密 提交于 2019-11-28 19:27:54

High Throughput Producer

在有大量消息需要发送的情况下,默认的Kafka Producer配置可能无法达到一个可观的的吞吐。在这种情况下,我们可以考虑调整两个方面,以提高Producer 的吞吐。分别为消息压缩(message compression),以及消息批量发送(batching)。

 

1. Message Compression

Producer一般发送的数据都是文本数据,例如JSON ,但是这类数据的问题在于:数据量会较大,消耗较多的传输带宽。这种情况下,有必要对Producer的数据进行压缩。

  • 数据压缩可以仅在Producer level完成即可,并不需要任何Broker或Consumer端的配置更改
  • 控制压缩的参数为 compression.type,可选值为 none(默认),gzip,lz4,snappy
  • 发送给Kafka的消息的数据量越大,使用Compression的收益也就越大
  • 有博主针对压缩性能进行过测试,详细内容可以参考以下文档:https://blog.cloudflare.com/squeezing-the-firehose/

 

一般Producer在向kafka传输消息时会用到Producer Batch,将多条消息以一个batch的方式传输。对一个batch的消息进行压缩,然后传输给Kafka,会大大减少消息的传输、使用的网络带宽,以及减少latency:

 

总的来说,使用compressed batch的好处有:

  • 更小的producer request size(压缩比率最高可以达 4x)
  • 使用更少的网络带宽 => 也就是更小的延迟
  • 更高的吞吐
  • 在Kafka端更优的磁盘使用率(存储在磁盘上的消息数据量会更小)

同时也会有缺点:

  • Producers需要一些CPU资源用于压缩
  • Consumers也需要一些CPU资源用于解压缩

 

一般场景下,可以尝试使用 snappy 或是 lz4 作为压缩算法,它们有较好的速度以及压缩率。其他算法例如gzip,压缩率较高,但是速度较慢。对于各类不同的压缩算法,一般都是在压缩率与解压缩(以及压缩)速度这两者间做权衡,可根据实际场景进一步做测试并选择适用的压缩算法。最好的方式是:对应用场景下的数据,比较所有的压缩算法的性能,从中选出最优的压缩算法,再应用到生产。

在一个应用场景下,若是需要达到一个较高的吞吐,压缩是必须要考虑在内的。另一方面,我们也要考虑message batch。通过调整linger.ms 以及 batch.size 控制batch的大小,结合压缩,使应用达到更高的吞吐 。

 

2. Producer Batching

在默认情况下,Kafka Producer会尝试尽可能的发送records。之前我们介绍过一个参数max.in.flight.requests.per.connection,它表示的含义是:

  • 最多同时会有5个in flight 连接,也就是说在同一时刻,最多仅有5条message会相互独立地发送
  • 在这之后,如果有更多的messages需要被发送,而其他的连接均为in flight。则Kafka会开始将这些消息batching,并进行等待。直到返回了一个ack后,kafka会将这些消息一次性传输出去。更重要的是:此次传输仅为Producer的一个request

显而易见,batching可以让Kafka增大throughput,同时保有较低的延时。此功能也不需要做任何特殊配置,Kafka默认会使用此机制传输消息。另一方面,Batches可以有更高的压缩率,并因此达到更高的效率。

控制batch行为的参数有两个,分别为linger.ms、batch.size。

首先介绍linger.ms:

  • Linger.ms:在发送一个batch出去前,一个Producer等待的毫秒数。默认为0,也就是说Kafka会立即发送一个batch
  • 若是引入一些延迟(例如linger.ms=5),则消息以batch形式被发送的概率会增加
  • 所以在引入了一点延迟成本后,我们可以增加producer的吞吐以及压缩性能,让producer更高效
  • 如果一个batch在linger.ms时间到达之前就满了(由batch.size控制),则这个batch会被立即发送到Kafka。所以不需要担心过长的等待时间。

 

 

 

 

 

 

 

 

然后是batch.size:

  • batch.size:在一个batch中,最多能容纳的字节数。默认为16KB
  • 在大多数情况下,增加此参数到32KB或64KB可以有效提高压缩、吞吐、以及请求的性能
  • 任何超过此batch size大小的消息不会被batch
  • batch的分配基于partition数目,所以确保不要设置太高的值,以防止使用过多内存
  • 我们可以使用Kafka Producer Metrics监控average batch size 指标

 

3. High Throughput Producer 示例

基于之前的Java例子,我们会继续添加snappy 压缩算法到我们的producer中。对于基于文本的数据(例如日志文件或是JSON文件)来说,snappy在CPU与压缩率之间有均有权衡,相对来说是一个较好的压缩算法选择。我们也会将batch.size 增加到 32KB,并通过linger.ms 引入一个较小的延时(20ms)。

配置参数如下:

// high throughput producer at the expense of a lit bit latency and CPU usage
properties.setProperty(ProducerConfig.COMPRESSION_TYPE_CONFIG, "snappy");
properties.setProperty(ProducerConfig.LINGER_MS_CONFIG, "20");
properties.setProperty(ProducerConfig.BATCH_SIZE_CONFIG, Integer.toString(32*1024)); // 32 KB batch size

 

在配置以上参数后,发送给Kafka的消息即为压缩后的消息。不过在Consumer中,不需要做任何配置即可正常读取并将这些消息转回文本。

 

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!