需要明确下,目前 以为是 2 。
来自园友“扎心了,老铁”的博文的三张图:
https://images2018.cnblogs.com/blog/1228818/201805/1228818-20180507194612622-1788087919.png
https://images2018.cnblogs.com/blog/1228818/201805/1228818-20180507190731172-1317551019.png
https://images2018.cnblogs.com/blog/1228818/201805/1228818-20180507192145249-1414897650.png
3.ZooKeeper负载过重 每个Replica都要为此在ZooKeeper上注册一个Watch,当集群规模增加到几千个Partition时ZooKeeper负载会过重。
Kafka 0.8.*的Leader Election方案解决了上述问题,它在所有broker中选出一个controller,所有Partition的Leader选举都由controller决定。controller会将Leader的改变直接通过RPC的方式(比ZooKeeper Queue的方式更高效)通知需为为此作为响应的Broker。同时controller也负责增删Topic以及Replica的重新分配。
转自 正文中 提到的 园友的 博文
“所有Partition的Leader”
明白了,也就是说,有很多 Leader,和 Partition 有关,而不是Topic?也是,Topic那么多,无法确定的,,而Partition是可确定的。