关于 Kafka，为什么由 Group Leader 分配分区，而不是 GroupCoordinator 呢？

一句话回答
让「最了解业务规则」的客户端（Group Leader）做分配，既把分区算法的复杂度从 Broker 上移走，又允许用户自由插入自定义策略，而 Group Coordinator 只需做一个“可信的仲裁者和广播者”。

下面把原因拆开讲：

1. Broker 保持简单、无状态
   Group Coordinator 作为服务端进程，需要同时处理成千上万个消费者组的心跳、offset 提交、组成员管理等。如果再让它去解析并执行 Range、RoundRobin、Sticky、CooperativeSticky 乃至用户自定义的分配逻辑，代码复杂度、CPU/内存消耗都会急剧上升。把“如何分”外包给客户端，Coordinator 只需校验结果长度是否正确、然后原子地下发给所有成员即可，实现非常轻量。

2. 允许自定义分配策略而不升级 Broker
   分区分配策略以 jar/class 形式存在于客户端，用户可以写自己的 PartitionAssignor 实现，或简单地在配置里换个实现类，无需重启任何 Broker。如果由 Coordinator 来做，就必须在服务端加载、验证、隔离这些用户代码，运维和安全风险都不可接受。

3. 客户端拥有完整订阅信息
   消费者各自订阅的 topic 列表、正则表达式、assign 模式等细节只存在于客户端。Broker 只知道 group.id 和 member.id，并不掌握“谁订阅了哪些 topic”的精确信息，因此也无法独立完成分配。

4. 减少网络数据量
   由客户端 Leader 计算完后，只需把「member → partitions」映射结果回传给 Coordinator，Coordinator 再原样广播给其他成员即可；如果让 Coordinator 做计算，它需要先向所有成员索要完整订阅信息，消息量会大得多。

5. 与协议设计保持一致
   Kafka 的 JoinGroup/SyncGroup 协议本身就是“两阶段”：

   • 阶段1：所有成员上报订阅信息 → Coordinator 选 Leader
   • 阶段2：Leader 计算分配 → Coordinator 把结果同步给所有成员
     这种设计天然把「计算」放在客户端，「一致性广播」放在服务端。

因此，Group Coordinator 只负责选举 Leader、收集订阅、校验结果、原子下发；真正的分区分配逻辑由客户端 Group Leader 完成，既解耦又灵活。