消息队列之kafka 的负载均衡

[TOC]

综述

ZooKeeper负责管理所有Broker服务器列表，并且建立了对应路径来对其进行管理/brokers/ids。每个Broker服务器在启动时，都会到ZooKeeper上进行注册，其节点路径为/broker/ids/[0…N]。
Topic注册：Kafka当中，会将同一个Topic的消息分成多个区，分布到多个Broker上，这些分区信息和Broker的对应关系由ZooKeeper来维护。
每当一个Broker启动时，会首先完成Broker注册过程，在ZooKeeper的节点列表里保存Broker。
Kafka的生产者会对ZooKeeper上的“Broker的新增与减少”、“Topic的新增和减少”和“Broker和Topic关联关系的变化”等事件注册Watcher监听
通过ZooKeeper的Watcher通知能够让生产者动态的获取Broker和Topic的变化情况

在生产中，必须指定topic， topic 对应的 broker 是可以通过 zk 获得的；但是对于partition,有两种指定方式：

明确指定partition(0-N)，则数据被发送到指定partition
设置为RD_KAFKA_PARTITION_UA，则kafka会回调partitioner进行均衡选取，partitioner方法需要自己实现。可以轮询或者传入key进行hash。未实现则采用默认的随机方法rd_kafka_msg_partitioner_random随机选择。

Kafka具有消费分组的概念，某个Topic的某个partition只能由一个Consumer group中的一个Consmer消费。但如果两个Consmer不在同一个Consumer group，那么他们是可以同时消费某Topic的同一个partition的。

对于某些低级别的API，Consumer消费时必须制定topic和partition，这显然不是一种很好的均衡策略。基于高级别的API，Consumer消费时只需指定topic，借助zookeeper可以根据partition的数量和consumer的数量做到均衡的动态配置。

消费者在启动时会到zookeeper下以自己的conusmer-id创建临时节点/consumer/[group-id]/ids/[conusmer-id]，并对/consumer/[group-id]/ids注册监听事件，当消费者发生变化时，同一group的其余消费者会得到通知。

例如，消费组中有 4 个消费者，其中一个突然断开，那么这会促发 rebalance，这 3 个消费者会一起来消费所有的分区。促发 rebalance 的时机实际上是消费者的存活检测机制实现的。详细可以看《kafka入门》

broker 的负载均衡主要发生在创建 topic 时，会将 topic 的多个分区均衡地分配到多个 broker 上。

不确定 Kafka 的 broker 有没有像pulsar的自动的过载重平衡。