首先分析一下它为什么会积压，无非是以下几种情况，写个思路
代码中消费者处理消费效率低、kafka参数使用默认、消费者消费能力不足（生产者生产能力过盛）、网络带宽、服务器性能等
1、代码质量问题（消费者处理逻辑复杂等）
这个问题运维并不好直接验证，处理消费的速度慢，或者说处理的流程相对复杂都会导致消息积压，看开发同学怎么想，数据只要不过期，服务器不崩，没啥问题，反正就运维盯着点呗
2、应用层
在消费者段，可以通过调整消费者组的配置来优化消息的处理，可以增加并行消费的线程数量，调整消费者的批量读取配置等来提高消费的效率等
3、kafka层
通过代码调用kafka接口存放消息，所以kafka的配置文件优化也在考虑范围内，比如
max.poll.records：控制每次poll操作能够处理的最大消息数量
fetch.min.bytes和fetch.max.bytes：控制消费者一次请求能够拉取的消息数据大小。
min.insync.replicas：确保写入消息时至少有N个副本在线
类似的配置修改，百度一大堆，不举例了
如果涉及到扩容kafka的broker数量，想把之前已经积压的消息分给新服务器，涉及到kafka数据迁移，一般没必要，做的多错的多，百度上的方案一般拼拼凑凑也可以用，这里就不写了，我懒
4、消费者消费能力不足（生产者生产能力过盛）
生产者这部分我们几乎没有办法改变，因为一般来说，数据都是通过某个前端系统推送过来的，业务流量的增加导致的积压，我们总不能删请求数据，所以以运维的视角来说，这部分我们并没有什么好的办法控制
消费者这部分可以做做文章，比如增加某个topic的副本数量，横向扩容kafka等办法，都可以对其做出一定的优化
标签：消费,积压,消费者,处理,kafka,消息 From： https://www.cnblogs.com/zhangty333/p/18282095