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可靠性消息

看过一些别人写的, 感觉有些东西没太说清楚,个人主要以源代码跟踪,参考个人理解讲述,有错误请指正. 1基本名词 1.1 Tuple: 消息传递的基本单位.很多文章中介绍都是这么说的, 个人觉得应该更详细一点. 在spout发送的时候,函数原型 public List<Integer> emit(List<Object> tuple, Object messageId) {        return emit(Utils.DEFAULT_STREAM_ID, tuple, mess

storm trident 消息成功处理

trident里面 batch会被缓存,这样失败了可以重新发送 多个batch可以并行被process,但是commit是严格按照txid顺序来执行 一个batch的状态会存在zk里 只要batch在timeout时间内commit就算完成了,应该同时会清缓存 如果异常或超时了,就会replay 在原声的storm中一个tuple和它衍生的tuple有没有被成功处理,是通过一个异或机制来监控的,如果被成功处理,最后肯定会是0 batch也是类似的监控机制 一个batch也会衍生出一些tuple,

3、第八周 - 网络编程进阶 - Redis消息缓存

Redis概念 Redis是主流的key-value nosql 数据库之一.和Memcached类似,它支持存储的value类型相对更多,包括string(字符串).list(链表).set(集合).zset(sorted set --有序集合)和hash(哈希类型).这些数据类型都支持push/pop.add/remove及取交集并集和差集及更丰富的操作.,redis支持各种不同方式的排序.与memcached一样,为了保证效率,数据都是缓存在内存中.区别的是redis会周期性的把更新的数据

react-devtool看消息缓存与转发机制(electron版)

electron httpServer.on('request', (req, res) => { // Serve a file that immediately sets up the connection. var backendFile = readFileSync(join(__dirname, 'backend.js')); //res.end(backendFile + '\n;ReactDevToolsBackend.connectToDevTools();'); res.end

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,目前代码已经合并