背景
ckafka消费慢是用户经常遇到的问题，消费慢直接体现为消息堆积数上升，消息堆积数上升意味这消费者没有及时消费到消息，依赖消费者的下游应用就可能堵塞。因此，在观测到ckafka消费慢后及时进行有效排查、定位问题，用于降低消费慢对业务的影响，是很有必要的。
与自建kafka不同的是，客户无法看到ckafka的服务端数据比如broker的日志。因此，客户不能通过查看各个组件日志的方法排查问题，从而只能提工单咨询。从这一点出发，这篇文章介绍一些客户可操作的，针对ckafka的通用排查方法。
1.问题分析
1.2消息传递链路
生产太快、服务端出问题、消费客户端出问题和下游应用出问题是导致消息堆积的主要原因。ckafka的消息链路如下：
生产客户端 --> Ckafka --> 消费客户端 --> 应用A --> 应用B... ...
通用排查方法的核心思想就是从上游往下游，从使用者角度一个个排查。
1.3生产端分析
生产消息速度大于消息消费速度是生产导致消息堆积的唯一原因。这个可以直接在ckafka控制台的监控栏看到。
1.4服务端分析
服务端导致消费慢的原因有很多，比如集群负载高导致请求处理慢，这种情况从客户视角来看是很难发现的。在这里给出一个简单的方法用于确认是否服务端出了问题，即新建测试topic使用kafka命令行工具测试实例消费带宽能否跑满，工具可以从官网下载，操作方法可以参考CKafka系列学习文章 - CKafka入门型配置压测报告（十五）。
当实例消费带宽能够通过压测脚本跑满时，基本可以排除服务端出问题的可能性。
1.5客户端分析
客户端的排查可以从两方面入手：
- 配置
- 负载
配置方面首先看主题的分区数与订阅该主题的消费组的消费者数量。主题的分区数量反映了其可以同时被多少个消费者消费。当消费者组的消费者数量大于主题分区时，消费组中就会有部分消费者空跑。ckafka中主题的分区越多，消费能力越强，可以把主题看成是一个装满水（水看成是消息）的杯子，分区就是一根根插进杯子的吸管。吸管多但是使用吸管的人少，吸水速度也上不去，这种情况就是分区多，消费者数量少。使用吸管的人多但是吸管少，吸管的数量决定了人再多，吸水速度也上不去，这种情况就是分区少，消费者数量多。消费者数量过多还可能导致重平衡，kafka重平衡时无法消费，当kafka反复重平衡时，消费客户端只能不断轮询服务端，然后在消费者稳定时“赶紧”消费。因此，消费者数量过多过少都不好，最理想情况是消费者数量和分区数量比例为1:1。在发现ckafka实例消费特别慢时，客户端排查第一步就是看分区是不是够多了，接着再看分区数量和消费者数量是不是1:1。
当分区和消费者都足够多的时候，如果消费速度还上不来，那就得看消费者的负载。具体来说，是检查消费者进程所在节点或者所属容器节点的负载情况。看CPU负载情况、网卡出入流量等等。
1.6消费下游应用
消费下游应用的排查分两种情况讨论，分别是消费速度突然下降和消费速度一直就很低。
1.6.1消费速度突然下降
在已经排查服务端和消费客户端的情况下，对于下游应用需要检查应用最近是否有变更、负载有无发生变化。
1.6.2消费速度一直就很低
这种情况需要排查下游应用的逻辑，比如消息消费后用于写入数据库，需要检查这个过程是否存在慢查询。
2.小结
当观察到ckafka实例消费慢时，客户侧可以依次执行如下操作缩小排查范围：
- 检查生产速度是否过高。
- 使用压测脚本测试观察实例，确认服务端是否存在问题。
- 检查主题分区数量与消费者数量是否相等，是否存在反复重平衡。
- 检查消费客户端所在节点是否存在高负载。
- 检查下游应用是否存在高负载。
