前述：
本章内容借鉴官文和一些资料，有问题的地方希望大家指出。同样，内容中不会给出部署Storm集群的方法和步骤，因为部署只是我们使用它的基础，个人认为集群部署维护属于运维层面；也不会详解Command line client；更不会贴出yaml配置文件。所以不包含上述内容，希望不会浪费到大家时间。
那文章内容会有什么呢？
在完成上述工作以后，却不理解Storm是如何通过storm.yaml这个文件进行工作，集群之间是如何运行、每个守护进程都做了什么、代码怎么分配到每个节点、Storm的代码逻辑怎么写才会符合Stream、如何Storm集成到其他系统中、甚至想要重编译Storm；通过了解以下内容，可以理解并解决刚才的问题，举一反三。
当然这个必须自己部署一遍，熟悉过程，因为后期的topology结构定义可以不用写入代码内，而走flux配置来完成。这意味这什么呢？
概念：
特点介绍：
Storm 采用云计算框架中最实用的master/slave结构，静态设置。
主节点为nimbus，半容错；从节点supervisor；中间关系通过Zookeeper维护。
半容错：由于Nimbus不参与数据处理过程，且topology不会自动停止。所以只能对topology初始化、任务分发和监控，不会影响任务处理过程。但如果supervisor挂掉，nimbus不能再重新指派任务。
当然，可以使用HA nimbus，这个我们以后谈###############。
进程组件：
如果大家还记得上一章的Storm框架吗？本章就是围绕该架构来分析机理，首先，来看下每个进程组件的功能。
Nimbus：
Nimbus守护进程主要负责管理（类似于namenode+ResourceManager，因为Storm不需要hdfs），协调+监控 = topology的发布、任务指派、失败重新指派等。
Nimbus会记录所有supervisor节点的状态和分配给它们的task；如果supervisor没有heartbeat或不可达，它会将故障supervisor中的task重新分配到其他节点。
Supervisor：
Supervisor守护进程等待nimbus分配任务后，生成并监控workers（JVM进程）的执行。
Supervisor和worker都是运行在不同的JVM进程上（一个节点上可以运行多个JVM，每个JVM为一个进程，即worker），worker失败是由supervisor重启。
保障传输机制：当打开了可靠传输选项，传输到故障节点的tuple将不会收到应答确认，spout会因为超时而重新发射原始tuple（问题5），直到topology从故障中回复开始正常处理数据。
Zookeeper：
Storm 主要使用ZooKeeper 来协调一个集群中的状态信息，比如任务的分配情况，worker的状态，supervisor之间的nimbus的拓扑度量。nimbus 和supervisor节点之间的通信主要是结合 ZooKeeper 的状态变更通知和监控通知来处理的。（Zookeeper的在集群中最重要的应用！）1、Zookeeper原理、结构——Kuring 经典
Thrift：
对于重量级的数据传输操作，比如发布topology 时传输jar 包，Storm 依赖Thirft 进行通信。（在以后的源码分析中会有详解）
在理解每个守护进程后，我们来看看他们之间是如何工作的。
集群运行机制：
Storm的集群主要由三部分组成：nimbus、zookeeper、supervisor。
master是不会与每个slaver直接通信，他们之间的交流是通过zk，其中包括：代码下载、心跳机制、任务分配、同步集群等等。
这里简单提一下zk的主要功能：1、同步少量数据。2、有监听触发机制。
感兴趣的朋友可以自行学习zk，这里默认大家使用过zk。
nimbus的元数据存储在zk中，由于supervisor并不会直接与其通信，所以才会有半容错的存在。
1、实际上，nimbus在获取代码后运行代码，解析配置和topology结构，得到需要分配多少worker、executor、task等等，topology运行时需要的资源。
2、把相关信息提交给zk。这里其实就是修改zk中的tree文件内容，至于zk中的Storm tree是什么样的接下来会讲到。
3、zk作为中间服务系统，会触发消息到对应的supervisor。
4、每个supervisor得到信息后，会根据信息分配资源，首先是worker的建立、开启多少个executor、提交对应的tasks。
至于并发度、并行度，这些在提交代码、配置时已经定义好了，不用多说，如何做到这点请参考上一章Storm概念、原理详解及其应用（一）BaseStorm
zookeeper：
Storm在zookeeper中生成的树型目录结构如下图：
可以看出，根目录为/storm，其下的每一个叶子目录都是Storm存储元数据的地方。
下面分别介绍ZooKeeper中每项数据的具体含义：
/storm/workerbeats/<topology-id>/node-port：它存储由node和port指定的Worker的运行状态和一些统计信息，主要包括storm-id（也即topology-id）、当前Worker上所有Executor的统计信息（如发送的消息数目、接收的消息数目等）、当前Worker的启动时间以及最后一次更新这些信息的时间。在一个topology-id下面，可能有多个node-port节点。它的内容在运行过程中会被更新。
/storm/storms/<topology-id>：它存储Topology本身的信息，包括它的名字、启动时间、运行状态、要使用的Worker数目以及每个组件的并行度设置。它的内容在运行过程中是不变的。
/storm/assignments/<topology-id>：它存储了Nimbus为每个Topology分配的任务信息，包括该Topology在Nimbus机器本地的存储目录、被分配到的Supervisor机器到主机名的映射关系、每个Executor运行在哪个Worker上以及每个Executor的启动时间。该节点的数据在运行过程中会被更新。
/storm/supervisors/<supervisor-id>：它存储Supervisor机器本身的运行统计信息，主要包括最近一次更新时间、主机名、supervisor-id、已经使用的端口列表、所有的端口列表以及运行时间。该节点的数据在运行过程中也会被更新。
/storm/errors/<topology-id>/<component-id>/e<sequential-id>：它存储运行过程中每个组件上发生的错误信息。<sequential-id>是一个递增的序列号，每一个组件最多只会保留最近的10条错误信息。它的内容在运行过程中是不变的（但是有可能被删除）。
