storm是怎样保证at least once语义的

背景

本篇看看storm是通过什么机制来保证消息至少处理一次的语义的。

storm中的一些原语

要说明上面的问题，得先了解storm中的一些原语，比方：

tuple和message

在storm中，消息是通过tuple来抽象表示的。每一个tuple知道它从哪里来，应往哪里去，包括了其在tuple-tree（假设是anchored的话）或者DAG中的位置。等等信息。
spout

spout充当了tuple的发送源，spout通过和其他消息源，比方kafka交互，将消息封装为tuple，发送到流的下游。
bolt

bolt是tuple的实际处理单元，通过从spout或者还有一个bolt接收tuple，进行业务处理，将自己增加tuple-tree（通过在emit方法中设置anchors）或DAG。然后继续将tuple发送到流的下游。
acker

acker是一种特殊的bolt，其接收来自spout和bolt的消息，主要功能是追踪tuple的处理情况，假设处理完毕，会向tuple的源头spout发送确认消息，否则，会发送失败消息，spout收到失败的消息，依据配置和自己定义的情况会进行消息的丢弃、重放处理。

spout、bolt、acker的关系

spout将tuple发送给流的下游的bolts.
bolt收到tuple。处理后发送给下游的bolts.
spout向acker发送请求ack的消息.
bolt向acker发送请求ack的消息.
acker向bolt和spout发送确认ack的消息.

简单的关系例如以下所看到的：

上图展示了spout、bolts等形成了一个DAG，怎样追踪这个DAG的运行过程。就是storm保证仅处理一次消息的语义的机制所在。

storm怎样追踪消息（tuple）的处理

spout在调用emit/emitDirect方法发送tuple时，会以单播或者广播的方式，将消息发送给流的下游的component/task/bolt，假设配置了acker，那么会在每次emit调用之后，向acker发送请求ack的消息：

;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;; spout向acker发送请求ack消息

;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;; rooted?

表示是否设置了acker

(if (and rooted?

(not (.isEmpty out-ids)))

 (do

   (.put pending root-id [task-id

                          message-id

                          {:stream out-stream-id :values values}

                          (if (sampler) (System/currentTimeMillis))])

   (task/send-unanchored task-data

                         ;;表示这是一个流初始化的消息

                         ACKER-INIT-STREAM-ID

                         ;;将下游组件的out-id和0组成一个异或链。发送给acker用于追踪

                         [root-id (bit-xor-vals out-ids) task-id]

                         overflow-buffer))

 ;; 假设没有配置acker，则调用自身的ack方法

 (when message-id

   (ack-spout-msg executor-data task-data message-id

                  {:stream out-stream-id :values values}

                  (if (sampler) 0) "0:")))

从上面的代码能够看出，每次emit tuple后，spout会向acker发送一个流ID为ACKER-INIT-STREAM-ID的消息。用于将DAG或者tuple-tree中的节点信息交给acker，acker会利用这个信息来追踪tuple-tree或DAG的完毕。

而spout调用emit/emitDirect方法。将tuple发到下游的bolts。也同一时候会发送用于追踪DAG完毕情况的信息：

;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;; spout向流的下游emit消息

;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(let [tuple-id (if rooted?

                ;; 假设有acker，tuple的MessageId会包括一个<root-id,id>的哈希表

                ;; root-id和id都是long型64位整数

                (MessageId/makeRootId root-id id)

                (MessageId/makeUnanchored))

     ;;实例化tuple

     out-tuple (TupleImpl. worker-context

                           values

                           task-id

                           out-stream-id

                           tuple-id)]

 ;; 发送至队列，终于发送给流的下游的task/bolt

 (transfer-fn out-task

              out-tuple

              overflow-buffer)

 ))

这个追踪信息是什么呢？

假设是spout -> bolt或者bolt -> bolt，这个信息就是tuple的MessageId，其内部维护一个哈希表：

// map anchor to id

private Map<Long, Long> _anchorsToIds;

键为root-id，表示spout，值表示tuple在tuple-tree或者DAG的根（spout）或者经过的边（bolt），但这里没有利用不论什么常规意义上的“树”的算法，而是採用异或的方式来存储这个值：

spout -> bolt。值被初始化为一个long型64位整数.
bolt -> bolt，值被初始化为一个long型64位整数，并和_anchorsToIds中的旧值进行按位异或，将结果更新到_anchorsToIds中.

假设是spout -> acker。或者bolt -> acker。那么用于追踪的是tuple的values：

spout -> acker ： [root-id (bit-xor-vals out-ids) task-id]
bolt -> acker : [root (bit-xor id ack-val) ..]

以下给出上面调用的bit-xor-vals和bit-xor方法的代码：

(defn bit-xor-vals

  [vals]

  (reduce bit-xor 0 vals))

(defn bit-xor

  "Bitwise exclusive or"

  {:inline (nary-inline 'xor)

   :inline-arities >1?

   :added "1.0"}

  ([x y] (. clojure.lang.Numbers xor x y))

  ([x y & more]

    (reduce1 bit-xor (bit-xor x y) more)))

演示样例

说起来有点抽象，看个样例。

假设我们有1个spout。n个bolt。1个acker：

1.spout

spout发送tuple到下游的bolts：

;; id_1是发送到bolt_1的tuple-id，依此类推

spout :

  ->bolt_1 : id_1

  ->bolt_2 : id_2

  ..

  ->bolt_n : id_n

2.bolt

bolt收到tuple。在execute方法中进行必要的处理，然后调用emit方法，最后调用ack方法：

;; bolt_1调用emit方法，追踪消息的这样一个值：让id_1和bid_1按位进行异或.

;; bid_1和id_1相似，是个long型的64位随机整数，在emit这一步生成

  bolt_1 emit : id_1 ^ bid_1

;; bolt_1调用ack方法，并将值表达为例如以下方式的异或链的结果

  bolt_1 ack : 0 ^ bid_1 ^ id_1 ^ bid_1 = 0 ^ id_1

以上。能够看出bolt进行了emit-ack组合后，其自身在异或链中的作用消失了，也就是说tuple在此bolt得到了处理。

（当然，此时的ack还没有得到acker的确认。假设acker确认了，那么上面所说的tuple在bolt得到了处理就成立了。

）

来看看acker的确认。

3.acker

acker收到来自spout的tuple：

;; spout发消息给acker，tuple的MessageId包括以下的异或链的结果

spout -> acker ： 0 ^ id_1 ^ id_2 ^ .. ^ id_n

;; acker收到来spout的消息，对tuple的ackVal进行处理，例如以下所看到的：

acker : 0 ^ (0 ^ id_1 ^ id_2 ^ .. ^ id_n) = 0 ^ id_1 ^ id_2 ^ .. ^ id_n

acker收到来自bolt的tuple：

;; bolt_1发消息给acker：

bolt_1 -> acker : 0 ^ id_1

;; acker维护的相应此tuple的源spout的ackVal :

ackVal : 0 ^ id_1 ^ id_2 ^ .. ^ id_n

;; acker进行确认，也就是拿上面的两个值进行异或：

acker : (0 ^ id_1) ^ (0 ^ id_1 ^ id_2 ^ .. ^ id_n) = 0 ^ id_2 ^ .. ^ id_n

能够看出。bolt_1向acker请求ack，acker收到请求ack，异或之后，id_1的作用消失。也就是说。bolt_1已处理完毕这个tuple。

所以。在acker看来，假设某个bolt的处理完毕，则此bolt在异或链中的作用就消失了。

假设全部的bolt 都得到处理。那么acker将会观察到ackVal值变成了0：

ackVal = 0

= (0 ^ id_1) ^ (0 ^ id_1 ^ .. ^ id_n) ^ .. (0 ^ id_n)

= (0 ^ 0) ^ (id_1 ^ id_1) ^ (id_2 ^ id_2) ^ .. ^ (id_n ^ id_n)

假设出现了ackVal = 0，说明两个可能：

spout发送的tuple都处理完毕。tuple-tree或者DAG已完毕。
概率性出错。也就是说在极小的概率下。即使不按上面的确认流程来走，异或链的结果也可能出现0.但这个概率极小。小到什么程度呢？

用官方的话说就是。假设每秒发送1万个ack消息，50,000,000年时才可能发生这样的情况。

假设ackVal不为0，说明tuple-tree或DAG没有完毕。

假设长时间不为0，通过超时。能够触发一个超时回调。在这个回调中调用spout的fail方法，来进行重放。

如此，就保证了消息处理不会漏掉。但可能会反复。

结语

以上。就是storm保证消息至少处理一次的语义的机制。