FW:分布式实时计算storm 原理简介及单机版安装指南（4）_拔剑-浆糊的传说

本文链接：https://blog.csdn.net/qq_40287292/article/details/109666162

7、流分组策略(Stream grouping)

流分组策略告诉topology如何在两个组件之间发送tuple。要记住， spouts和bolts以很多task的形式在topology里面同步执行。如果从task的粒度来看一个运行的topology，它应该是这样的:

从task角度来看topology

当Bolt A的一个task要发送一个tuple给Bolt B，它应该发送给Bolt B的哪个task呢？

stream grouping专门回答这种问题的。在我们深入研究不同的stream grouping之前，让我们看一下storm-starter里面的另外一个topology。WordCountTopology读取一些句子，输出句子里面每个单词出现的次数.

 
TopologyBuilder builder =newTopologyBuilder();
 
  
 
builder.setSpout(1,newRandomSentenceSpout(),5);
 
builder.setBolt(2,newSplitSentence(),8)
 
        .shuffleGrouping(1);
 
builder.setBolt(3,newWordCount(),12)
 
        .fieldsGrouping(2,newFields("word"));

SplitSentence对于句子里面的每个单词发射一个新的tuple, WordCount在内存里面维护一个单词->次数的mapping， WordCount每收到一个单词，它就更新内存里面的统计状态。

有好几种不同的stream grouping:

最简单的grouping是shuffle grouping, 它随机发给任何一个task。上面例子里面RandomSentenceSpout和SplitSentence之间用的就是shuffle grouping, shuffle grouping对各个task的tuple分配的比较均匀。
一种更有趣的grouping是fields grouping, SplitSentence和WordCount之间使用的就是fields grouping, 这种grouping机制保证相同field值的tuple会去同一个task，这对于WordCount来说非常关键，如果同一个单词不去同一个task，那么统计出来的单词次数就不对了。

fields grouping是stream合并，stream聚合以及很多其它场景的基础。在背后呢， fields grouping使用的一致性哈希来分配tuple的。

还有一些其它类型的stream grouping. 你可以在Concepts一章里更详细的了解。

下面是一些常用的 “路由选择” 机制：

Storm的Grouping即消息的Partition机制。当一个Tuple被发送时，如何确定将它发送个某个（些）Task来处理？？

l ShuffleGrouping：随机选择一个Task来发送。

l FiledGrouping：根据Tuple中Fields来做一致性hash，相同hash值的Tuple被发送到相同的Task。

l AllGrouping：广播发送，将每一个Tuple发送到所有的Task。

l GlobalGrouping：所有的Tuple会被发送到某个Bolt中的id最小的那个Task。

l NoneGrouping：不关心Tuple发送给哪个Task来处理，等价于ShuffleGrouping。

l DirectGrouping：直接将Tuple发送到指定的Task来处理。

8、使用别的语言来定义Bolt

Bolt可以使用任何语言来定义。用其它语言定义的bolt会被当作子进程(subprocess)来执行， storm使用JSON消息通过stdin/stdout来和这些subprocess通信。这个通信协议是一个只有100行的库， storm团队给这些库开发了对应的Ruby, Python和Fancy版本。

下面是WordCountTopology里面的SplitSentence的定义:

 
publicstaticclassSplitSentenceextendsShellBoltimplementsIRichBolt {
 
    publicSplitSentence() {
 
        super("python","splitsentence.py");
 
    }
 
  
 
    publicvoiddeclareOutputFields(OutputFieldsDeclarer declarer) {
 
        declarer.declare(newFields("word"));
 
    }
 
}

SplitSentence继承自ShellBolt并且声明这个Bolt用python来运行，并且参数是: splitsentence.py。下面是splitsentence.py的定义:

 
importstorm
 
  
 
classSplitSentenceBolt(storm.BasicBolt):
 
    defprocess(self, tup):
 
        words=tup.values[0].split(" ")
 
        forwordinwords:
 
          storm.emit([word])
 
  
 
SplitSentenceBolt().run()

更多有关用其它语言定义Spout和Bolt的信息，以及用其它语言来创建topology的信息可以参见: Using non-JVM languages with Storm.

9、可靠的消息处理

在这个教程的前面，我们跳过了有关tuple的一些特征。这些特征就是storm的可靠性API： storm如何保证spout发出的每一个tuple都被完整处理。看看《storm如何保证消息不丢失》以更深入了解storm的可靠性API.

Storm允许用户在Spout中发射一个新的源Tuple时为其指定一个MessageId，这个MessageId可以是任意的Object对象。多个源Tuple可以共用同一个MessageId，表示这多个源Tuple对用户来说是同一个消息单元。Storm的可靠性是指Storm会告知用户每一个消息单元是否在一个指定的时间内被完全处理。完全处理的意思是该MessageId绑定的源Tuple以及由该源Tuple衍生的所有Tuple都经过了Topology中每一个应该到达的Bolt的处理。

在Spout中由message 1绑定的tuple1和tuple2分别经过bolt1和bolt2的处理，然后生成了两个新的Tuple，并最终流向了bolt3。当bolt3处理完之后，称message 1被完全处理了。

Storm中的每一个Topology中都包含有一个Acker组件。Acker组件的任务就是跟踪从Spout中流出的每一个messageId所绑定的Tuple树中的所有Tuple的处理情况。如果在用户设置的最大超时时间内这些Tuple没有被完全处理，那么Acker会告诉Spout该消息处理失败，相反则会告知Spout该消息处理成功。

那么Acker是如何记录Tuple的处理结果呢？？

A xor A = 0.

A xor B…xor B xor A = 0，其中每一个操作数出现且仅出现两次。

在Spout中，Storm系统会为用户指定的MessageId生成一个对应的64位的整数，作为整个Tuple Tree的RootId。RootId会被传递给Acker以及后续的Bolt来作为该消息单元的唯一标识。同时，无论Spout还是Bolt每次新生成一个Tuple时，都会赋予该Tuple一个唯一的64位整数的Id。

当Spout发射完某个MessageId对应的源Tuple之后，它会告诉Acker自己发射的RootId以及生成的那些源Tuple的Id。而当Bolt处理完一个输入Tuple并产生出新的Tuple时，也会告知Acker自己处理的输入Tuple的Id以及新生成的那些Tuple的Id。Acker只需要对这些Id进行异或运算，就能判断出该RootId对应的消息单元是否成功处理完成了。