kafka笔记-Kafka在zookeeper中的存储结构【转】

参考链接：apache kafka系列之在zookeeper中存储结构  http://blog.csdn.net/lizhitao/article/details/23744675

1.topic注册信息

/brokers/topics/[topic] :

存储某个topic的partitions所有分配信息

Schema:

{
    "version": "版本编号目前固定为数字1",
    "partitions": {
        "partitionId编号": [
            同步副本组brokerId列表
        ],
        "partitionId编号": [
            同步副本组brokerId列表
        ],
        .......
    }
}

Example:

{
"version": 1,
"partitions": {
"0": [1, 2],
"1": [2, 1],
"2": [1, 2],
}
}

说明：紫红色为patitions编号，蓝色为同步副本组brokerId列表

2.partition状态信息

/brokers/topics/[topic]/partitions/[0...N]  其中[0..N]表示partition索引号

/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": 2,
"version": 1,
"leader_epoch": 0,
"isr": [2, 1]
}

3. Broker注册信息

/brokers/ids/[0...N]

每个broker的配置文件中都需要指定一个数字类型的id(全局不可重复),此节点为临时znode(EPHEMERAL)

Schema:

{
"jmx_port": jmx端口号,
"timestamp": kafka broker初始启动时的时间戳,
"host": 主机名或ip地址,
"version": 版本编号默认为1,
"port": kafka broker的服务端端口号,由server.properties中参数port确定
}

Example:

{
"jmx_port": 6061,

"timestamp":"1403061899859"
"version": 1,
"host": "192.168.1.148",
"port": 9092
}

4. Controller epoch:

/controller_epoch -> int (epoch)

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

5. Controller注册信息:

/controller -> int (broker id of the controller)  存储center controller中央控制器所在kafka broker的信息

Schema:

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

Example:

{
"version": 1,
"brokerid": 3,
"timestamp": "1403061802981"
}

Consumer and Consumer group概念:

a.每个consumer客户端被创建时,会向zookeeper注册自己的信息;
b.此作用主要是为了"负载均衡".
c.同一个Consumer Group中的Consumers，Kafka将相应Topic中的每个消息只发送给其中一个Consumer。
d.Consumer Group中的每个Consumer读取Topic的一个或多个Partitions，并且是唯一的Consumer；
e.一个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会出现空闲状态。

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)]

6. 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;

Schema:

{
"version": 版本编号默认为1,
"subscription": { //订阅topic列表
"topic名称": consumer中topic消费者线程数
},
"pattern": "static",
"timestamp": "consumer启动时的时间戳"
}

Example:

{
"version": 1,
"subscription": {
"open_platform_opt_push_plus1": 5
},
"pattern": "static",
"timestamp": "1411294187842"
}
 

7. Consumer owner:

/consumers/[groupId]/owners/[topic]/[partitionId] -> consumerIdString + threadId索引编号

当consumer启动时,所触发的操作:

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.

8. Consumer offset:

/consumers/[groupId]/offsets/[topic]/[partitionId] -> long (offset)

用来跟踪每个consumer目前所消费的partition中最大的offset

此znode为持久节点,可以看出offset跟group_id有关,以表明当消费者组(consumer group)中一个消费者失效,

重新触发balance,其他consumer可以继续消费.

9. Re-assign partitions

/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]

        }

     ]            

}

10. Preferred replication election

/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

        }

     ]            

}

11. 删除topics
/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"]

}

Topic配置

/config/topics/[topic_name]

例子

{

  "version": 1,

  "config": {

    "config.a": "x",

    "config.b": "y",

    ...

  }

}

 请注明转载自:http://blog.csdn.NET/lizhitao/article/details/23744675

时间： 2024-11-05 08:55:47

kafka笔记-Kafka在zookeeper中的存储结构【转】的相关文章

kafka在zookeeper中的存储结构

参考site:http://kafka.apache.org/documentation.html#impl_zookeeper 1.zookeeper客户端相关命令 在确保zookeeper服务启动状态下,通过 bin/zkCli.sh -server 127.0.0.1:2181 该命令来连接客户端 简单操作如下: 1. 显示根目录下.文件: ls /  使用 ls 命令来查看当前 ZooKeeper 中所包含的内容 2. 显示根目录下.文件: ls2 / 查看当前节点数据并能看到更新次数等

Twitter Storm源代码分析之ZooKeeper中的目录结构

徐明明博客:Twitter Storm源代码分析之ZooKeeper中的目录结构 我们知道Twitter Storm的所有的状态信息都是保存在Zookeeper里面,nimbus通过在zookeeper上面写状态信息来分配任务,supervisor,task通过从zookeeper中读状态来领取任务,同时supervisor, task也会定义发送心跳信息到zookeeper, 使得nimbus可以监控整个storm集群的状态, 从而可以重启一些挂掉的task.ZooKeeper 使得整个sto

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, broker

《大话数据结构》笔记（7-2）--图：存储结构

第七章  图 图的存储结构 图不能用简单的顺序存储结构来表示. 而多重链表的方式,即以一个数据域和多个指针域组成的结点表示图中的一个顶点,尽管可以实现图结构,但是会有问题,比如若各个顶点的度数相差很大,按度数最大的顶点设计结点结构会造成很多存储单元的浪费,而若按每个顶点自己的度数设计不同的顶点结构,又带来操作的不便. 对于图来说,如何对它实现物理存储是个难题.图有以下五种不同的存储结构. 邻接矩阵 图的邻接矩阵(Adjacency Matrix)存储方式使用过两个数组来表示图.一个一维数组存储图

【Java数据结构学习笔记之一】线性表的存储结构及其代码实现

应用程序后在那个的数据大致有四种基本的逻辑结构: 集合:数据元素之间只有"同属于一个集合"的关系 线性结构:数据元素之间存在一个对一个的关系 树形结构:数据元素之间存在一个对多个关系 图形结构或网状结构:数据元素之间存在多个对多个的关系 对于数据不同的逻辑结构,计算机在物理磁盘上通常有两种屋里存储结构 顺序存储结构 链式存储结构 本篇博文主要讲的是线性结构,而线性结构主要是线性表,非线性结构主要是树和图. 线性表的基本特征: 总存在唯一的第一个数据元素 总存在唯一的最后一个数据元素 除

Apache kafka系列之在zookeeper中存储结构

1.topic注册信息 /brokers/topics/[topic] :存储某个topic的partitions所有分配信息 Schema: { "version": "版本编号目前固定为数字1", "partitions": { "partitionId编号": [ 同步副本组brokerId列表 ], "partitionId编号": [ 同步副本组brokerId列表 ], ....... } }

iOS中keychain存储结构的研究

keychain在ios中是保存在sqlite数据库中的. 这个数据库文件的位置: 真机: /private/var/Keychains/keychain-2.db 虚拟机: /Users/USER-HOME/Library/Developer/CoreSimulator/Devices/26DCA62C-B516-4DEA-A601-5C2D0EA07710/data/Library/Keychains/keychain-2-debug.db 在虚拟机中,这个数据库考出来就不能读了,很奇怪.

Objective-C基础笔记（7)Foundation中的常用结构体

一.NSRange NSRange的定义: typedef struct _NSRange { NSUInteger location; NSUInteger length; } NSRange; NSRanage的使用: NSRange range = NSMakeRange(8, 10); NSLog(@"location:%zi", range.location); NSLog(@"length:%zi", range.length); NSString *s

深入解析 ObjC 中方法的结构

因为 ObjC 的 runtime 只能在 Mac OS 下才能编译,所以文章中的代码都是在 Mac OS,也就是 x86_64 架构下运行的,对于在 arm64 中运行的代码会特别说明. 在上一篇分析 isa 的文章从 NSObject 的初始化了解 isa中曾经说到过实例方法被调用时,会通过其持有 isa 指针寻找对应的类,然后在其中的 class_data_bits_t 中查找对应的方法,在这一篇文章中会介绍方法在 ObjC 中是如何存储方法的. 这篇文章的首先会根据 ObjC 源代码来分