storm源码之理解Storm中Worker、Executor、Task关系【转】

【原】storm源码之理解Storm中Worker、Executor、Task关系

Storm在集群上运行一个Topology时,主要通过以下3个实体来完成Topology的执行工作:
1. Worker(进程
2. Executor(线程
3. Task

下图简要描述了这3者之间的关系:
                                                   

1个worker进程执行的是1个topology的子集(注:不会出现1个worker为多个topology服务)。1个worker进程会启动1个或多个executor线程来执行1个topology的component(spout或bolt)。因此,1个运行中的topology就是由集群中多台物理机上的多个worker进程组成的。

executor是1个被worker进程启动的单独线程。每个executor只会运行1个topology的1个component(spout或bolt)的task(注:task可以是1个或多个,storm默认是1个component只生成1个task,executor线程里会在每次循环里顺序调用所有task实例)。

task是最终运行spout或bolt中代码的单元(注:1个task即为spout或bolt的1个实例,executor线程在执行期间会调用该task的nextTuple或execute方法)。topology启动后,1个component(spout或bolt)的task数目是固定不变的,但该component使用的executor线程数可以动态调整(例如:1个executor线程可以执行该component的1个或多个task实例)。这意味着,对于1个component存在这样的条件:#threads<=#tasks(即:线程数小于等于task数目)。默认情况下task的数目等于executor线程数目,即1个executor线程只运行1个task。

参考:https://github.com/nathanmarz/storm/wiki/Understanding-the-parallelism-of-a-Storm-topology

时间: 2024-09-30 00:07:29

storm源码之理解Storm中Worker、Executor、Task关系【转】的相关文章

从源码层理解Hashtable中的put和get

首先我们先看put方法:将指定 key 映射到此哈希表中的指定 value.注意这里键key和值value都不可为空. [java] view plain copy print? public synchronized V put(K key, V value) { // 确保value不为null if (value == null) { throw new NullPointerException(); } /* * 确保key在table[]是不重复的 * 处理过程: * 1.计算key的

storm源码之storm代码结构【译】【转】

[原]storm源码之storm代码结构[译] 说明:本文翻译自Storm在GitHub上的官方Wiki中提供的Storm代码结构描述一节Structure of the codebase,希望对正在基于Storm进行源码级学习和研究的朋友有所帮助. Storm的源码共分为三个不同的层次. 首先,Storm在设计之初就考虑到了兼容多语言开发.Nimbus是一个thrift服务,topologies被定义为Thrift结构体.Thrift的运用使得Storm可以被任意开发语言使用. 其次,Stor

storm源码分析之任务分配--task assignment

在"storm源码分析之topology提交过程"一文最后,submitTopologyWithOpts函数调用了mk-assignments函数.该函数的主要功能就是进行topology的任务分配(task assignment).mk-assignments函数定义如下: ;; get existing assignment (just the executor->node+port map) -> default to {};; filter out ones whi

storm源码之storm代码结构【译】

说明:本文翻译自Storm在GitHub上的官方Wiki中提供的Storm代码结构描述一节Structure of the codebase,希望对正在基于Storm进行源码级学习和研究的朋友有所帮助. Storm的源码共分为三个不同的层次. 首先,Storm在设计之初就考虑到了兼容多语言开发.Nimbus是一个thrift服务,topologies被定义为Thrift结构体. Thrift优势 : 使得Storm可以被任意开发语言使用. 其次,Storm的所有接口都是Java语言来定义的.因此

storm源码之一个class解决nimbus单点问题【转】

[原]storm源码之一个class解决nimbus单点问题 一.storm nimbus 单节点问题概述 1.storm集群在生产环境部署之后,通常会是如下的结构:                                         从图中可以看出zookeeper和supervisor都是多节点,任意1个zookeeper节点宕机或supervisor节点宕机均不会对系统整体运行造成影响,但nimbus和ui都是单节点.ui的单节点对系统的稳定运行没有影响,仅提供storm-ui

JStorm与Storm源码分析(四)--均衡调度器,EvenScheduler

EvenScheduler同DefaultScheduler一样,同样实现了IScheduler接口, 由下面代码可以看出: (ns backtype.storm.scheduler.EvenScheduler (:use [backtype.storm util log config]) (:require [clojure.set :as set]) (:import [backtype.storm.scheduler IScheduler Topologies Cluster Topolo

Storm源码分析--Nimbus-data

nimbus-datastorm-core/backtype/storm/nimbus.clj (defn nimbus-data [conf inimbus] (let [forced-scheduler (.getForcedScheduler inimbus)] {:conf conf :inimbus inimbus ; INimbus实现类, standalone-nimbus的返回值 :submitted-count (atom 0) ; 已经提交的计算拓扑的数量, 初始值为原子值0

Apache Storm源码阅读笔记

欢迎转载,转载请注明出处. 楔子 自从建了Spark交流的QQ群之后,热情加入的同学不少,大家不仅对Spark很热衷对于Storm也是充满好奇.大家都提到一个问题就是有关storm内部实现机理的资料比较少,理解起来非常费劲. 尽管自己也陆续对storm的源码走读发表了一些博文,当时写的时候比较匆忙,有时候衔接的不是太好,此番做了一些整理,主要是针对TridentTopology部分,修改过的内容采用pdf格式发布,方便打印. 文章中有些内容的理解得益于徐明明和fxjwind两位的指点,非常感谢.

Storm源码阅读之SpoutOutputCollector

不得不说storm是一个特别棒的实时计算框架.为了对后文理解的方便,先说几个storm中的术语: Topology:拓扑图或者拓扑结构.在storm中它通过消息分组的分式连接Spout和Bolt节点定义了运算处理的拓扑结构.如下图: 那什么是Spout呢? 在计算任务需要的数据其实就是由Spout提供的,所以它可以说是Storm中的消息源,一般是从外部数据源(日志文件.数据库.消息队列等等)不间断地读取数据然后发送给tuple元组的. 那它是通过谁发送的呢?又是如何发送的呢? 这里我们先回答第一