Kafka学习之路 （五）Kafka在zookeeper中的存储

当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.1　topic注册信息

/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.2　partition状态信息

/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.3　Broker注册信息

/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.4　Controller epoch

[zk: localhost:2181(CONNECTED) 6] get /controller_epoch
1

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

2.5　Controller注册信息

存储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.7　Consumer均衡算法

当一个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.8　Consumer注册信息

每个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.9　Consumer 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.10　Consumer 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.11　Re-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.12　Preferred 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.14　Topic配置

/config/topics/[topic_name]

[zk: localhost:2181(CONNECTED) 19] get /config/topics/topic2

原文地址：http://blog.51cto.com/13525470/2315459

时间： 2024-10-12 14:44:40

Kafka学习之路 （五）Kafka在zookeeper中的存储的相关文章

kafka学习之路

https://www.cnblogs.com/qingyunzong/p/9004509.html 目录 一.简介 1.1 概述 1.2 消息系统介绍 1.3 点对点消息传递模式 1.4 发布-订阅消息传递模式 二.Kafka的优点 2.1 解耦 2.2 冗余(副本) 2.3 扩展性 2.4 灵活性&峰值处理能力 2.5 可恢复性 2.6 顺序保证 2.7 缓冲 2.8 异步通信 三.常用Message Queue对比 3.1 RabbitMQ 3.2 Redis 3.3 ZeroMQ 3.4

kafka学习之路（二）——提高

kafka学习之路(二)--提高 消息发送流程 因为Kafka内在就是分布式的,一个Kafka集群通常包括多个代理.为了均衡负载,将话题分成多个分区,每个代理存储一或多个分区.多个生产者和消费者能够同时生产和获取消息.     过程: 1.Producer根据指定的partition方法(round-robin.hash等),将消息发布到指定topic的partition里面 2.kafka集群接收到Producer发过来的消息后,将其持久化到硬盘,并保留消息指定时长(可配置),而不关注消息是否

Android的学习之路（二）项目中原生文件的使用场景和文件介绍

1.src文件:java源代码存放目录 2.gen 文件:自动生成所有由android开发工具自动生成的文件,目录中最重要的就是R.java文件,这个文件由android开 发工具自动产生的.android开发工具会自动根据你存放res目录的资源,同步更新修稿R.java文件,正因为 R.java文件是由开发工具自动生成的,所以我们应避免手工修改R.java.R.java文件在应用中起到了字典的作 用,它包含了各种资源的ID,通过R.java,应用可以很方便的找到对应资源, 2.1R.java 

《代码大全》学习摘要（五）软件构建中的设计（下）

这次的学习内容主要是设计过程中的启发式方法和设计实践中的一些经验. 对于具体的编程工作来说,期待确定性的行为是很正常的,由于软件设计是非确定性的,灵活熟练地运用一组有效的启发方法(试探法),便成了合理的软件设计的核心工作. 1.在确定设计方案时,首选且最流行的方法是面向对象的方法,此方法的要点是辨别现实世界中的对象以及人造的对象.这个过程分为以下几步:辨识对象及其属性.确定可以对各个对象进行的操作.确定各个对象能对其他对象进行的操.确定对象的哪些部分对其他对象可见.定义每个对象的公开接口. 2.

Kafka学习之路 （二）Kafka的架构

一.Kafka的集群架构 如上图所示,一个典型的Kafka集群中包含若干Producer(可以是web前端产生的Page View,或者是服务器日志,系统CPU.Memory等),若干broker(Kafka支持水平扩展,一般broker数量越多,集群吞吐率越高),若干Consumer Group,以及一个Zookeeper集群.Kafka通过Zookeeper管理集群配置,选举leader,以及在Consumer Group发生变化时进行rebalance.Producer使用push模式将消

Kafka学习之路 （四）Kafka的安装

zookeeper1:192.168.1.11 zookeeper2:192.168.1.12 zookeeper3:192.168.1.13 kafka1:192.168.1.14 kafka2:192.168.1.15 kafka3:192.168.1.16 kafka3:192.168.1.17 kafka-manager:192.168.1.18 一.下载 下载地址: http://kafka.apache.org/downloads.html http://mirrors.hust.e

Kafka学习之路 （三）Kafka的高可用

一.高可用的由来 1.1 为何需要Replication 在Kafka在0.8以前的版本中,是没有Replication的,一旦某一个Broker宕机,则其上所有的Partition数据都不可被消费,这与Kafka数据持久性及Delivery Guarantee的设计目标相悖.同时Producer都不能再将数据存于这些Partition中. 如果Producer使用同步模式则Producer会在尝试重新发送message.send.max.retries(默认值为3)次后抛出Exception,

kafka学习之路（三）——高级

设计原理 kafka的设计初衷是希望作为一个统一的信息收集平台,能够实时的收集反馈信息,并需要能够支撑较大的数据量,且具备良好的容错能力. 持久性 kafka使用文件存储消息,这就直接决定kafka在性能上严重依赖文件系统的本身特性.且无论任何OS下,对文件系统本身的优化几乎没有可能.文件缓存/直接内存映射等是常用的手段.因为kafka是对日志文件进行append操作,因此磁盘检索的开支是较小的;同时为了减少磁盘写入的次数,broker会将消息暂时buffer起来,当消息的个数(或尺寸)达到一定

kafka 学习之路 第一篇

kafka官网:http://kafka.apache.org/ 下载地址:http://mirrors.hust.edu.cn/apache/kafka/0.10.2.0/kafka_2.12-0.10.2.0.tgz 未完待续