Storm消息可靠性的保障机制

参考【并发编程网】的Storm官方教程翻译

以WordCountToPology为例：

 // 构造Topology
        TopologyBuilder builder = new TopologyBuilder();

        builder.setSpout(SPOUT_ID,new SentenceSpout(), 2)// 指定 Spout ,2 指的是使用2个executor来运行spout
                .setNumTasks(4);//指定tasks的数量

        // 指定 SentenceSpout 向SplitBolt发射tuple  随机分组
        builder.setBolt(SPLIT_BOLT, new SplitBolt(), 3) // 3 指的就是使用3个executor来执行bolt
                .shuffleGrouping(SPOUT_ID);  

        builder.setBolt(COUNT_BOLT, new CountBolt(), 2).fieldsGrouping(SPLIT_BOLT, new Fields("word"));

        builder.setBolt(PRINT_BOLT, new PrintBolt(), 1).globalGrouping(COUNT_BOLT); // 全局分组

这个topology从一个队列中读取句子，然后将句子分解成若干个单词，然后将它每个单词和该单词的数量发送出去。这种情况下，从 spout 中发出的 tuple 就会产生很多基于它创建的新 tuple：包括句子中单词的 tuple 和 每个单词的个数的 tuple。这些消息构成了这样一棵树：

如果这棵 tuple 树发送完成，并且树中的每一条消息都得到了正确的处理，就表明发送 tuple 的 spout 已经得到了“完整性处理”。对应的，如果在指定的超时时间内 tuple 树中有消息没有完成处理就意味着这个 tuple 失败了。这个超时时间可以使用 Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS 参数在构造topology时进行配置，如果不配置，则默认时间为 30 秒。

在消息得到完整性处理后或者处理失败后会发生什么

为了理解这个问题，让我们先了解一下 tuple 的生命周期。下面是定义 spout 的接口（可以在 Javadoc 中查看更多细节信息）：

public interface ISpout extends Serializable {
    void open(Map var1, TopologyContext var2, SpoutOutputCollector var3);

    void close();

    void activate();

    void deactivate();

    void nextTuple();

    void ack(Object var1);

    void fail(Object var1);
}

首先，通过调用 Spout 的 nextTuple 方法，Storm 向 Spout 请求一个 tuple。Spout 会使用 open 方法中提供的SpoutOutputCollector 向它的一个输出数据流中发送一个 tuple。在发送 tuple 的时候，Spout 会提供一个 “消息 id”，这个 id 会在后续过程中用于识别 tuple。

使用 Storm 的可靠性机制的时候你需要注意两件事：首先，在 tuple 树中创建新节点连接时务必通知 Storm；其次，在每个 tuple 处理结束的时候也必须向 Storm 发出通知。通过这两个操作，Storm 就能够检测到 tuple 树会在何时完成处理，并适时地调用 ack 或者 fail 方法。Storm 的 API 提供了一种非常精确的方式来实现着两个操作

因此SentenceSpout需要做如下修改,在nextTuple方法中，发送tuple时，增加一个msgId；如果返回确认成功，则调用ack方法，把执行成功的msgId从缓存中移除，如果超时，或者异常，在调用fail方法，进行重试。具体实现如下：

public class SentenceSpout extends BaseRichSpout{

    private static final Logger logger = LoggerFactory.getLogger(SentenceSpout.class);

    /**
     * tuple发射器
     */
    private SpoutOutputCollector collector;

    private static final String[] SENTENCES = {
            "hadoop yarn mapreduce spark",
            "flume hadoop hive spark",
            "oozie yarn spark storm",
            "storm yarn mapreduce error",
            "error flume storm spark"
    };

    //把已发送的tuple缓存到Map中，key就是msg id
    private Map<Object,Values> hasSendTuples;
    //如果tuple在后续处理中出现异常时，我们需要采取一些措施，这里我们采用重试
    //因此，把需要重试的tuple缓存下来，key为msg id
    private Map<Object,Integer>  hasRetries;
    //设置需要重试的最大次数
    private int maxRt;

    /**
     * 用来声明该组件向后面组件发射的tuple的key名称依次是什么
     * @param declarer
     */
    @Override
    public void declareOutputFields(OutputFieldsDeclarer declarer) {
        declarer.declare(new Fields("sentence"));
    }

    @Override
    public Map<String, Object> getComponentConfiguration() {
        // 用于指定只针对本组件的一些特殊配置
        return null;
    }

    /**
     * Spout 组件的初始化方法
     * 创建SentenceSpout组件的实例对象时调用，只执行一次
     * @param conf
     * @param context
     * @param collector
     */
    @Override
    public void open(Map conf, TopologyContext context, SpoutOutputCollector collector) {

        // 用实例变量来接收tuple发射器
        this.collector = collector;
        this.hasSendTuples = new HashMap<>();
        this.hasRetries = new HashMap<>();
        //获取配置的最大重试次数
        Object maxRetryTimes = conf.get("MAX_RETRY_TIMES");
        maxRt = Integer.valueOf(maxRetryTimes.toString());
    }

    @Override
    public void close() {
        // 收尾工作
    }

    @Override
    public void activate() {

    }

    @Override
    public void deactivate() {

    }

    /**
     * Spout组件的核心方法
     * 循环调用
     * 1）如何从数据源上获取数据 逻辑 写在该方法中
     * 2）对获取的数据进行一些简单的处理
     * 3) 封装tuple，并且向后面的bolt发射 （其实只能指定tuple的value值依次是什么）
     */
    @Override
    public void nextTuple() {
        // 随机从数组中获取一一条语句（模拟从数据源中获取数据）
        String sentence = SENTENCES[new Random().nextInt(SENTENCES.length)];

        if(sentence.contains("error")){
            logger.error("记录有问题：" + sentence);
        }else{
            // 封装成tuple

            //this.collector.emit(new Values(sentence));
            Object msgId = new Object();
            // a）启用消息可靠性保障机制：Spout中给每个tuple一个msgId来标识
            Values tuple = new Values(sentence);
            this.collector.emit(tuple, msgId);
            // b)添加到内存缓存起来
            this.hasSendTuples.put(msgId,tuple );
        }

    }

    @Override
    public void ack(Object msgId) {
        // 表示后面的组件对tuple处理完，并确认成功后，调用该方法
        // 从内存中将处理成功的去掉
        logger.info("Tuple:"+ msgId +",被成功处理....");
        System.err.println("Tuple:"+ msgId +",被成功处理....");
        if(hasSendTuples.containsKey(msgId)){
            //把成功处理的msgId移除
            hasSendTuples.remove(msgId);
        }
    }

    @Override
    public void fail(Object msgId) {
        // 后面组件接收tuple超时，后面组件没有接收到，或者明确 确认失败，调用该方法
        // 比如：重试 最大重试次数
        logger.info("Tuple:" + msgId + "，处理失败或者发射超时...");
        System.err.println("Tuple:" + msgId + ",处理失败或者发射超时...");
        if(!hasSendTuples.containsKey(msgId)){
            return;
        }

        int hasRetry = 0;
        if(hasRetries.containsKey(msgId)){
            hasRetry = hasRetries.get(msgId);
        }

        if(hasRetry < maxRt){
            // 重试
            this.collector.emit(hasSendTuples.get(msgId),msgId);
            hasRetry ++;
            hasRetries.put(msgId,hasRetry);
        }else{
            //超过了最大重试次数则直接丢弃
            this.hasRetries.remove(msgId);
            this.hasSendTuples.remove(msgId);
        }
    }
}

tuple 会被发送到对应的 bolt 中去，在这个过程中，Storm 会很小心地跟踪创建的消息树。如果 Storm 检测到某个 tuple 被完整处理， Storm 会根据 Spout 提供的“消息 id”调用最初发送 tuple 的 Spout 任务的 ack 方法。对应的，Storm 在检测到 tuple 超时之后就会调用 fail 方法。注意，对于一个特定的 tuple，响应（ack）和失败处理（fail）都只会由最初创建这个 tuple 的任务执行。也就是说，及时 Spout 在集群中有很多个任务，某个特定的 tuple 也只会由创建它的那个任务——而不是其他的任务——来处理成功或失败的结果

SplitBolt接收到来自SentenceSpout发送的tuple后，开始进行处理，并且在处理完毕后，需要给SentenceSpout发送确认信息。主要修改execute方法，进行锚定（anchoring）

public class SplitBolt implements IRichBolt{

    /**
     * bolt组件中发射器
     */
    private OutputCollector collector;

    /**
     * Bolt组件的初始化方法
     *
     * @param stormConf
     * @param context
     * @param collector
     */
    @Override
    public void prepare(Map stormConf, TopologyContext context, OutputCollector collector) {

        this.collector = collector;
    }

    /**
     * 每接收到前面组件发射过来的tuple就调用一次
     *
     * bolt对数据处理逻辑写在该方法中
     * 处理完后的数据封装成tuple(value部分），继续发射给后面的组件
     * 或者执行比如写到数据库、打印到文件等等操作（终点）
     * @param input
     */
    @Override
    public void execute(Tuple input) {
        try {
            String sentence = input.getStringByField("sentence");

            if (sentence != null && !"".equals(sentence)) {
                String[] words = sentence.split(" ");
                for (String word : words) {
                   // this.collector.emit(new Values(word));
                    // 锚定 tuple，构造tuple的某个分组
                    this.collector.emit(input, new Values(word));
                }
            }

            // 处理接收到的tuple之后，记得发送确认成功
            this.collector.ack(input);
        }catch (Exception e){
            // 处理失败，发送确认失败
            this.collector.fail(input);
        }
    }

    @Override
    public void cleanup() {

    }

    @Override
    public void declareOutputFields(OutputFieldsDeclarer declarer) {
        declarer.declare(new Fields("word"));
    }

    @Override
    public Map<String, Object> getComponentConfiguration() {
        return null;
    }
}

通过将输入 tuple 指定为 emit 方法的第一个参数，每个单词 tuple 都被“锚定”了。这样，如果单词 tuple 在后续处理过程中失败了，作为这棵 tuple 树的根节点的原始 Spout tuple 就会被重新处理。相对应的，如果这样发送 tuple：

this.collector.emit( new Values(word));

就称为“非锚定”。在这种情况下，下游的 tuple 处理失败不会触发原始 tuple 的任何处理操作。有时候发送这种“非锚定” tuple 也是必要的，这取决于你的topology的容错性要求。

一个输出 tuple 可以被锚定到多个输入 tuple 上，这在流式连接或者聚合操作时很有用。显然，一个多锚定的 tuple 失败会导致 Spout 中多个 tuple 的重新处理。多锚定操作是通过指定一个 tuple 列表而不是单一的 tuple 来实现的，如下面的例子所示：

List<Tuple> anchors = new ArrayList<Tuple>();
anchors.add(tuple1);
anchors.add(tuple2);
this.collector.emit(anchors, new Values(1, 2, 3));

多锚定操作会把输出 tuple 添加到多个 tuple 树中。注意，多锚定也可能会打破树的结构从而创建一个 tuple 的有向无环图（DAG），如下图所示：

锚定其实可以看作是将 tuple 树具象化的过程 —— 在结束对一棵 tuple 树中一个单独 tuple 的处理的时候，后续以及最终的 tuple 都会在 Storm 可靠性 API 的作用下得到标定。这是通过 OutputCollector 的 ack 和 fail 方法实现的。如果你再回过头看一下 SplitSentence 的例子，你就会发现输入 tuple 是在所有的单词 tuple 发送出去之后被 ack 的。

你可以使用 OutputCollector 的 fail 方法来使得位于 tuple 树根节点的 Spout tuple 立即失败。例如，你的应用可以在建立数据库连接的时候抓取异常，并且在异常出现的时候立即让输入 tuple 失败。通过这种立即失败的方式，原始 Spout tuple 就会比等待 tuple 超时的方式响应更快。

每个待处理的 tuple 都必须显式地应答（ack）或者失效（fail）。因为 Storm 是使用内存来跟踪每个 tuple 的，所以，如果你不对每个 tuple 进行应答或者失效，那么负责跟踪的任务很快就会发生内存溢出。

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

public class SplitSentence extends BaseBasicBolt {
 public void execute(Tuple tuple, BasicOutputCollector collector) {
        try {
            String sentence = tuple.getStringByField("sentence");

            if (sentence != null && !"".equals(sentence)) {
                String[] words = sentence.split(" ");
                for (String word : words) {
                    this.collector.emit(new Values(word));
                }
            }
        }catch (Exception e){
            // 处理失败，发送确认失败
            this.collector.fail(tuple);
        }
    }

这个实现方式比之前的方式要简单许多，而且在语义上有着完全一致的效果。发送到 BasicOutputCollector 的 tuple 会被自动锚定到输入 tuple 上，而且输入 tuple 会在 execute 方法结束的时候自动应答。

相对应的，执行聚合或者联结操作的 Bolt 可能需要延迟应答 tuple，因为它需要等待一批 tuple 来完成某种结果计算。聚合和联结操作一般也会需要对他们的输出 tuple 进行多锚定。这个过程已经超出了 IBasicBolt 的应用范围。

Storm可靠性的实现方法

Storm 的topology有一些特殊的称为“acker”的任务，这些任务负责跟踪每个 Spout 发出的 tuple 的 DAG。当一个 acker 发现一个 DAG 结束了，它就会给创建 spout tuple 的 Spout 任务发送一条消息，让这个任务来应答这个消息。你可以使用Config.TOPOLOGY_ACKERS 来配置topology的 acker 数量。Storm 默认会将 acker 的数量设置为一，不过如果你有大量消息的处理需求，你可能需要增加这个数量。

理解 Storm 的可靠性实现的最好方式还是通过了解 tuple 和 tuple DAG 的生命周期。当一个 tuple 在topology中被创建出来的时候 —— 不管是在 Spout 中还是在 Bolt 中创建的 —— 这个 tuple 都会被配置一个随机的 64 位 id。acker 就是使用这些 id 来跟踪每个 spout tuple 的 tuple DAG 的。

Spout tuple 的 tuple 树中的每个 tuple 都知道 spout tuple 的 id。当你在 bolt 中发送一个新 tuple 的时候，输入 tuple 中的所有 spout tuple 的 id 都会被复制到新的 tuple 中。在 tuple 被 ack 的时候，它会通过回掉函数向合适的 acker 发送一条消息，这条消息显示了 tuple 树中发生的变化。也就是说，它会告诉 acker 这样一条消息：“在这个 tuple 树中，我的处理已经结束了，接下来这个就是被我标记的新 tuple”。

以下图为例，如果 D tuple 和 E tuple 是由 C tuple 创建的，那么在 C 应答的时候 tuple 树就会发生变化：

由于在 D 和 E 添加到 tuple 树中的时候 C 已经从树中移除了，所以这个树并不会被过早地结束。

关于 Storm 如何跟踪 tuple 树还有更多的细节。正如上面所提到的，你可以随意设置topology中 acker 的数量。这就会引起下面的问题：当 tuple 在topology中被 ack 的时候，它是怎么知道向那个 acker 任务发送信息的？

对于这个问题，Storm 实际上是使用哈希算法来将 spout tuple 匹配到 acker 任务上的。由于每个 tuple 都会包含原始的 spout tuple id，所以他们会知道需要与哪个 acker 任务通信。

关于 Storm 的另一个问题是 acker 是如何知道它所跟踪的 spout tuple 是由哪个 Spout 任务处理的。实际上，在 Spout 任务发送新 tuple 的时候，它也会给对应的 acker 发送一条消息，告诉 acker 这个 spout tuple 是与它的任务 id 相关联的。随后，在 acker 观察到 tuple 树结束处理的时候，它就会知道向哪个 Spout 任务发送结束消息。

Acker 实际上并不会直接跟踪 tuple 树。对于一棵包含数万个 tuple 节点的树，如果直接跟踪其中的每个 tuple，显然会很快把这个 acker 的内存撑爆。所以，这里 acker 使用一个特殊的策略来实现跟踪的功能，使用这个方法对于每个 spout tuple 只需要占用固定的内存空间（大约 20 字节）。这个跟踪算法是 Storm 运行的关键，也是 Storm 的一个突破性技术。

在 acker 任务中储存了一个表，用于将 spout tuple 的 id 和一对值相映射。其中第一个值是创建这个 tuple 的任务 id，这个 id 主要用于在后续操作中发送结束消息。第二个值是一个 64 比特的数字，称为“应答值”（ack val）。这个应答值是整个 tuple 树的一个完整的状态表述，而且它与树的大小无关。因为这个值仅仅是这棵树中所有被创建的或者被应答的 tuple 的 tuple id 进行异或运算的结果值。

当一个 acker 任务观察到“应答值”变为 0 的时候，它就知道这个 tuple 树已经完成处理了。因为 tuple id 实际上是随机生成的 64 比特数值，所以“应答值”碰巧为 0 是一种极小概率的事件。理论计算得以得出，在每秒应答一万次的情况下，需要 5000 万年才会发生一次错误。而且即使是这样，也仅仅会在 tuple 碰巧在topology中失败的时候才会发生数据丢失的情况。

假设你现在已经理解了这个可靠性算法，让我们再分析一下所有失败的情形，看看这些情形下 Storm 是如何避免数据缺失的：

由于任务（线程）挂掉导致 tuple 没有被应答（ack）的情况：这时位于 tuple 树根节点的 spout tuple 会在任务超时后得到重新处理。
Acker 任务挂掉的情形：这种情况下 acker 所跟踪的所有 spout tuple 都会由于超时被重新处理。
Spout 任务挂掉的情形：这种情况下 Spout 任务的来源就会负责重新处理消息。例如，对于像 Kestrel 和 RabbitMQ 这样的消息队列就会在客户端断开连接时将所有的挂起状态的消息放回队列（关于挂起状态的概念可以参考Storm 的容错性——译者注）。
综上所述，Storm 的可靠性机制完全具备分布的、可伸缩的、容错的特征。

调整可靠性

由于 acker 任务是轻量级的，在拓扑中你并不需要很多 acker 任务。你可以通过 Storm UI 监控他们的性能（acker 任务的 id 为“__acker”）。如果发现观察结果存在问题，你可能就需要增加更多的 acker 任务。

如果你不关注消息的可靠性 —— 也就是说你不关心在失败情形下发生的 tuple 丢失 —— 那么你就可以通过不跟踪 tuple 树的处理来提升拓扑的性能。由于 tuple 树中的每个 tuple 都会带有一个应答消息，不追踪 tuple 树会使得传输的消息的数量减半。同时，下游数据流中的 id 也会变少，这样可以降低网络带宽的消耗。

有三种方法可以移除 Storm 的可靠性机制。第一种方法是将 Config.TOPOLOGY_ACKERS 设置为0，在这种情况下，Storm 会在 Spout 发送 tuple 之后立即调用 ack 方法，tuple 树叶就不会被跟踪了。

第二种方法是基于消息本身移除可靠性。你可以通过在 SpoutOutputCollector.emit 方法中省略消息 id 来关闭 spout tuple 的跟踪功能。

最后，如果你不关心拓扑中的下游 tuple 是否会失败，你可以在发送 tuple 的时候选择发送“非锚定”的（unanchored）tuple。由于这些 tuple 不会被标记到任何一个 spout tuple 中，显然在他们处理失败的时候不会引起任何 spout tuple 的重新处理（注意，在使用这种方法时，如果上游有 spout 或 bolt 仍然保持可靠性机制，那么需要在 execute 方法之初调用OutputCollector.ack 来立即响应上游的消息，否则上游组件会误认为消息没有发送成功导致所有的消息会被反复发送——译者注）。