[Jstorm]Jstorm章1 Jstorm架构浅析

一、整体架构

JStorm 的整体架构图如下：

其中 W 表示 worker，T 表示 task。

从图中我们可以看到 JStorm 在设计上将集群中的节点分为 nimbus 和 supervisor 两类。其中 nimbus 节点相当于整个集群的调度者，基于 ZK 对整个集群进行调度，supervisor 节点则是整个集群中实际运行 topology 的节点。在一个 supervisor 节点中一般会启动多个 worker 进程，每个 worker 进程又包含多个 task 线程。我们提交的 topology 任务一般会包含多个组件（spout 和 bolt），每个组件依据其并行度配置会分配到相应数量的 task 任务，而每一个 task 任务都运行在对应的 task 线程上面。JStorm 是一个重度依赖于 ZK 的分布式调度系统，所有的工作组件（nimbus、supervisor、worker，以及 task）都会与 ZK 进行交互上报和更新自己的运行状态，同时获取其他工作组件的运行状态来指导自己接下去的运行。

二、工作过程

简单陈述一下一个 topology 任务从提交到运行的基本执行过程。

当我们按照 JStorm 的开发规范实现好自己的 topology 之后，我们需要将其打成 jar 包并执行相应的命令将其发布到集群，这期间我们主要是和 nimbus 节点进行通信，nimbus 会启动一个 thrift 服务，而提交任务的过程实际上就是一次 RPC 请求的过程。

Nimbus 节点会为本次任务提交请求创建对应的传输通道，然后等待用户上传 topology 的 jar 文件到本地。上传完成之后，nimbus 节点会依据用户的配置以及集群的运行状态开始为当前 topology 制定运行方案，包括需要分配多少 task，这些 task 需要多少 worker 进行执行，对应的 worker 需要落地到哪些 supervisor 节点才能保证集群的均衡等。当方案制定完成之后，nimbus 会将运行方案写入 ZK 对应的路径下面，并告知用户本次任务提交成功。

Supervisor 节点会定期检查 ZK 的任务分配路径以确定是否有新的任务需要执行，如果正好任务是被分配给当前 supervisor 节点，则 supervisor 会从 nimbus 节点下载当前 topology 对应的 jar 文件，并按照 nimbus 制定的运行方案在本地启动相应的 worker 去执行 topology 任务。同时 supervisor 会监控本地 worker 的运行状态，如果存在运行异常的 worker，则将其 kill 掉并通知 nimbus 重新分配。

Nimbus 节点作为调度者在实际中以单节点的形式运行，早期的 storm 在设计上没有引入 HA 机制，所以对于 nimbus 节点而言存在单点的隐患，虽然 nimbus 上的数据都是无状态的，但是当 nimbus 节点宕机之后，还是会在一定程度上影响整个集群的正常运行。JStorm 在改造时引入了 HA 机制，在 JStorm 中可以同时启动多个 nimbus 节点，这些节点在初始时都是 follower 角色，它们会将自身的节点信息上报给 ZK，然后依据优先级竞选成为 leader，期间需要 ZK 的介入来保证竞选结果的一致，当 nimbus leader 宕机之后，候选的 follower 会马上顶替一个上来，以保证集群的正常运行。