brokers

1.kafka使用zk临时节点维护brokers 信息，zk path为/brokers/ids

controller

只有一个broker会成为Controller,其zk path 为/controller，每次controller发生变化时都会增加controller epoch

Kafka使用Zookeeper的临时节点特性来选择一个controller，并在节点加入和离开集群时通知controller。当controller器注意到节点加入和离开集群时，它负责在分区和副本之间选择leader。controller使用历元数来防止分裂的大脑场景，其中两个节点认为每个节点都是当前控制器

Replication

kafka 副本分为Leader replica 和Follower replica,为了保证一致性生产者和消费者请求都发送给Leader replica 同时leader 负责 trace follower 的同步情况,Followers不处理请求，他们唯一的任务是从Leader同步数据

Followers 通过向Leader 发送Fetch请求同步Leader的数据，这个和消费者发出的消费请求类似，都是包含一个offset，表示下一个需要获取的数据

out of sync

leader 通过查看每个follower最后发来的Fetch请求中的offset 得知follower的数据同步情况。如果一个Follower replica在超过10秒内没有请求一条消息，或者发出了请求，但是已经落后leader 超出10s（ replica.lag.time.max.ms ）了，则认为该副本不同步

in-sync replicas

实时与kafak leader 保持同步的副本

preferred leader

当所有partition的preferred leade为leaders时，可以认为集群是负载均衡的，使用kafka-topics.sh 查看的第一个出现的副本即为 preferred leader

Request Processing

kafka broker 的主要工作是处理来自客户端，其他分区副本，和控制器的请求,主要的请求为Produce requests和Fetch requests。
客户端负责将这些请求发送到leader对应的broker上，那么客户端又是如何得知这些信息的呢，这是通过metadata request实现的，不同于为Produce requests和Fetch requests 这两个只能有leader broker处理，metadata request可以由任何一个broker处理,每个broker都有缓存这些信息

一般客户端会缓存metadata信息， metadata.max.age.ms 控制客户端 metadata request的频率