这是针对Kafka的消费者的机制，以下场景将发生rebalance：
- 消费者组新增消费实例或者有消费实例退出group；
- group消费超时；
- group订阅的topic个数发生变化；
- group订阅的topic的分区个数发生变化；
当rebalance时，所有消费实例会先发起 ApiKeys.FIND_COORDINATOR请求获取coordinator （这个coordinator是消费组名称hash对__consumer_offsetst这个topic的分区个数进行取余，然后获取分区的leader所在broker作为coordinator）。
然后消费者获取到coordinator或将向coordinator发起 ApiKeys.JOIN_GROUP请求加入消费组，在coordinator中会选出一个consumer作为消费组的leader消费者，把成员信息和leader信息返回到个消费者实例中，消费实例根据角色判断是否是leader。
如果是leader，则负责为整个消费组中的消费者分配应该消费哪些分区，然后发送ApiKeys.SYNC_GROUP请求，把分配策略同步到coordinator。
如果是follower，则直接发起一个ApiKeys.SYNC_GROUP请求到coordinator，获取自己分配到的topic分区。
那么在rebalance中，如果解决重复提交消费点位和重复消费的问题呢？这里面主要是用了一个generationId，这时一个递增的数字，和epoch有点像。
