Storm 内部消息缓存

这篇文件翻译自 http://www.michael-noll.com/blog/2013/06/21/understanding-storm-internal-message-buffers/

当进行Storm调优时,理解Storm内部消息队列的配置十分有帮助。这篇文件将说明在Storm 0.8/0.9版本中一个Worker内部的消息通信。

Storm Worker进程内部消息传输

这里所说的“内部消息”是指单台节点上的一个Worker进程内部的消息。这种通信依赖于Storm内部各种 LMAX Disrupter(高性能多线程消息库) 支持的消息队列。

单个Worker进程内部多线程通信不同于多个worker进程之间的通信。后者通常跨网络或者机器,Storm采用 Zero MQ/Netty进行支持。

  • Intra-worker communication in Storm (inter-thread on the same Storm node): LMAX Disruptor
  • Inter-worker communication (node-to-node across the network): ZeroMQ or Netty
  • Inter-topology communication: nothing built into Storm, you must take care of this yourself with e.g. a messaging system such as Kafka/RabbitMQ, a database, etc.

事例说明

Storm内部消息队列概要。Worker进程的消息队列标识为红色,Worker内部Executer的消息队列标识为绿色。图中为了可读性,只有一个Worker和一个Executor,而现实中通常有多个Worker,一个Worker中也可能有多个Executors。

详细描述

Worker进程

为了管理进来和出去的消息,每个Worker进程有一个监听TCP端口(configured by supervisor.slots.ports)的接收线程。类似的,每个Worker有一个发送线程负责将从transfer queue中读到的消息发送到下游消费者。

  • The topology.receiver.buffer.size is the maximum number of messages that are batched together at once for appending to an executor’s incoming queue by the worker receive thread (which reads the messages from the network) Setting this parameter too high may cause a lot of problems (“heartbeat thread gets starved, throughput plummets”). The default value is 8 elements, and the value must be a power of 2 (this requirement comes indirectly from LMAX Disruptor).
  • // Example: configuring via Java API
    Config conf = new Config();
    conf.put(Config.TOPOLOGY_RECEIVER_BUFFER_SIZE, 16); // default is 8
  • Each element of the transfer queue configured with topology.transfer.buffer.size is actually a list of tuples. The various executor send threads will batch outgoing tuples off their outgoing queues onto the transfer queue. The default value is 1024 elements.
  • // Example: configuring via Java API
    conf.put(Config.TOPOLOGY_TRANSFER_BUFFER_SIZE, 32); // default is 1024

Executors

一个Worker进程控制着一个或者多个Executer线程。每个Executor有自己的 incoming queue 和 outgoing queue

每个Executor有一个负责逻辑处理spout/bolt的线程, 一个接收消息线程,和一个发送消息线程。

  • The topology.executor.receive.buffer.size is the size of the incoming queue for an executor. Each element of this queue is a list of tuples. Here, tuples are appended in batch. The default value is 1024 elements, and the value must be a power of 2 (this requirement comes from LMAX Disruptor).
  • // Example: configuring via Java API
    conf.put(Config.TOPOLOGY_EXECUTOR_RECEIVE_BUFFER_SIZE, 16384); // batched; default is 1024
  • The topology.executor.send.buffer.size is the size of the outgoing queue for an executor. Each element of this queue will contain a single tuple. The default value is 1024 elements, and the value must be a power of 2 (this requirement comes from LMAX Disruptor).
  • // Example: configuring via Java API
    conf.put(Config.TOPOLOGY_EXECUTOR_SEND_BUFFER_SIZE, 16384); // individual tuples; default is 1024
时间: 11-23

Storm 内部消息缓存的相关文章

ack是什么,如何使用Ack机制,如何关闭Ack机制,基本实现,STORM的消息容错机制,Ack机制

1.ack是什么 ack 机制是storm整个技术体系中非常闪亮的一个创新点. 通过Ack机制,spout发送出去的每一条消息,都可以确定是被成功处理或失败处理, 从而可以让开发者采取动作.比如在Meta中,成功被处理,即可更新偏移量,当失败时,重复发送数据. 因此,通过Ack机制,很容易做到保证所有数据均被处理,一条都不漏. 另外需要注意的,当spout触发fail动作时,不会自动重发失败的tuple,需要spout自己重新获取数据,手动重新再发送一次 ack机制即, spout发送的每一条消

内部消息 微软中国云计算 内测Azure免费账号

内部消息 微软中国云计算 内测Azure免费账号!微软MSDN俱乐部 29754721, [一大波Azure免费账号来袭]Windows Azure再次开启发放免费试用账号,Windows Azure云平台的魅力吧! http://t.cn/RvPnQ2m没有的赶紧申请, 不要外传! 微软MSDN俱乐部 29754721, 微软中国Azure数据中心是 北京上海 2个一级骨干网络节点,阿里是二三线城市杭州和青岛 2.阿里是共享1-100M带宽收费,微软是直接一级骨干网的100G带宽免费 3.微软

内部消息 微软中国云计算 内测Azure免费账号 赶紧申请 错过不再有

内部消息 微软中国云计算 顶级内测Azure免费账号 火热申请 过期不再有!微软MSDN俱乐部  29754721, [一大波Azure免费账号来袭]Windows Azure再次开启发放免费试用账号,Windows Azure云平台的魅力吧! http://t.cn/RvPnQ2m 没有的赶紧申请, 不要外传! 微软MSDN俱乐部  29754721, 微软中国Azure数据中心是 北京上海 2个一级骨干网络节点,阿里是二三线城市杭州和青岛 2.阿里是共享1-100M带宽收费,微软是直接一级骨

STORM在线业务实践-集群空闲CPU飙高问题排查(转)

最近将公司的在线业务迁移到Storm集群上,上线后遇到低峰期CPU耗费严重的情况.在解决问题的过程中深入了解了storm的内部实现原理,并且解决了一个storm0.9-0.10版本一直存在的严重bug,目前代码已经合并到了storm新版本中,在这篇文章里会介绍这个问题出现的场景.分析思路.解决的方式和一些个人的收获. 背景 首先简单介绍一下Storm,熟悉的同学可以直接跳过这段. Storm是Twitter开源的一个大数据处理框架,专注于流式数据的处理.Storm通过创建拓扑结构(Topolog

STORM在线业务实践-集群空闲CPU飙高问题排查

源:http://daiwa.ninja/index.php/2015/07/18/storm-cpu-overload/ 2015-07-18AUTHORDAIWA STORM在线业务实践-集群空闲CPU飙高问题排查有2条评论 STORM在线业务实践-集群空闲CPU飙高问题排查 最近将公司的在线业务迁移到Storm集群上,上线后遇到低峰期CPU耗费严重的情况.在解决问题的过程中深入了解了storm的内部实现原理,并且解决了一个storm0.9-0.10版本一直存在的严重bug,目前代码已经合并

C#分布式消息队列 EQueue 2.0 发布啦

前言 最近花了我几个月的业余时间,对EQueue做了一个重大的改造,消息持久化采用本地写文件的方式.到现在为止,总算完成了,所以第一时间写文章分享给大家这段时间我所积累的一些成果. EQueue开源地址:https://github.com/tangxuehua/equeue EQueue相关文档:http://www.cnblogs.com/netfocus/category/598000.html EQueue Nuget地址:http://www.nuget.org/packages/eq

Storm实时日志分析实战

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

Flume-ng+Kafka+storm的学习笔记

Flume-ng Flume是一个分布式.可靠.和高可用的海量日志采集.聚合和传输的系统. Flume的文档可以看http://flume.apache.org/FlumeUserGuide.html 官方的英文文档 介绍的比较全面. 不过这里写写自己的见解 这个是flume的架构图 从上图可以看到几个名词: Agent: 一个Agent包含Source.Channel.Sink和其他的组件.Flume就是一个或多个Agent构成的. Source:数据源.简单的说就是agent获取数据的入口

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

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

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

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