26°

kafka学习(5)架构说明

 

上面是消息同步和异步的发送方式。

 

在用户拿去数据的时,可以采用kafka的两种api,高级api和低级api

问题:什么是高级API?什么是低级API?

hight level API:隐藏consumer和broker细节,相关信息保存在zookeeper中。

用户使用时很方便,大部分操作,都是已经封装好的,比如当前消费到哪个位置下,但是不够灵活。

low level API:没有进行封装,所有的操作,由用户决定,如自己需要保存某个分区下的记录,你当前消费到哪个位置。

灵活度提升了,但是需要自己负责链接到leader broker,保存offset,consumer partition对应关系。

 

Leader broker是之前的说法,现在基本上不使用了,

kafka集群中,包含了很多个broker,但是在broker中,也会有一个leader broker存在,是在kafka节点中的一个临时节点,

去创建相应的数据,controller broker。 controller_ecpoch是选举,哪个broker被选举成为老大,就把它的值写到controller_ecpoch中。

 

在Kafka早期版本,对于分区和副本的状态的管理依赖于zookeeper的Watcher和队列:每一个broker都会在zookeeper注册Watcher,所以zookeeper就会出现大量的Watcher, 如果宕机的broker上的partition很多比较多,会造成多个Watcher触发,造成集群内大规模调整;每一个replica都要去再次zookeeper上注册监视器,当集群规模很大的时候,zookeeper负担很重。这种设计很容易出现脑裂和羊群效应以及zookeeper集群过载。

新版本该变了这种设计,使用KafkaController,只有KafkaController

Leader会向zookeeper上注册Watcher,其他broker几乎不用监听zookeeper的状态变化。

Kafka集群中多个broker,有一个会被选举为controller leader,负责管理整个集群中分区和副本的状态,比如partition的leader 副本故障,由controller 负责为该partition重新选举新的leader 副本;当检测到ISR列表发生变化,有controller通知集群中所有broker更新其MetadataCache信息;或者增加某个topic分区的时候也会由controller管理分区的重新分配工作

当broker启动的时候,都会创建KafkaController对象,但是集群中只能有一个leader对外提供服务,这些每个节点上的KafkaController会在指定的zookeeper路径下创建临时节点,只有第一个成功创建的节点的KafkaController才可以成为leader,其余的都是follower。当leader故障后,所有的follower会收到通知,再次竞争在该路径下创建节点从而选举新的leader

Controller broker 的职责是管理所有的broker。管理整个集群中分区和副本的状态

KafkaController vs ReplicaManager

KafkaController: 负责管理整个集群中分区和副本的状态

ReplicaManager:负责管理当前broker所有分区和副本的信息,会处理KafkaController发起的一些请求,副本状态的切换,添加/读取消息等

 

 

kafka的常用命令:

数据到期,可以设置删除的方式,还有合并的方式。

Leader是 leader partition存在于某个broker的id,replicas是分区副本存在的broker的id,isr是或者的分区副本,存在的broker的id

 

本文由【太猪-YJ】发布于开源中国,原文链接:https://my.oschina.net/xiaoyoung/blog/3033959

全部评论: 0

    我有话说: