Storm集群类似于一个Hadoop集群。 然而你在Hadoop的运行“MapReduce job”，在Storm上你运行 “topologies”。 “job”和“topologies”本身有很大的不同，其中一个关键的区别是，MapReduce的工作最终完成，而topologies处理消息永远保持（或直到你杀了它）。Strom集群有主要有两类节点：主节点和工作节点。 主节点上运行一个叫做“Nimbus”的守护进程，也就是类似Hadoop的“JobTracker”。 Nimbus 负责在集群分发的代码，将任务分配给其他机器，和故障监测。
每个工作节点运行一个叫做”Supervisor”的守护进程。Supervisor监听分配给它的机器，根据Nimbus 的委派在必要时启动和关闭工作进程。每个工作进程执行topology的一个子集。一个运行中的topology由很多运行在很多机器上的工作进程组成。
图1 Storm架构
Nimbus和Supervisors之间所有的协调工作是通过一个Zookeeper集群。 此外，Nimbus的守护进程和Supervisors守护进程是无法连接和无状态的；所有的状态维持在Zookeeper中 或保存在本地磁盘上。这意味着你可以 kill -9 Nimbus 或Supervisors 进程，所以他们不需要做备份。这种设计导致Storm集群具有令人难以置信的稳定性。
Storm实现了一种数据流模型，其中数据持续地流经一个转换实体网络。一个数据流的抽象称为一个流（stream），这是一个无限的元组序列。元组（tuple）就像一种使用一些附加的序列化代码来表示标准数据类型（比如整数、浮点和字节数组）或用户定义类型的结构。每个流由一个唯一ID定义，这个ID可用于构建数据源和接收器（sink）的拓扑结构。流起源于喷嘴（spout），Spout将数据从外部来源流入 Storm 拓扑结构中。
图2 Storm的拓扑结构
接收器（或提供转换的实体）称为螺栓（bolt）。螺栓实现了一个流上的单一转换和一个 Storm 拓扑结构中的所有处理。Bolt既可实现 MapReduce之类的传统功能，也可实现更复杂的操作（单步功能），比如过滤、聚合或与数据库等外部实体通信。典型的 Storm 拓扑结构会实现多个转换，因此需要多个具有独立元组流的Bolt。Bolt和Spout都实现为Linux系统中的一个或多个任务。
但是，Storm 架构中一个最有趣的特性是有保障的消息处理。Storm 可保证一个Spout发射出的每个元组都会处理；如果它在超时时间内没有处理，Storm会从该Spout重新发射该元组。此功能需要一些聪明的技巧来在拓扑结构中跟踪元素，也是Storm的重要的附加价值之一。
除了支持可靠的消息传送外，Storm还使用ØMQ（ZeroMQ）最大化消息传送性能（删除中间排队，实现消息在任务间的直接传送）。ØMQ合并了拥塞检测并调整了它的通信，以优化可用的带宽。
Storm 0.9.0.1版本的第一亮点是引入了Netty Transport。Storm网络传输机制实现可插拔形式，当前包含两种方式：原来的ØMQ传输，以及新的Netty实现；在早期版本中（0.9.x之前的版本），Storm只支持ØMQ传输，由于ØMQ是一个本地库（native library），对平台的依赖性较高，要完全正确安装还是有一定挑战性。而且版本之间的差异也比较大；Netty Transport提供了纯JAVA的替代方案，消除了Storm的本地库依赖，且比ØMQ的网络传输性能快一倍以上。
