kafka 如何解决rebalance问题
能力是一个人的长度；勤奋是一个人的宽度；善于抓住机遇构成这个人的高度。长度、宽度、高度的乘积，就能算出我们每个人的生命容量。
在kafka中，什么是rebalance？
rebalance中文含义为再平衡。它本质上是一组协议，它规定了一个 consumer group 是如何达成一致来分配订阅 topic 的所有分区的。比方说Consumer Group A 有3个consumer 实例，它要消费一个拥有6个分区的topic，每个consumer消费2个分区，这就是rebalance。
rebalance是相对于consumer group 而言，每个consumer group会从kafka broker中选出一个作为组协调者（group coordinator）。coordinator负责对整个consumer group的状态进行管理，当有触发rebalance的条件发生时，促使生成新的分区分配方案。
rebalance（重平衡）其实就是重新进行 partition 的分配，从而使得 partition 的分配重新达到平衡状态。
什么是Coordinator？
Coordinator一般指的是运行在broker上的group Coordinator，用于管理Consumer Group中各个成员，每个KafkaServer都有一个GroupCoordinator实例，管理多个消费者组，主要用于offset位移管理和Consumer Rebalance。
rebalance触发的三种条件：
- 当 Consumer Group 组成员数量发生变化（新成员加入，组成员主动离开，组成员崩溃）
- 当订阅主题数量发生变化
- 当订阅主题的分区数发生变化
总结：根本原因还是因为topic 中partition或者consumer实例发生了变更导致触发rebalance
rebalance协议：kafka新版本提供了下面5个协议来处理Rebalance
- Heartbeat请求：Consumer 需要定期给 Coordinator 发送心跳来证明自己还活着。
- LeaveGroup请求：主动告诉 Coordinator 要离开 Consumer Group
- SyncGroup请求：Group Leader Consumer 把分配方案告诉组内所有成员
- JoinGroup请求：成员请求加入组
- DescribeGroup请求：显示组的所有信息，包括成员信息，协议名称，分配方案，订阅信息等。通常该请求是给管理员使用。
注意：Coordinator 在 Rebalance 的时候主要用到了前面4种请求
rebalance 过程中， coordinator 要处理 consumer 发过来的 JoinGroup 和SyncGroup 请求 。当consumer 主动离组时会发送 LeaveGroup 请求给 coordinator
在成功 rebalance 之后，组内所有 consumer 都需要定期地向 coordinator 发送 Heartbeat 请求，而每个 consumer 也是根据 Heartbeat 请求的响应中是否包含 REBALANCE_IN_PROGRESS判断当前 group 开启了新一轮 rebalance。
rebalance流程：主要分为两步：加入组和同步更新分配方案
1、加入组：consumer group中所有consumer实例向coordinator发送JoinGroup请求。当收集全JoinGroup请求，coordinator从中选择一个consumer group作为group的leader，并把所有成员信息以及他们订阅的topic信息发送给leader。需要注意的是leader是consumer group中的一个consumer实例，而coordinator为集群的一个broker。是leader而不是coordinator负责为整个consumer group成员制定分配方案。
2、同步更新分配方案：这一步leader开始制定分配方案，即根据前面提到的分配策略，决定哪个consumer消费哪些topic的哪些分区，一旦分配完成，leader会将分配方案封装进SyncGroup请求发送给coordinator。值得注意的是，组内所有成员都会发送SyncGroup请求，不过只有leader发送的请求中包含分配方案。coordinator收到分配方案后把属于每个consumer的分配方案单独抽取出来做作为SyncGroup请求的response返回给各个consumer。
