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

徐明明博客:Twitter Storm源代码分析之ZooKeeper中的目录结构

  我们知道Twitter Storm的所有的状态信息都是保存在Zookeeper里面,nimbus通过在zookeeper上面写状态信息来分配任务,supervisor,task通过从zookeeper中读状态来领取任务,同时supervisor, task也会定义发送心跳信息到zookeeper, 使得nimbus可以监控整个storm集群的状态, 从而可以重启一些挂掉的task。ZooKeeper 使得整个storm集群十分的健壮 — 任何一台工作机器挂掉都没有关系,只要重启然后从zookeeper上面重新获取状态信息就可以了。

  本文主要介绍Twitter Storm在ZooKeeper中保存的数据目录结构,源代码主要是: backtype.storm.cluster

  一个要注意的地方是,作者在代码里面很多地方用到的storm-id, 其实就是topology-id的意思。我在邮件列表里面问了他一下, 他说以前他把topology叫做storm, 代码里面还没有改过来。

直接看下面的结构图:

 1 /-{storm-zk-root}           -- storm在zookeeper上的根
 2   |                            目录
 3   |
 4   |-/assignments            -- topology的任务分配信息
 5   |   |
 6   |   |-/{topology-id}      -- 这个下面保存的是每个
 7   |                            topology的assignments
 8   |                            信息包括: 对应的
 9   |                            nimbus上的代码目录,所有
10   |                            task的启动时间,
11   |                            每个task与机器、端口的映射
12   |
13   |-/tasks                  -- 所有的task
14   |   |
15   |   |-/{topology-id}      -- 这个目录下面id为
16   |       |                    {topology-id}的topology
17   |       |                    所对应的所有的task-id
18   |       |
19   |       |-/{task-id}      -- 这个文件里面保存的是这个
20   |                            task对应的component-id:
21   |                            可能是spout-id或者bolt-id
22   |
23   |-/storms                 -- 这个目录保存所有正在运行
24   |   |                        的topology的id
25   |   |
26   |   |-/{topology-id}      -- 这个文件保存这个topology
27   |                            的一些信息,包括topology的
28   |                            名字,topology开始运行的时
29   |                            间以及这个topology的状态
30   |                            (具体看StormBase类)
31   |
32   |-/supervisors            -- 这个目录保存所有的supervisor
33   |   |                        的心跳信息
34   |   |
35   |   |-/{supervisor-id}    -- 这个文件保存的是supervisor
36   |                            的心跳信息包括:心跳时间,主
37   |                            机名,这个supervisor上worker
38   |                            的端口号运行时间
39   |                            (具体看SupervisorInfo类)
40   |
41   |-/taskbeats              -- 所有task的心跳
42   |   |
43   |   |-/{topology-id}      -- 这个目录保存这个topology的所
44   |       |                    有的task的心跳信息
45   |       |
46   |       |-/{task-id}      -- task的心跳信息,包括心跳的时
47   |                            间,task运行时间以及一些统计
48   |                            信息
49   |
50   |-/taskerrors             -- 所有task所产生的error信息
51       |
52       |-/{topology-id}      -- 这个目录保存这个topology下面
53           |                    每个task的出错信息
54           |
55           |-/{task-id}      -- 这个task的出错信息
时间: 2025-01-10 18:57:21

Twitter Storm源代码分析之ZooKeeper中的目录结构的相关文章

Storm入门(十一)Twitter Storm源代码分析之CoordinatedBolt

作者: xumingming | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明网址: http://xumingming.sinaapp.com/811/twitter-storm-code-analysis-coordinated-bolt/ 关于Twitter Storm的新特性: Transactional Topology 被问到的最多的问题是: Storm是怎么知道一个Bolt处理完成了它所有的tuple的? 其实要做到这一点还是有蛮多事情要做的, 幸运的是Sto

iOS项目开发过程中的目录结构(转)

iOS项目开发过程中的目录结构 我在这个目录结构方面真是吃了不少苦,开始总是觉得快点写快点写,后来发现只有快是不行的,在没有给整个项目的结构有一个清楚的认识和了解之前就匆匆动笔(敲代码啦)是非常冒失的, 好在在后来修改的过程中慢慢琢磨出来一套目录结构,现在发出来给大家参考一下. 项目主目录结构如图: 1.Network主要用于进行网络请求,以及请求完成后对数据进行处理使用, 2.Category:类目,这个文件夹放在这里我觉得是不太准确的,但是具体应该放在哪里我一直无法确实下来 3.Contro

Storm在zookeeper上的目录结构

storm操作zookeeper的主要函数都定义在命名空间backtype.storm.cluster中(即cluster.clj文件中). backtype.storm.cluster定义了两个重要protocol:ClusterState和StormClusterState.clojure中的protocol可以看成java中的接口,封装了一组方法.ClusterState协议中封装了一组与zookeeper进行交互的基础函数,如获取子节点函数,获取子节点数据函数等,ClusterState

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": {        &q

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 / 查看当前节点数据并能看到更新次数等

Android项目在Eclipse中的目录结构

src/ 存放源代码的地方. bin/ 编译后的输出目录.这里你可以找到.apk文件和其他编译后的资源. gen/ 包含R.java文件,这个文件是由ADT自动生成的,请不要随意修改它 assets/ 你能在这里放入原始的asset 文件.例如一些文档,这里的文件会保留原来的文件名被编译到.apk文件中,并且你还能使用文件系统的URL机制来读取文件,例如使用AssetManager类来读取一个字节流. res/ 包含应用程序的资源,如drawable文件, layout文件, string值.

MySQL 5.7 源码中的目录结构

MySQl Server的源码可以直接去Github浏览. 这里我们选择5.7版本的:https://github.com/mysql/mysql-server/tree/5.7 也可以通过: git clone https://github.com/mysql/mysql-server.git 下载下来. 源码根目录中主要目录和文件的作用: BUILD:里面包含各个平台,各个编译器下进行编译的脚本: CMakeLists.txt:CMake入口编译文件: client:客户端工具,所有客户端工

浅谈android中的目录结构

在开发android应用的过程中,总要去调试APP,安装时又想去了解android的目录结构.然后搜到了一点材料. 原文地址:http://www.hiapk.com/viewthread.php?tid=465392&page=4 Google Android手机的软件为了安全性和稳定性都是默认安装到手机内存里,但是手机内存有限,所以我们会做app2sd操作,来让我们安装的软件放到sd卡上,这个操作是需要rom的支持的.    Android 2.2 可以将手机程序安装在外置的sd卡上,也就是

storm源代码分析---Transactional spouts

Transactionalspouts Trident是以小批量(batch)的形式在处理tuple.而且每一批都会分配一个唯一的transaction id.不同spout的特性不同,一个transactionalspout会有例如以下这些特性: 1.有着相同txid的batch一定是一样的. 当重播一个txid相应的batch时,一定会重播和之前相应txid的batch中相同的tuples. 2.各个batch之间是没有交集的.每一个tuple仅仅能属于一个batch 3.每个tuple都属