文章目录
- Kafka消息压缩
- Kafka消息格式
Kafka消息压缩
Kafka 支持的压缩算法还挺多的，一般支持GZIP、Snappy、LZ4等压缩算法，具体是通过compression.type 来开启消息压缩并且设定具体的压缩算法。
props.put(“compressions.type”, “GZIP”);压缩算法是要占用挺大一部分cpu资源的并且耗时也是不小的，而压缩的目的很大程度上是为了提升网络传输的性能，毕竟小点传得快嘛。但是整个压缩的过程也是很耗时的，通常来说KafkaProducer.send( )主要时间其实都花在在压缩操作上，如果压缩的过程十分漫长，那么压缩就显得有点多余了，所以选择一个高性能的压缩算法是十分关键的。而且就现状来说对于Kafka这种消息系统瓶颈往往不是CPU，通常来说都是受网络带宽。
何时产生压缩:
- 生产者
为了数据在传输到 Kafka 可以更快，那么在生产者启动压缩自然是很正常的。 - Broker端
Broker 主要是负责储存数据，压缩能够很好的减少磁盘的占用。
一般情况而言，如果数据已经在生产者端压缩了，那么其实就不需要在Broker端再做处理，实际上也确实是这样，但是如果发生以下这些情况，那么Broker端会再进行压缩，这样无疑会导致性能问题，所以应该尽量避免：
- Broker端指定了和Producer端不同的压缩算法
这很好理解，因为压缩算法不一致，Broker 就需要解压缩，并在此压缩成设定好的算法，所以一定要避免这种情况。 - Broker端发生了消息格式转换。
这里所谓的消息格式转换，是因为在Kafka更新的过程中，进行了一次消息格式的修改，如果生产者 和 Kafka 集群版本的消息格式不一致，那么 Broker端为了兼容考虑，会将 生产者的消息格式修改为当前版本的消息格式，而转换消息格式是必然涉及 解压缩 和 重压缩的，
何时解压缩:
- Consumer端
消费数据自然需要将数据解压缩，这个没什么好说的。 - Broker端
这里可能你要奇怪了，为什么Broker端还要解压缩呢？
实际上Broker端只是为了进行消息的校检，以保证数据的正确性，这样必然会给Broker端的性能带来一定的影响，但是就目前来说，好像也没什么好的解决办法。
Kafka消息格式
使用Kafka是应该用怎样的消息格式才是最优？
决定我们使用何种消息格式考虑的因素有两种，一个是方便，一个效率。
就方便来说其实就是数据的转换（或者Mapping），效率包括时间和空间两个维度，当然能压缩最小无论是空间还是时间都是良好的选择。所以不同的场景应该有不同的最优，Kafka提供了String和Byte数组两种选择，分别为：
org.apache.kafka.common.serialization.ByteArraySerializerorg.apache.kafka.common.serialization.StringSerializer
使用前者时可以使用官方推荐的Avro，或者自定义的序列化Bean。
后者主要是简单消息或者JSON，还有XML（比较少用）。
原则1:
如果一句话能说清楚，当然用String。
JSON是最常用的消息，因为它足够灵活，又没有XML那么罗嗦，而且支持的语言又多，几乎是计算机行业的自然语言了。所以采用JSON在数据转换方面的工作量肯定是比较小的。
原则2:
当我们的数据格式固定时，应该避免直接JSON，可以考虑使用Avro。
用String的劣势就是由于它每条记录都需要Key，所以在大数据时，其实它有大量的数据冗余（和二维表比较，二维表只有一行是Name），另外一方面的劣势就是它不够明白，需要额外的文档来说明每一个字段。还有就是在操作的时候，其实是大量的String截取操作，也不经济。使用Kafka的时候，如果我们要保留大量数据，存储是一个要考虑的重要因素。
