kafka业务侧使用了与服务端版本不一致的客户端，并且开启了数据压缩带来的问题

数据压缩是kafka解决空间问题和超大数据问题关键场景，例如：当kafka的磁盘空间不足时，可以使用数据压缩，来节省磁盘空间的使用。当生产端需要向kafka集群发送大量的超大数据（大于1M的数据）时可以通过开启压缩模式来减少传输过程中带来的网络消耗。

压缩模式开启有一定的要求，为什么会这样，先看kafka压缩的原理：

Kafka服务端使用的topic最终压缩模式（由compression.type决定）为producer。

这也就意味着，开启压缩后存在kafka中的数据类型其实本质就是一个压缩包。如下图：

     图：客户端与kafka服务端版本一致的存储方式

如果客户端与kafka服务端版本不一致会怎样？再看下面的图。

                                             图：客户端与kafka服务端版本不一致的存储方式

客户端使用的kafka-client-xxxx.jar版本要与服务端的版本不一致时，在kafka的服务端会出现，对数据的“解压缩，再压缩”的过程。这个流程会非常损耗CPU，并且可能会造成kafka的GC超时从而导致kafka集群性能下降。

排查方式：

1. 如果节点CPU使用率超过80%，或者有kafka的GC时间超过阈值的告警。或者查看异常的broker节点的监控曲线：

如果这个节点的GC时间长时间达到了秒级，说明GC不正常。

1. 给kafka进程打一个jstack，如果jstack中出现gzip, snappy,lz4,zstd，说明有开启压缩，例如开启了GZIP。

解决方案：

1. 建议客户升级客户端，保持和服务端一致
2. 使用低版本客户端时，禁用压缩