Apache Storm - 集群架构

Apache Storm 的主要亮点之一是它是一个容错、快速且没有"单点故障"(SPOF)的分布式应用程序。 我们可以根据需要在尽可能多的系统中安装 Apache Storm,以增加应用程序的容量。

让我们看看 Apache Storm 集群是如何设计的以及它的内部架构。 下图描述了集群设计。

Zookeeper Framework

Apache Storm 有两种类型的节点,Nimbus(主节点)和Supervisor(工作节点)。 Nimbus 是 Apache Storm 的核心组件。 Nimbus 的主要工作是运行 Storm topology 。 Nimbus 分析 topology 并收集要执行的任务。 然后,它将任务分配给可用的主管。

主管将有一个或多个工作进程。 主管将任务委托给工作进程。 工作进程将根据需要生成尽可能多的执行程序并运行任务。 Apache Storm 使用内部分布式消息系统来进行 nimbus 和主管之间的通信。

组件 说明
Nimbus Nimbus 是 Storm 集群的主节点。 集群中的所有其他节点称为工作节点。 主节点负责在所有工作节点之间分发数据,将任务分配给工作节点并监控故障。
Supervisor 遵循 nimbus 指令的节点称为监督者。 supervisor 有多个工作进程,它管理工作进程以完成 nimbus 分配的任务。
Worker process 工作进程将执行与特定 topology 相关的任务。 工作进程不会自行运行任务,而是创建执行程序并要求它们执行特定任务。 一个工作进程将有多个执行者。
Executor 执行程序只不过是工作进程产生的单个线程。 executor 运行一个或多个任务,但仅针对特定的 spout 或 bolt。
Task 任务执行实际的数据处理。 所以,它要么是一个喷口,要么是一个bolt。
ZooKeeper framework

Apache ZooKeeper 是集群(节点组)使用的一种服务,用于在它们之间进行协调,并使用强大的同步技术维护共享数据。 Nimbus 是无状态的,所以它依赖于 ZooKeeper 来监控工作节点的状态。

ZooKeeper 帮助管理员与 nimbus 交互。 它负责维护 nimbus 和 supervisor 的状态。

Storm 本质上是无状态的。 尽管无状态特性有其自身的缺点,但它实际上帮助 Storm 以尽可能最好和最快的方式处理实时数据。

不过,Storm并非完全是无状态的。 它将其状态存储在 Apache ZooKeeper 中。 由于该状态在 Apache ZooKeeper 中可用,因此可以重新启动失败的 nimbus 并使其从其离开的位置开始工作。 通常,像 monit 这样的服务监控工具会监控 Nimbus 并在出现任何故障时重新启动它。

Apache Storm 还有一个名为 Trident Topology 的高级 topology ,具有状态维护功能,它还提供了像 Pig 这样的高级 API。 我们将在接下来的章节中讨论所有这些特性。