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中,不需要做任何配置即可正常读取并将这些消息转回文本。