storm原理

storm主节点Nimbus和工作节点supervisor中间是通过zookeeper知道对方状态，作业是topologies（拓扑），死循环

nimbus进程和supervisor进程是无法直接连接和无状态的，所有的状态维持在zookeeper中或者保存在本地磁盘

这意味着你可以kill -9 Nimbus或supervisors进程，而不需要做备份

这种设计导致storm集群具有令人难以置信的稳定性，即无耦合

zookeeper知道supervisor某个临时目录被清空了，就知道某个supervisor挂掉了

你如果做运维的话，你可以逐个启动节点，作业不会受到影响

nimbus负责在集群分发的代码，topo只能在nimbus机器上提交，将任务分配给其他机器，和故障检测

supervisor监听分配给它的节点，根据nimbus的委派在必要的时候启动和关闭工作进程。每个工作进程执行topology的一个子集。一个运行中的topology由很多运行在很多机器上的工作进程组成。

在storm中有对于流stream的抽象，流是一个不间断的无界的连续tuple，注意storm在建模事件流时，把流中的事件抽象为tuple元组。

中间的处理器称为bolt

storm认为每个stream都有一个源，也就是原始元组的源头，叫做spout（管口）

处理stream内的tuple，抽象为bolt，bolt可以消费任意数据的输入流，只要将流方向导入该bolt，同时它也可以发送新的流给其他的bolt，这样一来，只要打开特定的spout再将spout中流出的tuple导向特定的bolt（spout可以流入多个不同的处理器bolt），bolt对导入的流做处理后再导向其他bolt或者目的地。

可以认为spout就是一个水龙头，并且每个水龙头里面流出的水是不同的，我们想拿到哪种水就拧开哪个水龙头，然后使用管道将水龙头的水导向到一个水处理器（bolt），水处理器处理后再使用管道导向另一个处理器或者存入容器中。

为了增大水处理效率，就把拓扑弄成邮箱无环图。topo就是storm的job概念抽象，一个拓扑就是一个流转换图

topology

storm将流中元素抽象为tuple，一个tuple就是一个值列表·value list，list中的每个value都有一个name，并且该value可以是任意可序列化的类型，拓扑的每个节点都要说明它所发射出的元组的字段的name，其他节点只需要订阅该name就可以接受处理了

bolts：消息处理者

消息处理逻辑被封装在bolts里面，bolts可以做很多事情：过滤，聚合，查询数据库等。

bolts可以简单的做消息流的传递。复杂的消息流处理往往需要很多步骤，从而就需要经过很多bolts，第一级bolt的输出可以作为下一级bolt的输入，而spout不能有一级

bolt的主要方法是execute（死循环）连续处理传入的tuple，成功处理完一个tuple调用outputcollector的ack方法，以通知storm这个tuple被处理完成了，当处理失败时，可以调用fail方法通知spout端可以重新发送该tuple。

流程是：bolts处理一个输入tuple，然后调用ack通知storm自己已经处理过这个tuple了，storm提供了一个IBasicBolt会自动调用ack。

bolts使用outputcollector来发射tuple到下一级bolt

spout到很多bolt是广播，到单个bolt有6种grouping方式。。