Storm知识整理

阅读Storm的相关知识也已经一个多月了,除开Storm的基本框架之外,Storm代码方面的细节,在阅读中也有所积累,但一直没有总结出来,这里略作记录。

SpoutOutputCollector

作为输出收集器,它暴露了从Spout中发射的元组的API。它与bolt中的OutputCollector不同的是,它可以在元组上捆绑消息,使得它在接下来可以被ack或被fail。同时它还是Storm保证每条消息处理至少一次的api的一部分。

OutputFieldsDeclarer

官方说法是保证一个区域有一个id对应一个流,我的理解是可以为某个Spout或Bolt的输出流进行编号,以便其他Bolt接受。

关于Bolt如何处理Tuple

Bolt 处理 tuple 的一种通用模式是在 execute 方法中读取输入 tuple、发送出基于输入 tuple 的新 tuple,然后在方法末尾对 tuple 进行应答。大部分 Bolt 都会使用这样的过程。这些 Bolt 大多属于过滤器或者简单的处理函数一类。Storm 有一个可以简化这种操作的简便接口,称为 BasicBolt。

DRPC

要了解Storm中的DRPC是什么,首先要知道RPC是远程过程调用。分布式远程过程调用中的服务端由四部分组成:包括一个DRPC Server, 一个 DPRC Spout,一个Topology和一个ReturnResult。

Stream grouping

Stream Grouping控制着元组是如何在Topology中进行路由的,并且可以帮助我们理解这些内容(元组如何转移)。

Remote mode 和 Local mode

在使用Storm时,我们通过Local mode来进行拓扑的调试,Storm的客户端Client只用于Remote mode。

initState

这个方法是整个框架在Bolt的初始化过程中,利用之前Bolt处理时存下的状态信息来使用的。这个过程在准备过程结束之后,在Bolt开始处理任何Tuple之前进行。

如何设置状态持久性

我们需要使用一个提供持久性的State Provider,方法是设置storm配置文件中的topology.state.provider。

如何使用Checkpoint Spout保证Storm的状态持久性

当Topology中有至少一个Bolt实现了IStateBolt,Topology Builder就会自动启用一个CheckPoint Spout

State的实现

对于有状态的Topology,Topology Builder会将IStatefulBolt包装在StatefulBoltExecutor中,当他接收CheckPoint Tuples时处理状态提交。无状态的节点被包装在CheckpointTupleForwarder中,它只是去传递这些CheckPoint Tuples使他们能够在Topology中进行流动。

Nimbus

Nimbus负责将代码分发到集群的各个部分,将任务分配到每台机器上,并且监视failures。

Worker Node

在每一个Worker Node中都运行着一个”Supervisor“节点,这个节点监听着那些分配在它的机器上的任务,并且在必要的时候运行或者终止Worker进程本身,

Storm的稳定性

不论是Nimbus daemon还是Supervisor daemons都是fail-fast和stateless的,所有的状态都被存在Zookeeper中或者在本地硬盘上,这意味着你可以随便Kill掉几个Nimbus或者Supervisor,结果他们会开始备份,好像什么都没发生一样。这个设计使得Storm的集群非常稳定。

发表评论

电子邮件地址不会被公开。 必填项已用*标注