Kafka——zookeeper的作用
Zookeeper
1、leader 选举和 follower 信息同步
Kafka 中每个 Topic 的分区有 N 个副本，其中 N 是 Topic 的复制因子。Kafka 通过多副本机制实现故障转移，当 Kafka 集群中一个 Broker 失效情况下仍然保证服务可用，在 Kafka 中发生复制时确保分区副本日志有序地写到其它 Broker 节点。N 复制分区中，其中一个为 Leader，剩下都为 Follower，Leader 处理分区的所有读写请求，Follower 会被定期地去复制 Leader 上的数据。
Kafka 提供了数据复制算法的保证，如果 Leader 发生宕机，新 Leader 会当选并开始接收客户端消息进行写入。Follower 实现追赶 leader 数据，Leader 负责维护和跟踪 ISR 中所有 Follower 的滞后状态。当生产者发送一条消息到 Broker 时，Leader 写入消息并复制到所有 Follower，消息提交之后才被成功复制到所有同步的副本。
2、Broker 注册
Broker是分布式部署并且相互之间相互独立，但是需要有一个注册系统能够将整个集群中的Broker管理起来，此时就使用到了Zookeeper。在Zookeeper上会有一个专门用来进行Broker服务器列表记录的节点：/brokers/ids。
每个 Broker 在启动时，都会到 Zookeeper 上进行注册，即到 /brokers/ids 下创建属于自己的节点，例如 /brokers/ids/[0...N]。
Kafka 通过全局唯一的数字来指代每个 Broker 节点，创建完节点后节点的 IP、Port 会记录到节点信息中去，Broker 节点为临时节点，一旦 Broker 宕机信息就会丢失。
3、Topic 注册
在Kafka中，同一个Topic的消息会被分成多个分区并将其分布在多个Broker上，这些分区信息及与Broker的对应关系也都是由Zookeeper在维护，由专门的节点来记录，如：/brokers/topics。
Kafka 中每个 Topic 都会以 /brokers/topics/[topic] 形式记录和 Broker 的关系，例如 /brokers/topics/login、/brokers/topics/search 等。Broker 启动后会到对应 Topic 节点下注册自己的 BrokerID 并写入针对该 Topic 的分区总数，例如 /brokers/topics/login/3->2，它表示 BrokerID=3 的服务器，对于 login 这个主题消息提供了 2 个分区进行消息存储。这个节点也是临时节点。
4、生产者负载均衡
传统四层负载均衡、七层负载均衡：https://zhuanlan.zhihu.com/p/64777456
同一个 Topic 的消息分区分布在多个 Broker 上，因此生产者需要将消息合理地分布到这些 Broker 上，如何实现生产者的负载均衡，Kafka 支持传统的四层负载均衡，也支持 Zookeeper 方式的负载均衡。
- 传统四层负载均衡：根据生产者的 IP、Port 为其关联一个 Broker，由该生产者生产的消息都会发送到 Broker。每个生产者不需要同其它系统建立额外的 TCP 连接。但是无法实现真正的负载，因为实际每个生产者生产的消息量及每个 Broker 存储的消息量都是不一致的，生产者间消息量的不同导致负载差异。
- Zookeeper 负载均衡：每个 Broker 节点启动时会到对应 Topic 节点下注册自己的
BrokerID->PartitionNums记录，生产者可以通过该节点的变化感知 Broker 服务器列表的变更，实现动态的负载均衡。
5、消费者负载均衡
与生产者类似，Kafka中的消费者同样需要进行负载均衡来实现多个消费者合理地从对应的Broker服务器上接收消息，每个消费者分组包含若干消费者，每条消息都只会发送给分组中的一个消费者，不同的消费者分组消费自己特定的Topic下面的消息，互不干扰。
6、分区和消费者的关系
Kafka 会为每个消费者组分配一个全局唯一 Group ID，组内部的所有消费者共享该ID。消费者组订阅的主题下的每个分区只能分配给消费者组下某一个特定的消费者（该分区还可以分配给其他 Group）。同时，Kafka为每个消费者分配一个Consumer ID，通常采用"Hostname:UUID"形式表示。
Kafka 规定了每个消费分区只能被同消费者组的一个消费者消费，因此需要在 ZK 上记录消费分区与消费者之间的关系，将 ConsumerID 写入到 ZK 对应消息分区的临时节点上，例如：/consumers/[group_id]/owners/[topic]/[broker_id——partition_id]，其中 [broker_id——partition_id] 是消息分区的标识，节点内容就是消费者的 ConsumerID。
7、消息消费进度 Offset
在消费者对指定消息分区进行消息消费的过程中，需要定时地将分区消息的消费进度Offset记录到Zookeeper上，以便在该消费者进行重启或者其他消费者重新接管该消息分区的消息消费后，能够从之前的进度开始继续进行消息消费。Offset在Zookeeper中由一个专门节点进行记录，其节点路径为：/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id]，节点内容就是 Offset。
8、消费者注册
消费者初始化启动时加入消费者组步骤如下：
- 每个消费者启动时都会到 ZK 节点下创建一个属于自己的消费者节点，例如
/consumers/[group_id]/ids/[consumer_id]，完成节点创建后，消费者会将自己订阅的 Topic 信息写入该临时节点。 - 对消费者分组中的消费者的变化注册监听。每个消费者都需要关注所属消费者分组中其他消费者服务器的变化情况，即对
/consumers/[group_id]/ids节点注册子节点变化的Watcher监听，一旦发现消费者新增或减少，就触发消费者的负载均衡。 - 对Broker服务器变化注册监听。消费者需要对
/broker/ids/[0-N]中的节点进行监听，如果发现Broker服务器列表发生变化，那么就根据具体情况来决定是否需要进行消费者负载均衡。
