【Streaming】Storm内部通信机制分析

一、任务执行及通信的单元

Storm中关于任务执行及通信的三个概念:Worker(进程)、Executor(线程)和Task(Spout、Bolt)

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

2、  Executor是一个被Worker进程启动的单独线程,每个executor只会运行一个topology的一个component(spout或bolt)的task(task可以是一个或多个,Storm默认是一个component只生成一个task,executor线程会在每次循环里顺序调用所有task实例);

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

二、Storm内部通信机制简单介绍

1、  同一worker间消息的发送使用的是LMAX Disruptor,它负责同一节点(同一进程内)上线程间的通信;

A、Disruptor使用了一个RingBuffer替代队列,用生产者消费者指针替代锁。

B、生产者消费者指针使用CPU支持的整数自增,无需加锁并且速度很快。Java的实现在Unsafe package中。

2、  不同worker间通信使用ZeroMQ(0.8)或Netty(0.9.0);

3、  不同topologey之间的通信,Storm不负责,我们需要自己想办法实现,例如使用kafka等;

Worker进程内部的结构图如下所示:

每一个worker进程都有一个单独的线程来监听该worker的端口号,并接收发送到该端口的数据,它将通过网络发送过来的数据放到worker的接收队列里面。

它监听的端口号是通过supervisor.slots.ports定义的。

接收队列的大小是通过topology.receiver.buffer.size定义的,默认值为8.

Disruptor在Storm中的应用如下图所示:

三、与通信相关的几个配置项介绍:

1、  supervisor.slots.ports:worker进程的接收线程的监听端口;

2、  topology.receiver.buffer.size:worker接收线程缓存消息的大小,它将该缓存消息发送给executor线程;需要为2的倍数

3、  topology.transfer.buffer.size:worker进程中向外发送消息的缓存大小;

4、  topology.executor.receive.buffer.size:executor线程的接收队列大小;需要为2的倍数

5、  topology.executor.send.buffer.size:executor线程的发送队列大小;需要为2的倍数

http://www.michael-noll.com/blog/2013/06/21/understanding-storm-internal-message-buffers/文章中作者给出的初始建议配置如下:

Try the following settings as a first start and see whether it improves the performance of your Storm topology

conf.put(Config.TOPOLOGY_RECEIVER_BUFFER_SIZE,             8);

conf.put(Config.TOPOLOGY_TRANSFER_BUFFER_SIZE,            32);

conf.put(Config.TOPOLOGY_EXECUTOR_RECEIVE_BUFFER_SIZE, 16384);

conf.put(Config.TOPOLOGY_EXECUTOR_SEND_BUFFER_SIZE,    16384);

文章出处http://support.huawei.com/huaweiconnect/enterprise/thread-327549.html

时间: 2024-11-09 06:10:19

【Streaming】Storm内部通信机制分析的相关文章

storm - 可靠机制

一 可靠性简介 Storm的可靠性是指Storm会告知用户每一个消息单元是否在一个指定的时间(timeout)内被完全处理.完全处理的意思是该MessageId绑定的源Tuple以及由该源Tuple衍生的所有Tuple都经过了Topology中每一个应该到达的Bolt的处理. 注: timetout 可以通过Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS 来指定 Storm中的每一个Topology中都包含有一个Acker组件.Acker组件的任务就是跟踪从某个task

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

Darwin Streaming Server源码分析

2     Darwin流化服务器介绍DSS源代码完全采用标准C++语言写成,编程风格非常优秀,每个C++类都对应着一对和类同名的.h/.cpp文件.但是由于大量采用了面向对象的概念,如继承.多态等等:而且源文件和类相当多,所以不太容易讲清楚.因此,读者最好事先把代码完整的过滤一两遍,再配合本文,就能看得更清楚点.其中,最为重要的是基础功能类库(CommonUtilitiesLib)和流化服务器(StreamingServer)两个工程,前者是整个系统的通用代码工具箱,包括了线程管理.数据结构.

QT开发(六十三)——QT事件机制分析

QT开发(六十三)--QT事件机制分析 一.事件机制 事件是由系统或者QT平台本身在不同的时刻发出的.当用户按下鼠标.敲下键盘,或者是窗口需要重新绘制的时候,都会发出一个相应的事件.一些事件在对用户操作做出响应时发出,如键盘事件等:另一些事件则是由系统自动发出,如计时器事件. 事件的出现,使得程序代码不会按照原始的线性顺序执行.线性顺序的程序设计风格不适合处理复杂的用户交互,如用户交互过程中,用户点击"打开文件"将开始执行打开文件的操作,用户点击"保存文件"将开始执

Linux通信之poll机制分析

poll机制分析 韦东山 2009.12.10 所有的系统调用,基于都可以在它的名字前加上"sys_"前缀,这就是它在内核中对应的函数.比如系统调用open.read.write.poll,与之对应的内核函数为:sys_open.sys_read.sys_write.sys_poll. 一.内核框架: 对于系统调用poll或select,它们对应的内核函数都是sys_poll.分析sys_poll,即可理解poll机制. sys_poll函数位于fs/select.c文件中,代码如下:

Storm实时日志分析实战

项目背景 最近公司做一个项目,用户需要对网站访问者的广告点击/浏览记录进行实时统计分析,分析结果存入数据库,输出报表.我们采用了Kafka+Storm+Zookeeper的解决方案.之前没有接触过,经过一段时间的研究,最终完成了项目.接下来的内容我将介绍我们的解决方案.供大家参考.我们的系统结构如下: 总体结构介绍 业务系统把点击/浏览广告业务日志统一按规定的格式发送到Kafka集群中,不同的业务日志可以分别发送给Kafka不同的主题.Storm集群中运行了我们的实时统计拓扑,该统计拓扑分别从K

Nginx处理stale事件机制分析

Nginx为提高效率采用描述符缓冲池(连接池)来处理tcp连接,一个连接对应一个读事件和一个写事件,nginx在启动的时候会创建好所用连接和事件,当事件来的时候不用再创建,然而连接池的使用却存在stale事件的问题,以下将详细分析Nginx是如何处理stale事件的,该问题涉及到epoll.Nginx连接与事件的相关知识. 1      Epoll的实现原理 epoll相关的系统调用有:epoll_create, epoll_ctl和epoll_wait.Linux-2.6.19又引入了可以屏蔽

Linux x86_64 APIC中断路由机制分析

不同CPU体系间的中断控制器工作原理有较大差异,本文是<Linux mips64r2 PCI中断路由机制分析>的姊妹篇,主要分析Broadwell-DE X86_64 APIC中断路由原理.中断配置和处理过程,并尝试回答如下问题: 为什么x86中断路由使用IO-APIC/LAPIC框架,其有什么价值? pin/irq/vector的区别.作用,取值范围和分配机制? x86_64 APIC关键概念 Pin 此处的pin特指APIC的中断输入引脚,与内外部设备的中断输入信号相连.从上图中可以看出,

[转]易语言消息机制分析(消息拦截原理)

标 题: [原创]易语言消息机制分析(消息拦截原理)作 者: 红绡枫叶时 间: 2014-12-17,12:41:44链 接: http://bbs.pediy.com/showthread.php?t=195626 我自己做了个易语言的sig签名,方便分析的时候用.易语言例子是静态编译的.版本 5.11易语言其实是基于mfc的,它依然需要mfc的消息派发机制,只不过,自己当了系统与用户间的代理人.所有的消息都要经它转发而已.我在MFC的消息派发函数_AfxDispatchCmdMsg下断点,总