中心思想：
在一个kafka消费者组（consumer group）中，同一个topic的不同分区会分配给不同的消费者进行消费。每一次consumer group的初始建立以及每一个consumer的上下线都将触发分区的重分配，也就是rebalance。那么这个为消费者分配分区的动作是由谁来完成，consumer端还是kafka server端？分区又是如何进行分配的呢？ 对于这个问题，kafka经过了以下一系列的优化升级。
友情提示：
本文部分内容摘抄自《apache kafka源码剖析》，后期源码可能会有新的优化，本文仅供参考，具体请以官网最新发布为准。
优化历程：
-
zookeeper存储consumer元数据信息的方式
kafka最开始为消费者分配分区是通过zookeeper的watcher实现的。每个consumer group在zookeeper下都维护了一个“consumers/[group_id]/ids”路径，在此路径下使用临时节点记录属于此consumer group的消费者id,由consumer启动时创建。与ids同级的另外两个节点分别是：用于记录分区与对应消费者关系的owners节点以及consumer group在每个partition上的消费位置的offsets节点。
每个consumer都分别在“consumers/[group_id]/ids”和“brokers/ids”上注册一个watcher。当有消费者上下线或者kafka集群broker增减时，就可以被watcher监控到。
方案缺陷：
（1）羊群效应：任何broker或consumer加入或退出，都会向其余所有的consumer发送watcher通知触发rebalance,大量的watcher通知被发送到客户端的期间，会导致其他操作被延迟。
（2）脑裂：由于zookeeper只保证最终一致性，不同的consumer连接到zookeeper集群中的不同服务器，拿到的元数据信息可能不一样，就会造成不正确的rebalance尝试。 -
group coordinator管理consumer的方式
基于zookeeper方式的缺陷，kafka后续版本对rebalance操作进行了改造。主要是将全部的consumer group划分成多个子集，每个consumer group子集在kafka 服务端对应一个group coordinator对其进行管理，每个group coordinate在zookeeper上注册一个watcher用于监控consumer或者broker的变动，监控原理与上述方案一致，consumer不断向group coordinator发送心跳信息传递自己的健康状态，由coordinator完成分区的分配并将通过此种方式减少watcher的数量 。
方案缺陷：由于分区分配策略是由位于kafka server端的group coordinator决定的，当需要自定义分配策略或更改新的分配策略时就需要修改服务端源码并重启服务，非常不友好。 -
基于group coordinator的改造（kafka0.9版本）
针对上述方案中的缺陷，kafka0.9版本将分区分配的工作放到了consumer端进行处理。分区策略比重等信息封装在consumer中，当发起rebalance操作时，由group coordinantor收集所有的consumer信息，选定一个consumer leader 并根据收集到的分区策略信息决定选用的分区分配策略。返回SyncGroupResponse给所有的消费者，只有consumer leader收到的response包含所有消费者的分区信息，之后由consumer leader完成分区的分配。
