Kafka核心技术与实战 10 压缩算法

（1）把消息的公共部分抽取出来放到外层集合里。

如：在V1中每条消息都要执行CRC校验（循环冗余校验），有些情况下消息的CRC值会变，对每条消息都执行CRC校验，不仅浪费空间还耽误CUP时间。

（2）报存压缩消息的方法发生了变化：

v1把多条消息进行压缩后在保存到外层消息的消息体字段中。

v2 对整个消息集合进行压缩，压缩效果好与前者。

3，何时压缩：

在kafka中可能发生压缩的地方：生产者端和Broker端

A：生产者端：配置compression.type参数即表示指定类型的压缩算法。

B：有两种情况会样Broker端也可能进行压缩

（1）：Broker端指定了和Producer端不同的压缩算法，这会导致Broker端接收到生产者发来的压缩消息，Broker端重新解压、在压缩。

（2）：Broker端发生了消息格式转换，这种转换主要是为了兼容老版本的消费者程序，（v1和v2的差别）。这个过程会涉及消息的解压和重新压缩。这不仅对性能影响很大，还会让Kafka丧失引以为豪的Zero Copy特性。

4，何时解压：

通常情况下解压发生在消费者端。

A：这个流程是Producer发送的压缩消息到Broker，Broker原封不动的保存起来，当Consumer程序请求这部分消息时，Broker原样发出去，当下消息到的Consumer端后，由Consumer自行解压。

B：Consume之所以知道这些消息是用何种压缩算法的，是因为Kafka会将启用了哪种压缩算法封装到消息集合中，当Consumer读取到消息集合时，就知道了。

5：压缩算法对比：

在Kafka2.1.0版本之前，仅支持GZIP，Snappy和LZ4。2.1.0后还支持Zstandard算法(Facebook开源，能够提供超高压缩比)。

A：一个压缩算法的优劣，有两个重要指标：压缩比和压缩/解压缩吞吐量，两者都是越高越好。

B：吞吐量：LZ4>Snappy>zstd和GZIP，压缩比：zstd>LZ4>GZIP>Snappy

6：最佳实践：

A：启用压缩的一个条件是Producer端所在机器CPU资源充裕

B：生产环境网络带宽资源有限

C：尽量不要出现消息格式转换的情况。

常见问题

• 如果多条消息组成消息集合发送，那是什么条件控制消息发送，如果是一条又是什么条件控制触发发送的呢

主要是这两个参数：batch.size和linger.ms。如果是生产了一条消息且linger.ms=0，通常producer就会立即发送者一条消息了。

• 消息（v1叫message，v2叫record）是分批次（batch）读写的，batch是kafka读写（网络传输和文件读写）的基本单位，不同版本，对相同（或者叫相似）的概念，叫法不一样。

v1（kafka 0.11.0之前）:message set, message

v2（kafka 0.11.0以后）:record batch,record

其中record batch对英语message set，record对应于message。

一个record batch（message set）可以包含多个record（message）。

总结

在这里，由于面试中MySQL问的比较多，因此也就在此以MySQL为例为大家总结分享。但是你要学习的往往不止这一点，还有一些主流框架的使用，Spring源码的学习，Mybatis源码的学习等等都是需要掌握的，我也把这些知识点都整理起来了

[外链图片转存中…(img-ga5jheh2-1725983858893)]

[外链图片转存中…(img-f8OWILhO-1725983858894)]