背景：
工作往往是千篇一律，真正能学到点知识都是在上线后。使用Skywalking+Kafka+ES进行应用监控。
现象：
公司使用Skywalking在开发测试环境中Kafka顺利消费数据，到了UAT环境一开始还正常，后面接入了更多的应用后出现了问题：OAP服务正常但是ES里不再有数据。
排查：
通过查看消费者消费Kafka数据的情况可以看到，数据出现了积压。
由于没有设置消费者的参数，所以使用的是默认值max.poll.interval.ms是5分钟、 max.poll.records是500
目前积压数据远大于一次拉取消费的500，所以判断是因为消费者无法在等待时间内消费完数据，Consumer Group Coordination消费组判定当前消费者不在消费组内，所以查询消费者状态会出现消费者组不存在消费成员（如图符合判断）
目前解决方法：
max.poll.records改小或者 request.timeout.ms改大或者 request.timeout.ms改大，因为目前数据不稳定后续也只能通过数据量进行修改参数调优。重新开始消费，待后续观察。
结论：
由于数据量变大，消费者长时间不再请求数据，未向Group Coordinator发送心跳请求，所以kafka认为消费者已从消费组下线。所以不再进行消费。
学习：
之前知识浅浅了解了Rebalance，但没碰到过。所以借此好好学习一下。
一、什么是Rebalance
-
Rebalance本质上是一种协议, 规定了一个Consumer Group下的所有consumer如何达成一致,来分配订阅Topic的每个分区。
-
Rebalance发生时, 所有的Consumer Group都停止工作, 直到Rebalance 成。
二、触发条件
① 组成员个数发生变化
-
新的消费者加入到消费组
-
消费者主动退出消费组
-
消费者被动下线。比如消费者长时间的GC, 网络延迟导致消费者长时间未向Group Coordinator发送心跳请求, 均会认为该消费者已经下线并踢出（本次问题出现的原因）
② 订阅的Topic的Consumer Group个数发生变化
③ Topic 的分区数发生变化
三、Rebalance的弊端
- rebalance的时候消费组内的所有消费者都不能处理消息
- 消费组内的消费者越多rebalance时间越长
-
Rebalance 效率不高。当前 Kafka 的设计机制决定了每次 Rebalance 时，Consumer Group 下的所有成员都要参与进来，而且通常不会考虑局部性原理，但局部性原理对提升系统性能是特别重要的。
四、如何避免Rebalance
从触发条件可以看到，① 、 ② 、③基本都是可以认为尽量避免也就是提前根据数据量规划好消费者数量，主要是① 中的第三个，需要靠kafka的参数去调整
# 心跳相关session.timeout.ms = 6s heartbeat.interval.ms = 2s# 消费数量(默认500) max.poll.records# 消费时间(默认300000) request.timeout.msmax.poll.interval.ms=300000
五、Rebalance过程
Coordinator服务
-
Group Coordinator 是一个服务, 每个 Broker 在启动的时候都会启动一个该服务 Group Coordinator 的作用是用来存储 Group 的相关 Meta 信息, 并将对应 Partition 的 Offset 信息记录到 Kafka 内置 Topic(__consumer_offsets)中
-
Kafka 在0.9之前是基于 Zookeeper 来存储Partition的 offset 信息(consumers/{group}/offsets/{topic}/{partition}), 因为 Zookeeper 并不适用于频繁的写操作, 所以在0.9之后通过内置 Topic 的方式来记录对应 Partition 的 offset。
Rebalance过程分为两步：Join Group和 Sync Group。
Join Group
① 概述
-
Join Group 顾名思义就是加入组。
-
这一步中, 所有成员都向 Coordinator 发送 JoinGroup 请求, 请求加入消费组。
-
一旦所有成员都发送了 JoinGroup 请求, Coordinator 会从中选择一个 Consumer 担任 Leader 的角色, 并把组成员信息以及订阅信息发给 Consumer Leader。
-
注意Consumer Leader 和 Coordinator不是一个概念。Consumer Leader负责消费分配方案的制定。
② 流程图
Sync Group
① 概述
-
Consumer Leader 开始分配消费方案，即哪个 Consumer 负责消费哪些 Topic 的哪些 Partition。
-
一旦完成分配，Consumer Leader 会将这个方案封装进SyncGroup请求中发给 Coordinator。
-
非 Consumer Leader 也会发 SyncGroup 请求, 只是内容为空。
-
Coordinator 接收到分配方案之后会把方案塞进SyncGroup的Response中发给各个Consumer。
-
这样组内的所有成员就都知道自己应该消费哪些分区了。
② 流程图
参考：Kafka学习笔记 NO.004 Kafka的Rebalance(重平衡) - 墨天轮
