内容简介:当kafka启动的时候,就会向zookeeper里面注册一些信息,这些数据也称为Kafka的元数据信息。服务端开启的情况下,进入客户端的命令:{zookeeper目录}/bin/zkCli.sh
当kafka启动的时候,就会向zookeeper里面注册一些信息,这些数据也称为Kafka的元数据信息。
一、Kafka在zookeeper中存储结构图
二、分析
根目录下的结构
服务端开启的情况下,进入客户端的命令:{zookeeper目录}/bin/zkCli.sh
# {zookeeper目录}/bin/zkCli.sh [zk: localhost:2181(CONNECTED) 1] ls / [cluster, controller_epoch, controller, brokers, zookeeper, admin, isr_change_notification, consumers, log_dir_event_notification, latest_producer_id_block, config]
2.1topic注册信息
/brokers/topics/[topic] :
存储某个topic的partitions所有分配信息
[zk: localhost:2181(CONNECTED) 1] get /brokers/topics/topic2
Schema: { "version": "版本编号目前固定为数字1", "partitions": { "partitionId编号": [ 同步副本组brokerId列表 ], "partitionId编号": [ 同步副本组brokerId列表 ], ....... } } Example: { "version": 1, "partitions": { "2": [1, 2, 3], "1": [0, 1, 2], "0": [3, 0, 1], } }
2.2partition状态信息
/brokers/topics/[topic]/partitions/[0...N] 其中[0..N]表示partition索引号
[zk: localhost:2181(CONNECTED) 2] ls /brokers/topics/[topic]/partitions [0, 1, 2] [zk: localhost:2181(CONNECTED) 3] /brokers/topics/[topic]/partitions/[partitionId]/state
Schema: { "controller_epoch": 表示kafka集群中的中央控制器选举次数, "leader": 表示该partition选举leader的brokerId, "version": 版本编号默认为1, "leader_epoch": 该partition leader选举次数, "isr": [同步副本组brokerId列表] } Example: { "controller_epoch": 1, "leader": 3, "version": 1, "leader_epoch": 0, "isr": [3, 0, 1] }
2.3Broker注册信息
/brokers/ids/[0...N]
[zk: localhost:2181(CONNECTED) 4] ls /brokers/ids [0, 1, 2, 3] [zk: localhost:2181(CONNECTED) 5] get /brokers/ids/0
每个broker的配置文件中都需要指定一个数字类型的id(全局不可重复),此节点为临时znode(EPHEMERAL)
Schema: { "jmx_port": jmx端口号, "timestamp": kafka broker初始启动时的时间戳, "host": 主机名或ip地址, "version": 版本编号默认为1, "port": kafka broker的服务端端口号,由server.properties中参数port确定 } Example: { "jmx_port": -1, "timestamp":"1525741823119" "version": 1, "host": "hadoop1", "port": 9092 }
2.4Controller epoch
[zk: localhost:2181(CONNECTED) 6] get /controller_epoch 1
此值为一个数字,kafka集群中第一个broker第一次启动时为1,以后只要集群中center controller中央控制器所在broker变更或挂掉,就会重新选举新的center controller,每次center controller变更controller_epoch值就会 + 1;
2.5Controller注册信息
存储center controller中央控制器所在kafka broker的信息
[zk: localhost:2181(CONNECTED) 7] get /controller
Schema: { "version": 版本编号默认为1, "brokerid": kafka集群中broker唯一编号, "timestamp": kafka broker中央控制器变更时的时间戳 } Example: { "version": 1, "brokerid": 0, "timestamp": "1525741822769" }
2.6补充Consumer and Consumer group
① 每个consumer客户端被创建时,会向zookeeper注册自己的信息;
② 此作用主要是为了"负载均衡"。
③ 同一个Consumer Group中的Consumers,Kafka将相应Topic中的每个消息只发送给其中一个Consumer。
④ Consumer Group中的每个Consumer读取Topic的一个或多个Partitions,并且是唯一的Consumer。
⑤ 一个Consumer group的多个consumer的所有线程依次有序地消费一个topic的所有partitions,如果Consumer group中所有consumer总线程大于partitions数量,则会出现空闲情况。
举例说明:
kafka集群中创建一个topic为report-log 4 partitions 索引编号为0,1,2,3
假如有目前有三个消费者node: 注意 --> 一个consumer中一个消费线程可以消费一个或多个partition
如果每个consumer创建一个consumer thread线程,各个node消费情况如下,node1消费索引编号为0,1分区,node2费索引编号为2,node3费索引编号为3
如果每个consumer创建2个consumer thread线程,各个node消费情况如下(是从consumer node先后启动状态来确定的),node1消费索引编号为0,1分区;node2费索引编号为2,3;node3为空闲状态
总结:
从以上可知,Consumer Group中各个consumer是根据先后启动的顺序有序消费一个topic的所有partitions的。
如果Consumer Group中所有consumer的总线程数大于partitions数量,则可能consumer thread或consumer会出现空闲状态。
2.7Consumer均衡算法
当一个group中,有consumer加入或者离开时,会触发partitions均衡.均衡的最终目的,是提升topic的并发消费能力。
1) 假如topic1,具有如下partitions: P0,P1,P2,P3
2) 加入group中,有如下consumer: C0,C1
3) 首先根据partition索引号对partitions排序: P0,P1,P2,P3
4) 根据(consumer.id + '-'+ thread序号)排序: C0,C1
5) 计算倍数: M = [P0,P1,P2,P3].size / [C0,C1].size,本例值M=2(向上取整)
6) 然后依次分配partitions: C0 = [P0,P1],C1=[P2,P3],即Ci = [P(i M),P((i + 1) M -1)]
2.8Consumer注册信息
每个consumer都有一个唯一的ID(consumerId可以通过配置文件指定,也可以由系统生成),此id用来标记消费者信息。
/consumers/[groupId]/ids/[consumerIdString]
是一个临时的znode,此节点的值为请看consumerIdString产生规则,即表示此consumer目前所消费的topic + partitions列表。
consumerId产生规则:
StringconsumerUuid = null; if(config.consumerId!=null && config.consumerId) consumerUuid = consumerId; else { String uuid = UUID.randomUUID() consumerUuid = "%s-%d-%s".format( InetAddress.getLocalHost.getHostName, System.currentTimeMillis, uuid.getMostSignificantBits().toHexString.substring(0,8)); } String consumerIdString = config.groupId + "_" + consumerUuid;
[zk: localhost:2181(CONNECTED) 8] ls /consumers [zk: localhost:2181(CONNECTED) 9] ls /consumers/console-consumer-2034/ids [zk: localhost:2181(CONNECTED) 10] get /consumers/console-consumer-2034/ids/console-consumer-2034_kafka1-8454138431234-7a59ee48
Schema: { "version": 版本编号默认为1, "subscription": { //订阅topic列表 "topic名称": consumer中topic消费者线程数 }, "pattern": "static", "timestamp": "consumer启动时的时间戳" } Example: { "version": 1, "subscription": { "topic2": 1 }, "pattern": "white_list", "timestamp": "1525747915336" }
2.9Consumer owner
/consumers/[groupId]/owners/[topic]/[partitionId] -> consumerIdString + threadId索引编号 a) 首先进行"Consumer Id注册"。 b) 然后在"Consumer id 注册"节点下注册一个watch用来监听当前group中其他consumer的"退出"和"加入";只要此znode path下节点列表变更,都会触发此group下consumer的负载均衡.(比如一个consumer失效,那么其他consumer接管partitions)。 c) 在"Broker id 注册"节点下,注册一个watch用来监听broker的存活情况;如果broker列表变更,将会触发所有的groups下的consumer重新balance。
[zk: localhost:2181(CONNECTED) 11] ls /consumers [console-consumer-2034] [zk: localhost:2181(CONNECTED) 12] ls /consumers/console-consumer-2034/owners [topic2] [zk: localhost:2181(CONNECTED) 13] ls /consumers/console-consumer-2034/owners/topic2 [0, 1, 2] [zk: localhost:2181(CONNECTED) 14] get /consumers/console-consumer-2034/owners/topic2/0
2.10Consumer offset
/consumers/[groupId]/offsets/[topic]/[partitionId] -> long (offset)
用来跟踪每个consumer目前所消费的partition中最大的offset。
此znode为持久节点,可以看出offset跟group_id有关,以表明当消费者组(consumer group)中一个消费者失效,
重新触发balance,其他consumer可以继续消费。
[zk: localhost:2181(CONNECTED) 15] get /consumers/console-consumer-2034/offsets/topic2/0
2.11Re-assign partitions
[zk: localhost:2181(CONNECTED) 16] get /admin/reassign_partitions
{ "fields":[ { "name":"version", "type":"int", "doc":"version id" }, { "name":"partitions", "type":{ "type":"array", "items":{ "fields":[ { "name":"topic", "type":"string", "doc":"topic of the partition to be reassigned" }, { "name":"partition", "type":"int", "doc":"the partition to be reassigned" }, { "name":"replicas", "type":"array", "items":"int", "doc":"a list of replica ids" } ], } "doc":"an array of partitions to be reassigned to new replicas" } } ] } Example: { "version": 1, "partitions": [ { "topic": "Foo", "partition": 1, "replicas": [0, 1, 3] } ] }
2.12Preferred replication election
[zk: localhost:2181(CONNECTED) 17] get /admin/preferred_replica_election
{ "fields":[ { "name":"version", "type":"int", "doc":"version id" }, { "name":"partitions", "type":{ "type":"array", "items":{ "fields":[ { "name":"topic", "type":"string", "doc":"topic of the partition for which preferred replica election should be triggered" }, { "name":"partition", "type":"int", "doc":"the partition for which preferred replica election should be triggered" } ], } "doc":"an array of partitions for which preferred replica election should be triggered" } } ] } 例子: { "version": 1, "partitions": [ { "topic": "Foo", "partition": 1 }, { "topic": "Bar", "partition": 0 } ] }
2.13删除topics
[zk: localhost:2181(CONNECTED) 18] get /admin/delete_topics
Schema: { "fields": [ {"name": "version", "type": "int", "doc": "version id"}, {"name": "topics", "type": { "type": "array", "items": "string", "doc": "an array of topics to be deleted"} } ] } 例子: { "version": 1, "topics": ["foo", "bar"] }
2.14Topic配置
/config/topics/[topic_name]
[zk: localhost:2181(CONNECTED) 19] get /config/topics/topic2
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- InnoDB 存储引擎的事务学习
- InnoDB 存储引擎的文件学习
- 学习 Alluxio(三):HDFS 底层存储
- InnoDB 存储引擎的锁学习
- Prometheus学习系列(二十四)之存储
- DOCKER学习_014:Docker存储补充
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。