kafka在ZK中存存储节点及作用

2019年6月9日 460次阅读 来源: 开心就好_4ad7

    kafka集群依赖于ZOOKEEPER，了解kafka在zookeeper中的一些存储结构，便于更好的理解kafka的工作原理，zookeeper在kafka中扮演了举足轻重的作用(0.9版本后offest不放在zk上,由kafka内部topic自己保存),kakfa的 broker,消费者等相关的信息都存在zk的节点上,zk还提供了对kafka的动态负载均衡等机制，以下是我的测试环境ZK截取目录结构：

《kafka在ZK中存存储节点及作用》 image.png

接下来分析一下每个节点的作用：

（1） controller_epoch

    此值为一个数字,kafka集群中第一个broker第一次启动时为1，以后只要集群中center controller中央控制器所在broker变更或挂掉，就会重新选举新的center controller，每次center controller变更controller_epoch值就会 + 1;

《kafka在ZK中存存储节点及作用》 image.png

（2）controller

    存储控制器broker信息，数据格式为：

{"version":1,"brokerid":0,"timestamp":"1524191485779"}
version: 版本编号默认为1,
brokerid: kafka集群中broker唯一编号,
timestamp: kafka broker中央控制器变更时的时间戳

（3）brokers/topics

    当一个broker启动时,会向zookeeper注册自己持有的topic和partitions信息，如下：

《kafka在ZK中存存储节点及作用》 image.png

  • test：topic名称
  • partitions：分区列表，当前只有一个分区”0“
  • state：Kafka的ISR的管理最终都会反馈到Zookeeper节点上。目前有两个地方会对该节点进行维护：
{"controller_epoch":1,"leader":0,"version":1,"leader_epoch":0,"isr":[0]}
  • Controller来维护：Kafka集群中的其中一个Broker会被选举为Controller，主要负责Partition管理和副本状态管理，也会执行类似于重分配partition之类的管理任务。在符合某些特定条件下，Controller下的LeaderSelector会选举新的leader，ISR和新的leader_epoch及controller_epoch写入Zookeeper的相关节点中。同时发起LeaderAndIsrRequest通知所有的replicas。
  • leader来维护：leader有单独的线程定期检测ISR中follower是否脱离ISR, 如果发现ISR变化，则会将新的ISR的信息返回到Zookeeper的相关节点中。

（4）brokers/ids

    每个broker的配置文件中都需要指定一个数字类型的id(全局不可重复),此节点为临时znode(EPHEMERAL)，存放的内容格式如下。

{
    "listener_security_protocol_map": {
        "PLAINTEXT": "PLAINTEXT"
    },
    "endpoints": ["PLAINTEXT://hostname:port"],
    "jmx_port": -1,
    "host": "host ip",
    "timestamp": "1524191485634",
    "port": port,
    "version": 4
}

（5）brokers/topics/_consumer_offsets

    新版kafka将消费者的位置信息（offset）保存在kafka内部的topic中，就是这里的__consumer_offsets topic,并且提供了kafka-consumer-groups.sh供用户查看消费者信息。

《kafka在ZK中存存储节点及作用》 image.png

    原文作者：开心就好_4ad7
    原文地址: https://www.jianshu.com/p/da62e853c1ea
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞