最近公司日志Kafka集群出现性能瓶颈。当单个节点还没有达到60W/tps时，发送消息有很大的延迟，甚至超过10s。截图如下：虽然使用的是机械盘，但是这一点压力对Kafka来说应该是小菜一碟的事实在我心里敲响了警钟，需要对其进行诊断。通过监控平台观察Kafka集群中的相关监控节点，发现cpu使用率只有接近20%，磁盘IO等待等指标也没有异常，请问是什么问题呢？平时CPU消耗的时间不多，但是性能却明显下降了。我们先查看kafka节点的线程栈。获取线程栈的方法比较简单。命令是：ps-ef|grepkafka//获取pidjstackpid>j1.log我们可以通过上面的命令获取kafka进程的栈信息，通过查看线程名中包含kafka-request-handler字样的线程（在Kafka中处理请求)，发现大量锁等待。具体截图如下：并且在jstack文件中发现了很多线程。等待这个锁，截图如下：我们先根据线程栈查看代码，找到对应的源码如下图：通过阅读源码，这段代码是为了partitionleader保证写入分区时数据的完整性。,锁定分区，即如果收到多个针对同一个分区的写请求，这些请求将被串行执行。这个锁是必须的，不能优化，但是仔细观察线程的调用栈，发现在GZIPInputstream中出现了锁的代码块，进行了zip压缩。一个压缩在锁中，它的执行性能注定是低的。什么时候需要在服务器端进行压缩？那么我们继续看LogValidator的validateMessagesAndAssignOffsets方法，最后调用validateMessagesAndAssignOffsetsCompressed方法，部分代码截图如下：这段代码的注释部分详细介绍了kafka需要在服务端进行压缩的四种情况side，它的翻译其实是两种情况：client-side和server-sidecompressionalgorithmsInconsistency客户端和服务端的消息版本格式不一样，包括offset的表示方式和压缩处理方式。客户端和服务端的压缩算法不一致。这种情况基本不会发生，因为服务器通常可以支持多种压缩算法。根据客户端的压缩算法自动匹配。最有可能是服务端和客户端的消息协议版本不一致。如果版本不一致，需要重新偏移服务器。如果使用压缩机制，需要重新解压，然后计算位置，再进行压缩存储，性能消耗很大。查看日志用户端，确实是客户端版本和服务端版本不一致导致的，最后需要客户端统一升级。
