2018-05-16

storm是一款开源的、分布式的、低延迟的、可扩展的、容错的实时计算框架，采用clojure和java的混合编程,jstom是阿里对storm的一个改进。

JStorm 是一个类似Hadoop MapReduce的系统， 用户按照指定的接口实现一个任务，然后将这个任务递交给JStorm系统，JStorm将这个任务跑起来，并且按7 * 24小时运行起来，一旦中间一个Worker 发生意外故障， 调度器立即分配一个新的Worker替换这个失效的Worker。

JStorm是一套基于流水线的消息处理机制。

Storm组件和Hadoop组件对比

storm组件对比

分布式的:一台物理机器的CPU、内存、磁盘终究是有限度的，当数据量巨大的情况下，利用多台廉价的机器来协同完成计算成为了上上策，而jstorm也就是用于协同多台机器完成计算的框架，当然这里的计算是指实时计算。其实分布式也是容错性的一部分。

容错:不同的应用程序对容错性的要求不同，如银行的交易，对容错性较高，网站访问数量的计算，其容错性要求就比较低。总的来数，核心业务的容错性要求较高。jstorm的容错性体现在两方面，一是其为集群的、分布式的系统，而且jstorm是一个无状态的模型，其所有的状态都保存在一个集群的zookeeper中，在机器、进程死掉后，可以通过zookeeper中记录的信息进行重启。二是其具有ack机制，对每一条信息，都可以进行ack告知上游处理完成，或者fail，告诉上游处理不成功，没能手动的ack，便会触发timeout，上游也会fail，根据我们容错性要求的不同，其处理办法也不同。

JStorm处理数据的方式是基于消息的流水线处理， 因此特别适合无状态计算，也就是计算单元的依赖的数据全部在接受的消息中可以找到， 并且最好一个数据流不依赖另外一个数据流。

因此，常常用于

日志分析，从日志中分析出特定的数据，并将分析的结果存入外部存储器如数据库。目前，主流日志分析技术就使用JStorm或Storm
管道系统， 将一个数据从一个系统传输到另外一个系统， 比如将数据库同步到Hadoop
消息转化器， 将接受到的消息按照某种格式进行转化，存储到另外一个系统如消息中间件
统计分析器， 从日志或消息中，提炼出某个字段，然后做count或sum计算，最后将统计值存入外部存储器。中间处理过程可能更复杂。

首先，JStorm有点类似于Hadoop的MR（Map-Reduce），但是区别在于，hadoop的MR，提交到hadoop的MR job，执行完就结束了，进程就退出了，而一个JStorm任务（JStorm中称为topology），是7*24小时永远在运行的，除非用户主动kill。

JStorm组件

接下来是一张比较经典的Storm的大致的结构图（跟JStorm一样）：

twitter_storm_topology

图中的水龙头（好吧，有点俗）就被称作spout，闪电被称作bolt。

在JStorm的topology中，有两种组件：spout和bolt。

spout

spout代表输入的数据源，这个数据源可以是任意的，比如说kafaka，DB，HBase，甚至是HDFS等，JStorm从这个数据源中不断地读取数据，然后发送到下游的bolt中进行处理。

bolt

bolt代表处理逻辑，bolt收到消息之后，对消息做处理（即执行用户的业务逻辑），处理完以后，既可以将处理后的消息继续发送到下游的bolt，这样会形成一个处理流水线（pipeline，不过更精确的应该是个有向图）；也可以直接结束。

通常一个流水线的最后一个bolt，会做一些数据的存储工作，比如将实时计算出来的数据写入DB、HBase等，以供前台业务进行查询和展现。

20160123160231467.jpg