Storm简介
storm是一个分布式的、容错的实时计算系统，它被托管在GitHub上，遵循Eclipse Public License 1.0。Storm是由BackType开发的实时处理系统，由Twitter开源，官网http://storm.apache.org/。
Storm实时低延迟，主要有两个原因：
– storm进程是常驻内存的，不像hadoop里面是不断的启停的，就没有不断启停的开销。
– 第二点，Storm的数据是不经过磁盘的，都是在内存里面，处理完就没有了，处理完就没有了，数据的交换经过网络，这样就避免磁盘IO的开销，所以Storm可以很低的延迟。
在2013年的时候，Storm进入Apache社区进行孵化，最终进入了Apache顶级项目。
Storm架构：
– Nimbus
– Supervisor
– Worker
编程模型：
– DAG
– Spout
– Bolt
数据传输：
– Zmq
Zmq也是开源的消息传递的框架，虽然叫mq，但它并不是一个message queue，而是一个封装的比较好的消息传递框架。
– Netty
netty是NIO的网络框架，效率比较高。之所以有netty是storm在apache之后呢，zmq的license和storm的license不兼容的，bolt处理完消息后会告诉Spout。
高可用性：
– 异常处理
– 消息可靠性保证机制(ack机制)
可维护性：
– Storm有个UI可以看跑在上面的程序监控
实时请求应答服务（同步）
– 实时请求应答服务（同步），往往不是一个很简单的操作，而且大量的操作，用DAG模型来提高请求处理速度
– DRPC
– 实时请求处理，例子：发送图片，或者图片地址，进行图片特征的提取
DRPCClient client = new DRPCClient("drpc-host", 3772);
String result = client.execute("reach","http://twitter.com");
服务端由四部分组成：包括一个DRPC Server， 一个DPRC Spout，一个Topology和一个ReturnResult。
流式处理（异步）
不是说不快，而是不是等待结果。
逐条处理, 例子：ETL，把关心的数据提取，标准格式入库，它的特点是我把数据给你了，不用再返回给我，这个是异步的。
另外一种类型，就是：分析统计, 例子：日志PV，UV统计，访问热点统计，这类数据之间是有关联的，比如按某些字段做聚合，加和，平均等等。
最后写到Redis，Hbase，MySQL，或者其他的MQ里面去给其他的系统去消费。
Topology示例：
- ShuffleGrouping("spout")就是从spout来订阅数据，fieldGrouping("split", new Fields("word"))实际上就是一个hash，同一
个词有相同的hash，然后就会被hash到同一个WordCount的bolt里面，然后就可以进行计数。
- 接下来两行是配置文件，然后是配置3个worker，接下来是通过Submitter提交Topology到Storm集群里面去。
- 程序会编译打包，这段代码来自storm里面的starter的一段代码，这个代码怎么真正运行起来呢，就用storm jar 然后jar包的名，然后就是类的名字，和topology的名字，因为这里有个args[0]。
- 这段代码很简单，首先，第一部分构造了一个DAG的有向无环图，然后生成配置，提交到Storm集群去。
Cluster Summary（整个集群的）
- 一个slot就是一个worker，一个worker里面是一个jvm，一个worker里面可以有多个executor，每一个executor就是执行线程，每一个executor上面执行一个或多个Task，一般来说默认是一个task。
- Topology Summary（每个应用程序的）
- 一个应用程序就是一个Topology，它有名字，还有ID，然后有个状态，ACTIVE就是正在运行，KILLED就是已经被杀掉了。
– Topology actions就是可以对Topology采取一些操作，Deactivate就是暂停，Rebalance就是重新做一下balance，然后kill就是杀掉这个应用。
– 这个应用运行的到底怎么样，在Topology stats里面有个整体的统计，有10分钟，3小时，1天，还有所有的统计，这里面比较关键的呢，是Complete latency，它的意思就是一条数据从发出去到处理完花了多长时间，第二个比较关键就是ACK，这个反映的是吞吐，前面的Complete latency反映的延迟。
– 在Spouts的统计信息里面，一个是spout的名字，和代码里面是对应的，第二个是这个spout它有多少个executor，然后它有多少个task，然后是它在一定时间内往外emit出多少数据，真正tranfer传输了多少数据，然后它latency延迟是多少，然后ACK处理了多少数据，后面还有错误的信息。
– Bolt也类似，通过这个UI页面可以实时观看这些统计信息，是非常有用的，可以知道哪个环节比较慢，哪些地方有没有什么瓶颈了，有瓶颈了是不是加一个并发来解决问题。
- Spout中这里最关键的是一个nextTuple()，它是从外部取数据的源头，可以从DPRC取数据，可以从MQ，比如Kafka中取数据，然后给后面的bolt进行处理，然后这里wordcount没有那么复杂，就自己随机的生成了数据。
- _collector.emit(new Values(sentence), new Object());
- 这个代码后面new Object()等于是随机的生成了一个message的ID，这个ID有什么用，后面会讲到，实际上它是消息可靠性保障的一部分。有了这个ID，Storm就可以帮你去跟踪这条消息到底有没有被处理完，如果处理完了呢?
- 如果处理完了，它就是调用一个ack告诉spout，我已经处理完了，这里ack方法里面仅仅是把id打印出来，因为这里id没有什么意义，仅仅是为了展示，相反，如果在一定时间内没有处理完，会调用fail告诉说消息处理失败了。
- 对于wordcount的示例，它是有两个blot，一个bolt是分词，一个bolt是计数，这里SplitSentence是展示它支持多语言的
开发，其实这里代码调用的是python的splitsentence.py，使用的是ShellBolt这个组件。
- 那wordcount这个bolt是用java实现的，它的实现核心是亮点，一点是有execute这样一个函数，第二个是declareOutputFields这个函数，这两个函数的作用其实是很什么呢？最核心的其实是execute，execute的作用呢就是拿到输入的数据Tuple，然后再emit数据出去。
- 以上就是在storm里面一个最简单的wordcount的例子，它的主函数的代码，它的提交的命令行代码，Spout是什么样的，Bolt是什么样的，提交到Storm集群之后是一个什么样的运行状况，在WebUI上面看到哪些核心的信息，这个在后面的应用开发里面都会大量的运用到。
Storm和MapReduce对比
- Storm：进程、线程常驻运行，数据不进入磁盘，网络传递。
- MapReduce：TB、PB级别数据设计的，一次的批处理作业。
Storm和Spark streaming对比
- Storm：纯流式处理，处理数据单元是一个个Tuple。另外Storm专门为流式处理设计，它的数据传输模式更为简单，很多地方也更为高效。并不是不能做批处理，它也可以来做微批处理，来提高吞吐。
- Spark Streaming：微批处理，一个批处理怎么做流式处理呢，它基于内存和DAG可以把处理任务做的很快，把RDD做的很小来用小的批处理来接近流式处理。
- 通过对比，更能了解Storm的一些特点：
(1) 首先，相对于Queue+Worker来说，它是一个通用的分布式系统，分布式系统的一些细节呢可以屏蔽掉，比如说水平扩展，容错，上层应用只需要关注自己的业务逻辑就可以了，这一点对应应用开发人员来说是非常重要的，不然的话业务逻辑会被底层的一些细节所打乱。
(2) 另外，Storm作为一个纯的流式处理系统，和mapreduce的差异相当大，一种称为流式处理，一种称为批处理，Storm是一个常驻运行的，它的消息收发是很高效的。
- 和spark这种微批处理系统相比，Storm可以处理单条单条的消息。
- 总的来说，Storm在设计之初，就被定义为分布式的流式处理系统，所以说大部分的流式计算需求都可以通过Storm很好的满足，Storm目前在稳定性方面也做的相当不错，对于实时流式计算来说是个非常不错的选择。