《Storm分布式实时计算模式》——2.1 Storm集群的框架-阿里云开发者社区

开发者社区> 华章出版社> 正文

《Storm分布式实时计算模式》——2.1 Storm集群的框架

简介:

本节书摘来自华章计算机《Storm分布式实时计算模式》一书中的第2章,第2.1节,作者:(美)P. Taylor Goetz Brian O’Neill 更多章节内容可以访问云栖社区“华章计算机”公众号查看。

第2章 配置Storm集群

在本章中你将深入理解Storm的技术栈,它的软件依赖,以及搭建和部署Storm集群的过程。我们首先会在伪分布式模式下安装Storm,所有的组件都安装在同一台机器上,而不是在多台机器上。一旦你了解了安装和配置Storm的基本步骤,我们就可以通过Puppet这个工具进行自动化的安装,这样的话部署多节点的集群可以节省大量的时间和精力。
本章包括以下内容:

  • 组成Storm集群的不同组件和服务
  • Storm的技术栈
  • 在Linux上安装和配置Storm
  • Storm的配置参数
  • Storm的命令行接口
  • 使用服务提供工具Puppet进行自动安装

2.1 Storm集群的框架

Storm集群遵循主/从(master/slave)结构,和Hadoop等分布式计算技术类似,语义上稍有不同。主/从结构中,通常有一个配置中静态指定或运行时动态选举出的主节点。Storm使用前一种实现方式。主/从结构中因为引入了单点故障的风险而被诟病,我们会解释Storm的主节点是半容错的。
Storm集群由一个主节点(称为nimbus)和一个或者多个工作节点(称为supervisor)组成。在nimbus和supervisor节点之外,Storm还需要一个Apache ZooKeeper的实例,ZooKeeper实例本身可以由一个或者多个节点组成。如图2-1所示。


<a href=https://yqfile.alicdn.com/12cb188dcbf5407b9b205dcfac49195ea0e677c7.png" >

nimbus和supervisor都是Storm提供的后台守护进程,可以共存在同一台机器上。实际上,可以建立一个单节点伪集群,把nimbus、supervisor和ZooKeeper进程都运行在同一台机器上。
2.1.1 理解nimbus守护进程
nimbus守护进程的主要职责是管理,协调和监控在集群上运行的topology。包括topology的发布,任务指派,事件处理失败时重新指派任务。
将topology发布到Strom集群,将预先打包成jar文件的topology和配置信息提交(submitting)到nimbus服务器上。一旦nimbus接收到了topology的压缩包,会将jar包分发到足够数量的supervisor节点上。当supervisor节点接收到了topology压缩文件,nimbus就会指派task(bolt和spout实例)到每个supervisor并且发送信号指示supervisoer生成足够的worker来执行指派的task。
nimbus记录所有supervisor节点的状态和分配给它们的task。如果nimbus发现某个supervisor没有上报心跳或者已经不可达了,它会将故障supervisor分配的task重新分配到集群中的其他supervisor节点。
前面提到过,严格意义上讲nimbus不会引起单点故障。这个特性是因为nimubs并不参与topology的数据处理过程,它仅仅是管理topology的初始化,任务分发和进行监控。实际上,如果nimbus守护进程在topology运行时停止了,只要分配的supervisor和worker健康运行,topology一直继续数据处理。要注意的是,在nimbus已经停止的情况下supervisor异常终止,因为没有nimbus守护进程来重新指派失败这个终止的supervisor的任务,数据处理就会失败。
2.1.2 supervisor守护进程的工作方式
supervisor守护进程等待nimbus分配任务后生成并监控workers(JVM进程)执行任务。supervisor和worker都是运行在不同的JVM进程上,如果由supervisor拉起的一个woker进程因为错误(或者因为Unix终端的kill-9命令,Window的tskkill命令强制结束)异常退出,supervisor守护进程会尝试重新生成新的worker进程。
看到这里你可能想知道Storm的有保障传输机制如何适应其容错模型。如果一个worker甚至整个supervisor节点都故障了,Storm怎么保障出错时正在处理的tuples的传输?
答案就在Storm的tuple锚定和应答确认机制中。当打开了可靠传输的选项,传输到故障节点上的tuples将不会收到应答确认,spout会因为超时而重新发射原始tuple。这样的过程会一直重复直到topology从故障中恢复开始正常处理数据。
2.1.3 Apache ZooKeeper简介
ZooKeeper使用一个简单的操作原语集合和分组服务,在分布式环境下提供了集中式的信息维护管理服务。它是一种简单但功能强大的分布式同步机制,允许客户端的应用程序监控或者订阅数据集中的部分数据,当数据产生,更新或者修改时,客户端都会收到通知。使用常见的ZooKeeper模式或方法,开发者可以实现分布式计算所需要的很多种机制,比如Leader选举,分布式锁和队列。
Storm主要使用ZooKeeper来协调一个集群中的状态信息,比如任务的分配情况,worker的状态,supervisor之间的nimbus的拓扑度量。nimbus和supervisor节点之间的通信主要是结合ZooKeeper的状态变更通知和监控通知来处理的。
Storm对ZooKeeper的使用相对比较轻量化,不会造成很重的资源负担。对于重量级的数据传输操作,比如发布topology时传输jar包,Storm依赖Thirft进行通信。我们将会看到,topology组件之间的数据传输(最影响效率的地方)是在底层进行的,并且经过了性能优化。
2.1.4 Storm的DRPC服务工作机制
Storm应用中的一个常见模式期望将Storm的并发性和分布式计算能力应用到“请求-响应”范式中。一个客户端进程或者应用提交了一个请求并同步地等待响应。这样的范式可能看起来和典型topology的高异步性、长时间运行的特点恰恰相反,Storm具有事务处理的特性来实现这种应用场景,如图2-2所示。


5dbc136a16bbe42164bfe283cad141e26f2122a0

为了实现这个功能,Storm将额外的服务(Storm DRPC)以及spout和bolt整合在一起工作,提供了可扩展的分布式RPC能力。
DRPC功能是完全是可选的,当Storm集群中的应用有使用这个功能时,DRPC服务节点才是必须的。
2.1.5 Storm UI
Storm UI也是可选功能,非常有用,会提供一个基于Web的GUI来监控Storm集群,对正在运行的topology有一定的管理功能。Storm UI提供了已经发布的topology的统计信息,对监控Storm集群的运转和topology的功能有很大帮助,如图2-3所示。


<a href=https://yqfile.alicdn.com/1efd747bc6c4146a092e5a7ff476da7966ae25ca.png" >

Storm UI只能报告由nimubs的trhift API获取的信息,不会影响到topology上其他功能。Storm UI可以随时开关而不影响任何topology的运行,在那里它完全是无状态的。它还可以用配置来进行一些简单的管理功能,如开启、停止、暂停和重新均衡负载topology。

版权声明:如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developerteam@list.alibaba-inc.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

华章出版社

官方博客
官网链接