Storm入门(十一)Twitter Storm源代码分析之CoordinatedBolt

作者: xumingming | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://xumingming.sinaapp.com/811/twitter-storm-code-analysis-coordinated-bolt/

关于Twitter Storm的新特性: Transactional Topology 被问到的最多的问题是: Storm是怎么知道一个Bolt处理完成了它所有的tuple的? 其实要做到这一点还是有蛮多事情要做的, 幸运的是Storm已经提供了一个Bolt,帮我们把这些事情都做掉了。这个牛逼的bolt就是
CoordinatedBolt . 重要的是 CoordinatedBolt 的实现也是在storm的原语:spout, bolt这些基础之上的 — 也就是说即使作者不提供,我们自己也可以实现。我们来看看这个类的实现原理。

虽然CoordinatedBolt所发挥的作用很牛逼,但是其实它的原理并不是很复杂。它现在被用在两个场景里面:

  • DRPC
  • Transactional Topology

在看 CoordinatedBolt 的原理之前,我们先看看到底什么叫”处理完了”, 到底处理完什么了?
其实CoordinatedBolt对于业务不是完全没有侵入的,要使用CoordinatedBolt提供的功能,你必须要保证你的每个bolt发送的每个tuple的第一个field是 request-id , 那么所谓的”做完了”的意思是说当前这个bolt对于当前这个”request-id”所需要做的工作做完了。 这个 request-idDRPC 里面代表一个DRPC请求;在Transactional Topology里面代表一个batch.

CoordinatedBolt的原理是这样的:

  • 对于用户在DRPC, Transactional Topology里面的Bolt,都被CoordinatedBolt包装了一层:也就是说在DRPC, Transactional Topology里面的topology里面运行的已经不是用户提供的原始的Bolt, 而是一堆CoordinatedBolt, CoordinatedBolt把这些Bolt的事务都代理了。
  • 有了这个代理层,CoordinatedBolt就可以做它的工作了。
  • 它会在自己这里维护以下几个数据:
    • 哪些上游task要给我发tuple?(通过构造topology的时候所提供的grouping信息可以得知)
    • 我给哪些下游task发tuple? (同样通过grouping信息可以得知)
  • 每个CoordinatedBolt在每次真正bolt发出一个tuple之后,它都会记录下,这个tuple发给哪个task了。
  • 等它所有的tuple都发送完了之后(怎么知道发送完了?等会再说,少安毋躁),它通过另外一个特殊的stream以emitDirect的方式告诉所有它发送过tuple的task,它发送了多少tuple给它。
  • 一个bolt在接到所有的上游task发送的tuple个数信息之后,对比它接收到的tuple数量,如果数量对上了,说明它接收到了所有的tuple — 它处理完成了。
  • 这样它处理完成了,它可以重复上面的步骤通知它的下游,它的下游再通知它的下游的下游等等。
  • 总结一下,每个tuple怎么知道自己处理完成了的?都是靠它的上游通知的。所以只要一个bolt有上游,它就能够知道自己什么时候完成。
  • 那总有一个bolt是没有上游的 — 最上面那个bolt。那么这个bolt是怎么知道自己处理完成的呢?靠的是storm的ack系统 — 只要它ack了它的上游(某个非CoordinatedBolt, 在DRPC里面就是PrepareRequest)发送过来的tuple, 它就完成处理这个tuple了。 — 也就是说对于最上面那个bolt来说它只要处理完一个tuple(相对于它的下游要处理很多tuple才算完成)

具体原理如下图:

正如我们在上面讨论到底什么叫”做完成”的概念的时候,我们说了, CoordinatedBolt 的使用对于业务是有侵入的:你必须要在你的每个tuple的第一个字段带上当前 request-id , 否则 CoordinatedBolt 就跟踪不了了。 一种更优雅的方式是网络协议栈里面IP, TCP协议的处理方式。IP包在TCP包的外面包上IP层需要的信息,而不要求把IP层需要的信息掺杂在TCP的包字段里面,TCP层在发送数据的时候只组装TCP的那些字段,到了IP层自动加上IP层的信息。而IP层把数据包传给TCP层之前也自动去掉IP层的那些信息,TCP只会看到自己层的那些字段,毫无侵入。。作者对于这个问题提了一些改进的措施在 这里

时间: 2024-10-18 06:44:22

Storm入门(十一)Twitter Storm源代码分析之CoordinatedBolt的相关文章

Twitter Storm源代码分析之ZooKeeper中的目录结构

徐明明博客:Twitter Storm源代码分析之ZooKeeper中的目录结构 我们知道Twitter Storm的所有的状态信息都是保存在Zookeeper里面,nimbus通过在zookeeper上面写状态信息来分配任务,supervisor,task通过从zookeeper中读状态来领取任务,同时supervisor, task也会定义发送心跳信息到zookeeper, 使得nimbus可以监控整个storm集群的状态, 从而可以重启一些挂掉的task.ZooKeeper 使得整个sto

Storm入门(十二)Twitter Storm: DRPC简介

作者: xumingming | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明网址: http://xumingming.sinaapp.com/756/twitter-storm-drpc/ 本文翻译自: https://github.com/nathanmarz/storm/wiki/Distributed-RPC . Storm里面引入DRPC主要是利用storm的实时计算能力来并行化CPU intensive的计算.DRPC的storm topology以函数的参数

Storm入门(十)Twitter Storm: Transactional Topolgoy简介

作者: xumingming | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明网址: http://xumingming.sinaapp.com/736/twitter-storm-transactional-topolgoy/ 本文翻译自: https://github.com/nathanmarz/storm/wiki/Transactional-topologies 概述 Storm通过保证每个tuple至少被处理一次来提供 可靠的数据处理 .关于这一点最常被问到的问

【转】Twitter Storm如何保证消息不丢失

Twitter Storm如何保证消息不丢失 发表于 2011 年 09 月 30 日 由 xumingming 作者: xumingming | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明网址: http://xumingming.sinaapp.com/127/twitter-storm如何保证消息不丢失/ 本文翻译自: https://github.com/nathanmarz/storm/wiki/Guaranteeing-message-processing s

Twitter Storm如何保证消息不丢失

转自:http://xumingming.sinaapp.com/127/twitter-storm如何保证消息不丢失/ storm保证从spout发出的每个tuple都会被完全处理.这篇文章介绍storm是怎么做到这个保证的,以及我们使用者怎么做才能充分利用storm的可靠性特点. 一个tuple被”完全处理”是什么意思? 就如同蝴蝶效应一样,从spout发射的一个tuple可以引起其它成千上万个tuple因它而产生, 想想那个计算一篇文章中每个单词出现次数的topology. 帮助 1 2

_00019 Storm的体系结构介绍以及Storm入门案例(官网上的简单Java案例)

博文作者:妳那伊抹微笑 博客地址:http://blog.csdn.net/u012185296 个性签名:世界上最遥远的距离不是天涯,也不是海角,而是我站在妳的面前,妳却感觉不到我的存在 技术方向:Flume+Kafka+Storm+Redis/Hbase+Hadoop+Hive+Mahout+Spark ... 云计算技术 转载声明:可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明,谢谢合作! qq交流群:214293307  (期待与你一起学习,共同进步) # Storm

[转载] 使用 Twitter Storm 处理实时的大数据

转载自http://www.ibm.com/developerworks/cn/opensource/os-twitterstorm/ 流式处理大数据简介 Storm 是一个开源的.大数据处理系统,与其他系统不同,它旨在用于分布式实时处理且与语言无关.了解 Twitter Storm.它的架构,以及批处理和流式处理解决方案的发展形势. Hadoop(大数据分析领域无可争辩的王者)专注于批处理.这种模型对许多情形(比如为网页建立索引)已经足够,但还存在其他一些使用模型,它们需要来自高度动态的来源的

storm入门

最近学习了storm的一些基础知识,感觉storm是一个非常强大的实时流处理系统.对其进行简要介绍如下: STORM 1.什么是storm Storm是一个开源的,分布式的,可靠的,实时数据流处理系统.类比Hadoop对数据进行批处理,storm对数据进行实时处理. 2.storm的应用场景 Storm的处理速度快吞吐量大,根据Storm官方网站的资料介绍,Storm的一个节点(Intel [email protected]的CPU,24 GB的内存)在1秒钟能够处理100万个100字节的消息.

Twitter Storm: storm的一些常见模式

这篇文章列举出了storm topology里面的一些常见模式: 流聚合(stream join) 批处理(Batching) BasicBolt 内存内缓存 + fields grouping 组合 计算top N 用TimeCacheMap来高效地保存一个最近被更新的对象的缓存 分布式RPC: CoordinatedBolt和KeyedFairBolt 流聚合(stream join) 流聚合把两个或者多个数据流聚合成一个数据流 — 基于一些共同的tuple字段.流聚合和SQL里面table