JStorm 源码分析 - tuple 在整个拓扑中的流转过程

栏目: 编程工具 · 发布时间: 6年前

内容简介:介绍 JStorm 时, 如果上来就直接贴大段大段的源代码, 那我觉得还不如不看. 这种行为就像是让盲人去摸:elephant:, 难以窥见整个系统的全貌.所以这里先丢一张图, 毕竟图总比文字更有表现力.

JStorm 源码分析 - tuple 在整个拓扑中的流转过程

介绍 JStorm 时, 如果上来就直接贴大段大段的源代码, 那我觉得还不如不看. 这种行为就像是让盲人去摸:elephant:, 难以窥见整个系统的全貌.

所以这里先丢一张图, 毕竟图总比文字更有表现力.

JStorm 源码分析 - tuple 在整个拓扑中的流转过程

这个图上画的是一个 tuple 在各个组件之间的流转过程, 主要涉及到的有三个队列:

  • deserializeQueues 待反序列化队列
  • innerTaskTransfer 待task消费队列
  • serializeQueue 待序列化队列

线条代表了 tuple 被处理后流动的方向.

我们的 tuple 被 Spout/Bolt 所 emit 之后, 就一辈子都在这三个队列当中兜兜转转^_^.

当我们的 task (bolt/spout) 发送一个 tuple 时, 自然是希望这个 tuple 被下一个 task (bolt/spout) 所消费, 但是下一个 task 可能被分配在同一个 worker 当中, 也可能是在另一台机器的另一个 worker 当中.

如果是另一个 worker , 那么 Collector 会将 worker 放入到 serializeQueue (待序列化队列), 有专门的线程会消费这个队列, 然后将消息发送到另一个 worker . 如果是同一个 worker , 那就没这么费事了, 直接丢到 innerTaskTransfer (待task消费队列) 就完事儿了! 那么 deserializeQueues (待反序列化队列) 又是做什么的呢? ^_^ 另一个接收到消息的 worker, 当然是需要反序列化收到的消息, 然后让 task 去消费啦, 那么这些刚接收到的消息, 都存在这个队列里面.

下面这张图画出了tuple 的反序列化/序列化/消费/网络传输所涉及的组件: TaskReceiver, TaskTransfer, Task, NettyClient, NettyServer

JStorm 源码分析 - tuple 在整个拓扑中的流转过程

TODO 待更新

JStorm 源码分析 - tuple 在整个拓扑中的流转过程


以上所述就是小编给大家介绍的《JStorm 源码分析 - tuple 在整个拓扑中的流转过程》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

有限与无限的游戏

有限与无限的游戏

[美]詹姆斯·卡斯 / 马小悟、余倩 / 电子工业出版社 / 2013-10 / 35.00元

在这本书中,詹姆斯·卡斯向我们展示了世界上两种类型的「游戏」:「有限的游戏」和「无限的游戏」。 有限的游戏,其目的在于赢得胜利;无限的游戏,却旨在让游戏永远进行下去。有限的游戏在边界内玩,无限的游戏玩的就是边界。有限的游戏具有一个确定的开始和结束,拥有特定的赢家,规则的存在就是为了保证游戏会结束。无限的游戏既没有确定的开始和结束,也没有赢家,它的目的在于将更多的人带入到游戏本身中来,从而延续......一起来看看 《有限与无限的游戏》 这本书的介绍吧!

在线进制转换器
在线进制转换器

各进制数互转换器

SHA 加密
SHA 加密

SHA 加密工具

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具