Storm事务 Topology 的实现概述

事务Topology的实现概述

1.事务类型的Spout节点实际上是一个子Topology, 它包含一个协调Spout节点（ Coordinator )，以及一些消息发送Bolt节点（ Emitter )。

2.协调Spout节点的并行度为1, 消息发送Bolt节点的并行度则可根据需要来设定。

3.协调Spout节点并不发送实际的数据， 而是将事务尝试发送到消息将Bolt节点中。 事务尝试（ TransactionalAttempt ) 包含一个Biglnteger类型的事务号以及长整型类型的尝试号。当事务被重传时， 事务号是相同的， 但是尝试号不同。

4.协调Spout节点与消息发送Bolt节点之间采用全局分组方式进行消息传输， 也就意味着从协调Spout中发送的一条事务尝试消息都会被所有的消息发送Bolt节点接收。 每个消息发送Bolt节点会根据收到的事务尝试消息来发送与该事务对应的消息集合。 消息发送Bolt节点之间则需要对该事务所对应的数据进行协作， 即每个节点只负责事务的一部分数据。

5.当所有的消息发送节点都成功处理了该事务在该节点上所对应的消息后（ 通过Storm的Ack框架 ）， 协调Spout节点认为该事务已经被成功处理， 协调Spout节点将会产生并发送下一个事务尝试消息。

6.协调Spout节点中含有两个系统输出流： 事务消息流（ Batch流 ） 和事务提交流（ Commit流 ）。协调Spout节点会向事务消息流发送事务尝试消息， 向事务提交流发送事务的提交消息。

7.事务的处理实际上被分成以下两个阶段
事务处理阶段：协调Spout节点向消息发送节点发送事务尝试消息， 消息发送Bolt节点，发送该事务所对应的消息集合， 然后Storm系统开始处理这些消息。 该阶段属于事务的处理阶段。
事务提交阶段：通过系统的Ack框架， 当系统中的消息均被成功处理后， 协调Spout节点将收到其发送的事务尝试消息的Ack, 这表明事务处理阶段已经结束。

事务Topology的特点

在事务类型的Topology中， 可以定义事务提交Bolt ( CommitBolt ), 这种类型的Bolt节点可保证其处理的事务会按照顺序被提交。 事务的提交操作可能是将事务的处理结果存储起来。

在Storm中， 若消息丢失或者超时， 一个事务可能会被重做， 此时将导致消息重复。 但由于提交节点可以保证事务是按照顺序提交的， 此处更利于去重操作。 例如， 若每个事务对应的数据在重传时相同， 则在提交节点看到相同的事务序号时， 可认为该事务是重传的事务， 进而将其忽略掉。

当事务的处理阶段完成后， 协调Spout节点会检查该事务是否为下一个要提交的事务， 若是则将该事务的事务序号发送到事务提交流。 所有的事务提交Bolt节点都会接收该流的消息， 并会在收到事务提交消息后， 对该事务进行提交。 可以看出， 当事务处理阶段结束后， 并不一定会立即进人事务提交阶段， 它需要等待之前的事务都已经被成功提交后， 方可进人事务提交阶段。 此
处， 保证了事务按顺序提交。

通过系统的Ack框架， 在收到事务提交消息的Ack之后， 该事务被认为已成功处理。

在事务提交节点， 将调用节点的finishBatch方法完成事务的提交。

在事务处理阶段， 属于一个事务的消息以及所有衍生出来的消息均以协调Spout节点发送的事务尝试消息为根。 基于Storm的Ack框架， 当所有的消息均被成功处理之后， 协调Spout节点将收到一条事务尝试消息的Ack。 若消息处理失败或者超时， 协调Spout节点则会收到失败消息， 事务类型的Topology此时会对该事务进行重传处理。 这样， 事务类型的Topology便可以保证消息不丢失。 实际上， 事务尝试消息会存储于ZooKeeper中， 所以即便Topology异常停止运行， 仍可保证在其重新启动时事务能被正确重传。

根据其中Spout类型的不同， 事务Topology可被进一步分为基本事务Topology和不透明事务Topology ( Opaque Transactional Topology )。