Storm 综合

Storm 综合

Storm中Nimbus、Supervisor以及Worker之间的关系

首先storm是运行在多台服务器上的，每一台服务器我们称之为一个节点。

【nimbus进程】storm集群工作的全局指挥官。

1. 通过thrift接口，监听并接收client对topology的submit， 将topology代码保存到本地目录/nimbus/stormdist/下
2. 为client提交的topology计算任务分配，根据集群worker资源情况，计算出topology的spoult和bolt的task应该如何在worker间分配，任务分配结果写入zookeeper
3. 通过thrift接口，监听supervisor的下载topology代码的请求，并提供下载
4. 通过thrift接口，监听ui对统计信息的读取，从zookeeper上读取统计信息，返回给ui
5. 若进程退出后，立即在本机重启，则不影响集群运行。

Note（划重点）：nimbus是单节点的，也就是意味着nimbus只运行在一台服务器上，当nimbus进程挂掉后storm会无法正常工作。

【supervisor进程】storm集群的资源管理者，按需启动worker进程。

1. 定时从zookeeper 检查是否有代码未下载到本地的新topology ，定时删除旧topology代码
2. 根据nimbus的任务分配结果，在本机按需启动1个或多个worker进程，监控守护所有的worker进程。
3. 若进程退出，立即在本机重启，则不影响集群运行。

Note：每一个节点上都会运行一个supervisor进程，所以如果只有一台服务器的话，那就只有一个supervisor。

【worker进程】storm集群的 任务构造者 ，构造spoult或bolt的task实例，启动executor线程。

1. 根据zookeeper上分配的task，在本进程中启动1个或多个executor线程，将构造好的task实例交给executor去运行（死循环调用spoult.nextTuple()或bolt.execute()方法）。
2. 向zookeeper写入心跳
3. 维持传输队列，发送tuple到其他的worker
4. 若进程退出，立即在本机重启，则不影响集群运行。

【executor线程】storm集群的 任务执行者 ，循环执行task代码。

1. 执行1个或多个task（每个task对应spout或bolt的1个并行度），将输出加入到worker里的tuple队列
2. 执行storm内部线程acker，负责发送消息处理状态给对应spoult所在的worker

转自：https://www.jianshu.com/p/9b52961ac213

关于Storm nimbus 单节点宕机处理

一、storm集群在生产环境部署之后，通常会是如下的结构：

从图中可以看出zookeeper和supervisor都是多节点，任意1个zookeeper节点宕机或supervisor节点宕机均不会对系统整体运行造成影响，但 nimbus和ui都是单节点 。ui的单节点对系统的稳定运行没有影响，仅提供storm-ui页面展示统计信息。但nimbus承载了集群的许多工作，如果nimbus单节点宕机，将会使系统整体的稳定运行造成极大风险。因此解决nimbus的单点问题，将会更加完善storm集群的稳定性。

二、storm nimbus单节点的风险

(1)功能上，nimbus进程退出后，如果再同时发生worker进程宕机，宕机的worker将无法重启，集群将会有部分消息始终无法得到处理。 
(2)监控上，nimbus进程不可用时，storm ui将无法访问。 
(3)几率上，机房由于演练或故障不可用时即会出现 nimbus与worker进程同时故障 的情形，面对风险的几率较大。

三、nimbus目前无法做到多节点的原因

1. nimbus节点的ip地址在配置文件中storm.yaml，更换机器后ip地址变化，需要 更新集群所有节点的配置文件后重启 集群。
2. 客户端submitTopology时也需要取得nimbus ip上传代码。nimbus更换机器后，client也需要 修改配置文件 。
3. nimbus机器的本地硬盘存放了topology的代码，更换机器后代码全部丢失，新启动的supervisor将 无法下载正在运行的topology代码 。
4. storm ui是从nimbus读取集群统计信息的，nimbus更换机器后ui也需要 修改配置文件后重启 。

同时启动多个nimbus节点，会面临多个nimbus并发计算topology的任务分配，并发写入zookeeper，并发清理zookeeper等诸多不可预料的问题。

即使存在多个nimbus节点，storm-ui、supervisor、client等也只会使用配置文件指定的ip的节点。

【注】 storm在设计之初就做到了节点进程间通过zookeeper松散耦合，进程相对独立，单个进程的退出不会影响集群运行，因此nimbus做到多节点并不存在十分巨大的困难。但作者 @Nathanmarz 认为 nimbus单节点问题 并不是storm最紧急和严重的问题，因此在0.8.2版本之前nimbus ip地址依旧是在配置文件。

四、解决nimbus单点问题的关键

1、supervisor、client、ui对 nimbus节点ip动态获取 ，而非由配置文件指定。 
2、在nimbus更换机器后，supervisor仍然可随时 下载到topology的代码 。

五、业界对nimbus单点问题的努力

1、storm作者Nathanmarz对高可用的nimbus提出了这样的 规划 ：

nimbus目前的本地存储topology代码方式需要更加灵活，比如既支持本地存储，也支持分布式存储
nimbus节点之间需要实现基于zookeeper的自选举机制
客户端能够通过zookeeper找到nimbus leader的ip地址来submit topology
2、其他参考具体链接 https://blog.csdn.net/daiyutage/article/details/52049519

转自：https://blog.csdn.net/daiyutage/article/details/52049519