- kafka消息压缩官方说明
- Compression
- Design
- Offset management on the consumer
- Backwards compatibility
- Configuration changes
- Compression codecs supported
原文地址:https://cwiki.apache.org/confluence/display/KAFKA/Compression
Compression该特性引入了 Kafka 中端到端的块压缩特性。 如果启用,数据将由生产者压缩,以压缩格式写入服务器并由消费者解压缩。 压缩会以一定的解压成本提高消费者吞吐量。 这在跨数据中心镜像数据时特别有用。
Design一组消息可以被压缩并表示为一个压缩消息。 从这个意义上说,消息根据定义是递归的。 ByteBufferMessageSet 可以包含未压缩和压缩的数据。 因此,我们需要某种方式从未压缩的消息中识别压缩消息。 为了识别压缩消息,我们在消息头中引入了一个压缩属性字节。 在消息头中增加一个字节表示网络字节格式以及存储字节格式的变化。 这种消息头部格式化为 magic 字节值 1。
magic byte=1 的消息头格式,现在看起来像 -
1 byte magic1 byte compression-attributes4 byte CRC32 of the payload属性字节中的最低 2 位将选择用于压缩数据的压缩编解码器。 压缩编解码器值为 0 表示未压缩消息。
Offset management on the consumer消费者收到的主题数据可能包含压缩消息和未压缩消息。 消费者迭代器透明地解压压缩数据,只返回未压缩的消息。 消费者中的偏移量维护变得有点棘手。 在zookeeper消费者中,每次返回消息时都会更新消耗的偏移量。 这个消耗的偏移量应该是正确的故障恢复的有效获取偏移量。 由于数据以压缩格式存储在代理上,因此有效的提取偏移量是压缩消息边界。 因此,对于压缩数据,消耗的偏移量将一次增加一条压缩消息。 如果消费者失败,这会产生可能重复的副作用。 对于未压缩的数据,消耗的偏移量将一次增加一条消息。
Backwards compatibility0.7 版本的代理和消费者将能够理解幻字节值 0 和 1 的消息。因此代理和消费者向后兼容。
Configuration changes生产者方面有 2 个新的配置参数 -
配置参数备注默认值compressed.topicscomma separated list of topics for which compression should be enabled. This doesn’t mean anything when compression.codec = 0emptycompression.codecControls the compression codec to be used by the producer. (0: No compression, 1: GZIP compression, 2: Snappy compression, 3: LZ4 compression)0 compression.topics=emptycompression.topics=“topicA,topicB”compression.codec=0All topics are uncompressed since compression is disabledAll topics are uncompressed since compression is disabledcompression.codec=1All topics are compressedOnly the topics topicA and topicB are compressed Compression codecs supported目前,仅支持 GZIP、Snappy 和 LZ4 压缩编解码器。