Broker 加入和离开集群时发生什么

验证：新broker加入，已有topic真实一个分区都不会挪动

命令 · shell $ kafka-server-start.sh node4/server.properties & # node.id=4，真实新加入的broker $ kafka-topics.sh --bootstrap-server localhost:19092 --describe --topic order-demo

真实实测 · 本机执行输出

broker4加入后，order-demo分区分配(跟加入前完全一样):
Partition 0  Leader: 3  Replicas: 3,1,2
Partition 1  Leader: 2  Replicas: 1,2,3
Partition 2  Leader: 2  Replicas: 2,3,1

broker4真实注册进了集群（能在broker列表里查到它），但已经存在的order-demo这个topic，三个分区的Replicas列表里真实都不包含4——Kafka不会因为集群多了一台机器，就自动重新平衡已有数据。新broker刚加入时是真实空的，不会自动分担任何已有topic的负载，这是需要额外操心的一步。

验证：只有新建的topic，才会真实把新broker算进去

真实实测 · 本机执行输出

$ kafka-topics.sh --create --topic after-join-topic --partitions 4 --replication-factor 2
Partition 0  Leader: 4  Replicas: 4,1
Partition 1  Leader: 1  Replicas: 1,2
Partition 2  Leader: 2  Replicas: 2,3
Partition 3  Leader: 3  Replicas: 3,4

broker4加入之后创建的这个新topic，round-robin真实覆盖了全部4个broker——分区0真实以broker4为leader，分区3真实把broker4也算进了副本。Controller的分区分配算法真实只在"创建新分区"这一刻才会考虑当前有哪些broker可用，不会主动回头重新分配已经存在的分区。

验证：broker离开后，Replicas列表真实不会自动清理它

命令 · shell $ kill -9 <broker4的pid> $ kafka-topics.sh --describe --topic after-join-topic

真实实测 · 本机执行输出

Partition 0  Leader: 1  Replicas: 4,1  Isr: 1     ← Replicas真实还写着4
Partition 3  Leader: 3  Replicas: 3,4  Isr: 3     ← 同样还留着4

broker4死后，真实只有Leader和Isr这两个字段更新了——leader真实切换到了剩下的健康副本，ISR真实收缩到只剩活着的那个；但Replicas字段，也就是"这个分区理论上应该有哪些副本"，真实原封不动地保留着broker4。这意味着分区0和分区3现在真实处于"只剩1个副本在线"的状态，如果这唯一的副本也真实挂了，数据就没了——Kafka不会自动帮你把死掉的副本从名单里划掉、找一个新broker补上，这一步真实需要运维主动介入，也就是下一篇要讲的Partition Reassignment。

分步演示：一个broker真实的加入与离开

每一步都是本文上面用一个新broker加入又死亡跑出来的原始结果。

加入不影响旧数据，离开也不会自动清理副本名单

这一步新验证的状态

参考与说明

数据来自本机3节点Kafka 4.3.1集群加入的第4个真实broker(node.id=4)，仅担任broker角色(未加入controller quorum)。
和《Partition Reassignment：分区迁移如何进行》一起看：这篇留下的"Replicas列表残留死broker id"这个问题，正是那篇要解决的。
没有验证：Cruise Control这类自动化工具真实是怎么在broker加入/离开时自动触发重新平衡的，本文只覆盖了Kafka自身默认(不自动重平衡)的行为。

下一篇 · KAFKA 内部原理 49

Partition Reassignment：分区迁移如何进行