Kafka Concept

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 replicaFollower 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 requestsFetch requests
客户端负责将这些请求发送到leader对应的broker上,那么客户端又是如何得知这些信息的呢,这是通过metadata request实现的,不同于为Produce requestsFetch requests 这两个只能有leader broker处理,metadata request可以由任何一个broker处理,每个broker都有缓存这些信息

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

你可能感兴趣的:(Kafka Concept)