Storm介绍

Storm是一个流式计算框架，用来实时处理数据，特点：低延迟、高可用、分布式、可扩展、数据不丢失。

• Storm进程常驻内存
• Storm数据不经过磁盘，在内存中处理

Storm架构

• Nimbus：即Storm的Master，负责资源分配和任务调度。一个Storm集群只有一个Nimbus。
• Supervisor：即Storm的Slave，负责接收Nimbus分配的任务，管理所有Worker，一个 Supervisor节点中包含多个Worker进程。
• Worker：工作进程，每个工作进程中都有多个Task。
• Task：任务，在 Storm 集群中每个 Spout 和 Bolt 都由若干个任务（tasks）来执行。每个任务都与一个执行线程相对应。

Storm架构.png

关于上图，采自网上的一段通俗理解：
Nimbus就像人的大脑一样，当客户端给这个人发送了段信息 ，这个人的大脑就接收到这段信息，这个人不简单，是幕后大佬，一般不自己去干活，都是交给下面二当家的（Supervisor）去执行。

这个大佬比较公平，先去Zookeeper那边看看每个二当家的（Supervisor）那里还有多少个可以干活的小弟（Worker），不会亏待了下面小弟，而小弟每过一段时间需要给Zookeeper负责人打个电话报备下。

毕竟在外混，难免有牺牲了，Nimbus知道这些情况后，开始分配任务，就让自己的秘书 Zookeeper女士去宣布让下面各位二当家的干活。二当家的把活分给自己的小弟（Worker），小弟这时候才真的让最底层的跟班（Task）去干活。

Storm编程模型

• Topology：计算拓扑，Storm 的拓扑是对实时计算应用逻辑的封装，它的作用与 MapReduce 的任务（Job）很相似，区别在于 MapReduce 的一个 Job 在得到结果之后总会结束，而拓扑会一直在集群中运行，直到你手动去终止它。拓扑还可以理解成由一系列通过数据流（Stream Grouping）相互关联的 Spout 和 Bolt 组成的的拓扑结构。
• Stream：数据流（Streams）是 Storm 中最核心的抽象概念。一个数据流指的是在分布式环境中并行创建、处理的一组元组（tuple）的无界序列。数据流可以由一种能够表述数据流中元组的域（fields）的模式来定义。
• Spout：数据源（Spout）是拓扑中数据流的来源。一般 Spout 会从一个外部的数据源读取元组然后将他们发送到拓扑中。
• Bolt：拓扑中所有的数据处理均是由 Bolt 完成的。通过数据过滤（filtering）、函数处理（functions）、聚合（aggregations）、联结（joins）、数据库交互等功能，Bolt 几乎能够完成任何一种数据处理需求。一个 Bolt 可以实现简单的数据流转换，而更复杂的数据流变换通常需要使用多个 Bolt 并通过多个步骤完成。
• Stream grouping：为拓扑中的每个 Bolt 的确定输入数据流是定义一个拓扑的重要环节。数据流分组定义了在 Bolt 的不同任务（tasks）中划分数据流的方式。在 Storm 中有八种内置的数据流分组方式。

• Reliability：可靠性。Storm 可以通过拓扑来确保每个发送的元组都能得到正确处理。通过跟踪由 Spout 发出的每个元组构成的元组树可以确定元组是否已经完成处理。每个拓扑都有一个“消息延时”参数，如果 Storm 在延时时间内没有检测到元组是否处理完成，就会将该元组标记为处理失败，并会在稍后重新发送该元组。

  
  Storm编程模型.png

Storm任务提交流程

Storm任务提交流程.png

Storm目录树

Storm目录树.png

StormZookeeper目录树

StormZookeeper目录树.png

Storm并发机制

Storm并发机制.png
调整Worker进程数量（无法调整task数量）
假设有了10个节点的集群，每个节点有4个worker（进程），如果再增加10台服务器，就需要调整进程数了，每个节点只跑两个进程。

#将mytopology拓扑worker进程数量调整为4个，
# -w 2  延迟2s执行
# -n 重新确定worker数量4
# wcsplitbolt 所使用的线程数量调整为4个
storm rebalance mytopology -w 2 -n 4 -e wcsplitbolt=4