storm开发总结【一】

这几个月来，一直在弄Storm相关的东西，先是调研Storm，然后看几个demo，最后自己开发程序。一路走来遇到许多问题。

首先，这东西比较新，因此本身可能会存在一些bug（实际开发工程中，Trident模式下就遇到了一个bug）。storm-ui的监控也不大完善（Storm UI里，Emitted ≠ Acked + Failed），对于API的描述也很简陋（几乎没有说明某某类某某接口是干什么的）。

其次，国外关于Storm的入门介绍的东西比较少，基本就是看Github主页的wiki，以及Getting Started with Strom这本书。由于刚开始看英文文档，初期感觉比较吃力。后期慢慢适应了，也充分意识到英语的重要性啊。好在Storm的开发者社区还是有一定活跃度，问的问题可能会被回答。

最后，自己的java水平太烂……

一、Storm的安装

在使用过程中，我至始至终没有涉及到Storm的安装，因此没有什么好记录的。总的来说，依赖Zookeeper，zeroMQ（storm0.9.0好像取消了zeroMQ）等等。

二、Storm的系统架构

基本的主从结构。nimbus是主节点，通关全局；supervisor是从节点，管理节点上的任务。每个supervisor上运行Worker进程，执行具体任务。每个supervisor上的worker数量是由slot的个数决定的。在配置文件/conf/storm.yaml中。Nimubs，Supervisor与Worker间的通讯不存在心跳信息或其他RPC控制协议，而是采用ZooKeeper来进行信息交换。

作为主节点， Nimbus类似于Hadoop中的Jobtracker，主要负责接收客户端提交的Topology，进行相应的验证，分配任务，进而把任务相关的元信息写入Zookeeper相应目录，此外，Nimbus还负责通过Zookeeper来监控任务执行情况。而Supervisor则类似于TaskTracker，负责会监听任务分配情况，根据实际情况启动/停止工作进程（worker）。相应的，Worker和Hadoop中的map/reduce task很类似，实际的数据处理发生在这里。

三、计算模型

Storm的计算模型以Topology为单位。一个Topology是由一系列Spout和Bolt构成的图。Events stream会在构成Topology的Spout和Bolt之间流动。Spout负责产生event，而bolt负责处理对接收到的event进行各种处理，得出需要的计算结果。Bolt可以级联，也可以往外发送event （往外发送的event可以和接收到的event是同一种类型或者不同类型）。Storm的topology相当于Hadoop里面的一个MapReduce Job, 它们的关键区别是：一个MapReduce Job最终总是会结束的， 然而一个storm的topoloy会一直运行 — 除非你显式的杀死它。

storm的一些基本名词解释：

1. Stream：消息流，一个消息流是一个无限的tuple序列。

2. Tuple：storm里面最基本的消息格式，一个tuple可以包含各种字段，比如，integer，long，short，byte，string等等。

3. Spout：消息流Stream的来源。例如，一个Spout可以从Kafka消息队列中读取消息，发给bolt。

4. Bolt：消息的处理者，它接收tuple，处理tuple，并可以继续发tuple。

5. Stream Grouping：定义了tuple流在各个组件（Spout / Bolt）之间的分配策略。目前支持六种：Shuffle Grouping: 随机分组，Fields Grouping：按字段分组，All Grouping： 广播发送，Global Grouping: 全局分组，Non Grouping: 不分组，Direct Grouping: 直接分组。

四、应用场景

Storm可以应用于三种不同的场景：事件流（stream processing），持续计算（Continuous computation）以及分布式RPC（Distributed RPC）。