storm学习小结一：storm概述

本文只对storm作原理性的介绍和概述，不涉及代码，以及深层分析。

1.业务层概念

    storm在业务 层所展现的结构是一个DAG（有向无环图，Directed Acyclic Graph）。如下图所示：

    其中，节点类型为spout或bolt，有向边代表这个流式系统中数据的流向。这两个概念是业务层的概念，也是代码层面的概念，也就是说，在storm的源码或针对storm面编写的应用中，有spout和bolt这样的类。对这些概念的解释是：

spout：数据源。其实就是storm的数据接入层，作为流式计算系统的接口，将系统外的数据导入系统内。和这个spout对接的上游一般是其他系统的数据订阅接口（比如消息队列系统）。因为毕竟是流式系统，如果从磁盘或hdfs上拿数据，就违背了流式计算时效性的初衷了。

bolt：数据处理单元。一个bolt对应storm应用代码中的一个类（也就是一种处理逻辑）。上图中的各个spout和bolt，就业务逻辑而言其实是不同的，可以将图中的spout和bolt脑补成spout1,spout2,bolt1,bolt2.....

    在这个topoplogy在storm上跑起来的时候，对于spout和bolt，都有一个并发度的概念。我们在这里定一个潜规则：如果某个bolt有n的并发度，我们就说这个bolt在实际运行的时候，有n个实例。一个bolt的所有实例，它们的逻辑是一样的，只不过可能运行在不同的机器上，或同一个机器的同一个进程中的不同线程中，或同一个线程中（当两个实例被分配在同一个机器上的时候）；分配规则在系统层中介绍。再自创一个名词：“topology的运行态”表示一个topology在某次运行时，所有spout实例和bolt实例的集。这一段的内容其实是系统层概念，先在这里预先阐述。

2.系统层概念

    storm这个系统有三个子系统：nimbus，ui，supervisor。说是三个子系统，其实storm为这三个子系统提供了一个统一的工具接口，只要提供不同的参数（比如nimbus,ui,supervisor）就可以运行这三个功能中的一个。storm运行在集群之上。一般而言，在这个集群之中，会专门拿出一台机器运行nimbus服务和ui服务，剩下的机器，在每台机器上都会运行supervisor进程。这几个概念的解释如下：

nimbus：storm的master（master-worker模型中的master），功能：

    1）处理用户提交的命令，如提交拓扑、删除拓扑等

    2）对拓扑进行管理，如状态管理、jar包管理等

    3）对supervisor的任务分配

    4）failover机制，对失效的task重新进行分配

supervisor：storm的worker（master-worker中的worker，与下面说到的worker是两码事）。负责接收来自nimbus的命令，运行各个任务。

ui：监控系统情况的web页面，不作介绍。

3.模块级别概念

    针对supervisor这个子系统，再展开其中的其他概念：

worker：在supervisor上是一个独立的进程。一般而言，nimbus会把一个topology中的所有spout实例和bolt实例以某种策略（以后再说是什么策略）分配置到各个supervisor机器（或supervisor进程）上。可以认为，同一个supervisor中的同一个topology的各个实例，组成了一个worker进程。也就是说，一个worker进程其实是一个（且只能是某一个）“topology运行态”的子集，一个“topology运行态”是由分发到不同supervisor的各个worker组成的。

executor：一个executor一般就是隶属于某个worker的一个线程。一个executor线程可以认为就是一个spout或bolt实例。一种特殊情况是，如果一个bolt的两个实例被分配到了同一个worker中，那么这两个实例会放在一个executor线程中运行，spout同理。

task： task和概念就是之前一直用到的实例的概念。即一个bolt的task的数量就是其并发度，一个topology的所有task构成了这个“topology运行态”。也即，一个task是一个bolt或一个spout的实际运行实体。正如executor中所说的那样，一个线程中可能有多个task。

    几个概念如下图：

4.storm系统内一些比较重要的技术

• strom数据可靠性保证：记录级容错机制
• 一致事务
• 消息分发策略
• DRPC实现

以上部分内容在官方文档中有介绍，这个不作深入讨论，后续以引用形式给出具体文档