Kafka 消息压缩
Kafka中的消息压缩
正如我们所见，生产者以文本格式向 Kafka 发送数据，通常称为 JSON 格式。 JSON 有一个缺点，即数据是以字符串形式存储的。这会创建多个重复记录以存储在 Kafka 主题中。因此，它占用大量磁盘空间。因此，需要减少磁盘空间。这可以通过在将数据发送到 Kafka 之前压缩或延迟数据来完成。
需要消息压缩
可能有以下原因可以更好地描述需要减小消息大小:
它将减少将数据发送到 Kafka 所需的延迟和大小。
它会减少带宽，从而使用户增加发送到代理的网络消息。
通过云平台将数据存储在 Kafka 中可以降低成本。这是因为云服务是付费的。因此，它计算存储在 Kafka 中的数据量。
消息压缩不需要对代理和消费者的配置进行任何更改。
消息压缩不需要对代理和消费者的配置进行任何更改。
减少的磁盘负载将导致快速的读写操作。
Producer Batch/Record Batch
生产者将消息一条一条地写入Kafka。因此，卡夫卡玩得很聪明。它等待正在向 Kafka 生成的消息。然后，它创建一个批处理并将消息放入其中，直到它变满。然后，将批处理发送到 Kafka。这种类型的批次称为生产者批次。默认批量大小为 16KB，最大值可以是任何大小。大的是批量大小，更多的是生产者请求的压缩、吞吐量和效率。
注意: 消息大小不应超过批处理大小。否则，消息将不会被批处理。此外，批处理是按分区分配的，因此不要将其设置为非常高的数字。
较大的是生产者批次，有效使用消息压缩技术。
消息压缩格式
消息压缩是始终在生产者端完成，因此不需要更改消费者或代理端的配置。
图中创建了一个200MB的生产者批次。压缩后，它减少到 101 MB。
为了压缩数据，使用了"compression.type"。这让用户可以决定压缩的类型。类型可以是"gzip"、"snappy"、"lz4"或"none"(默认)。 'gzip'具有最大压缩率。
消息压缩的缺点
消息压缩有以下缺点:
生产者提交一些 CPU 周期以进行压缩。
消费者提交一些 CPU 周期用于解压。
这些缺点会导致 CPU 使用率增加。
因此，消息压缩是减少磁盘负载的更好选择。
