Spark大数据实时分析实战

下面通过在Kafka 中创建一个“mytopic”来说明Leader 均衡机制的问题。

在Kafka 任意一台Broker 节点上执行创建Topic 命令，这里在mynode1 中执行命令创建“mytopic”，命令如下：

创建了一个Topic，名称为“mytopic”，这个Topic 有3 个Partition，每个Partition 有3 个副本，执行以下命令来查看当前“mytopic”的描述。

通过以上查询“mytopic”消息队列的描述，发现在每个Partition 都有各自的Replicas，以“mytopic”消息队列中的Partition 0 为例，当前分区0 的Replicas 为0，1，2，代表当前Partition 的副本存在于0 号Broker、1 号Broker、2 号Broker 上。Partition 0 的Leader 为0，代表当前Partition 0 归属0 号Broker 节点管理。(www.xing528.com)

当“mytopic”的Partition 0 所在的0 号Broker 节点宕机时，Partition 0 会按照Replicas 的顺序寻找下一个Broker 节点来管理，这样就选择了1 号Broker 来管理Partition 0，同样，如果1 号Broker 节点宕机之后，Kafka 集群继续按照Replicas 的顺序继续找到2 号Broker 节点来管理当前的0 号Partition，直到所有Kafka 节点都宕机时，Kafka 集群才不能对外提供数据服务。

假设这里的3 台Broker 节点挂点了2 台Broker 节点，那么最后存活的Broker 节点负责Kafka 集群所有Topic 的分区的读写和存储任务，这样这台节点的负载比较高。这时，如果通过集群监控工具发现其他两台Broker 节点挂掉，将其他挂掉的两台Broker节点重新启动后，Kafka 集群会将当前这台负载较高节点上管理的Partition 分区自动分散到其他两台重启后的Broker 节点上，原则是原来两台Broker 节点管理哪些Partition，重启之后还是管理哪些Partition，这个过程避免了将所有的Kafka 集群Topic 的读取、存储压力集中到一台Broker 节点的现象，相当于做了一次负债均衡，这就是所谓的Leader均衡机制。