标签：
storm可以确保spout发送出来的每个消息都会被完整的处理。本章将会描述storm体系是如何达到这个目标的，并将会详述开发者应该如何使用storm的这些机制来实现数据的可靠处理。
TopologyBuilder builder = new TopologyBuilder(); builder.setSpout("sentences", new KestrelSpout("kestrel.backtype.com", 22133, "sentence_queue", new StringScheme())); builder.setBolt("split", new SplitSentence(), 10) .shuffleGrouping("sentences"); builder.setBolt("count", new WordCount(), 20) .fieldsGrouping("split", new Fields("word"));
一个消息(tuple)从spout发送出来，可能会导致成百上千的消息（tuple）基于此消息被创建。
我们来思考一下流式的“单词统计”的例子：storm任务从数据源（Kestrel queue）每次读取一个完整的英文句子；将这个句子分解为独立的单词，最后，实时的输出每个单词以及它出现过的次数。本例中，每个从spout发送出来的消息（每个英文句子）都会触发很多的消息被创建，那些从句子中分隔出来的单词就是被创建出来的新消息。
这些消息构成一个树状结构，我们称之为“tuple tree”，看起来如图1所示：
This topology reads sentences（句子） off of a Kestrel queue, splits the sentences into its constituent（构成） words, and then emits for each word the number of times it has seen that word before. A tuple coming off the spout triggers（引起，触发） many tuples being created based on it: a tuple for each word in the sentence and a tuple for the updated count for each word. The tree of messages looks something like this:
图1 示例tuple tree
在什么条件下，Storm才会认为一个从spout发送出来的消息被完整处理呢？答案就是下面的条件同时被满足：
如果在指定的时间内，一个消息衍生出来的tuple tree未被完全处理成功，则认为此消息未被完整处理。这个超时值可以通过任务级参数Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS 进行配置，默认超时值为30秒。
Storm considers a tuple coming off a spout "fully processed" when the tuple tree has been exhausted（耗尽的,用尽） and every message in the tree has been processed. A tuple is considered failed when its tree of messages fails to be fully processed within a specified timeout. This timeout can be configured（配置的） on a topology-specific basis using the Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS configuration and defaults to 30 seconds.
public static final String TOPOLOGY_MESSAGE_TIMEOUT_SECS
如果消息被完整处理或者未被完整处理，Storm会如何进行接下来的操作呢？为了弄清这个问题，我们来研究一下从spout发出来的消息的生命周期。这里列出了spout应该实现的接口：
public interface ISpout extends Serializable { void open(Map conf, TopologyContext context, SpoutOutputCollector collector); void close(); void nextTuple(); void ack(Object msgId); void fail(Object msgId); }
首先， Storm使用spout实例的nextTuple()方法从spout请求一个消息（tuple）。 收到请求以后，spout使用open方法中提供的SpoutOutputCollector向它的输出流发送一个或多个消息。每发送一个消息，Spout会给这个消息提供一个message ID，它将会被用来标识这个消息。假设我们从kestrel队列中读取消息，Spout会将kestrel 队列为这个消息设置的ID作为此消息的message ID。 向SpoutOutputCollector中发送消息格式如下：
_collector.emit(new Values("field1", "field2", 3) , msgId);
接下来， 这个发射的tuple被传送到消息处理者bolt那里， storm会跟踪由此所产生的这课tuple树，当检测到一个消息衍生出来的tuple tree被完整处理后， 那么storm会以最开始的那个message-id作为参数去调用消息源的ack方法。同理，如果某消息处理超时，则此消息对应的Spout的fail方法会被调用，调用时此消息的messageID会被作为参数传入。
注意：一个消息只会由发送它的那个spout任务来调用ack或fail。如果系统中某个spout由多个任务运行，消息也只会由创建它的spout任务来应答（ack或fail），决不会由其他的spout任务来应答。
Note that a tuple will be acked or failed by the exact（精确的） same Spout task that created it. So if a Spout is executing（执行） as many tasks across（穿过） the cluster, a tuple won‘t be acked or failed by a different task than the one that created it.
我们继续使用从kestrel队列中读取消息的例子来阐述高可靠性下spout需要做些什么(假设这个spout的名字是KestrelSpout)。
我们先简述一下kestrel消息队列：当KestrelSpout从kestrel队列中读取一个消息，表示它“打开”了队列中某个消息。这意味着，此消息并未从队列中真正的 taken off ，而是将此消息设置为“pending”（待定）状态，它等待来自客户端的应答，被应答以后，此消息才会被真正的从队列中删除。处于“pending”状态的消息不会被发给其他消息处理者了；另外，如果一个客户端意外的断开连接，则由此客户端“打开”的所有消息都会被重新加入到队列中。当消息被“打开”的时候，kestrel队列同时会为这个消息提供一个唯一的标识。
KestrelSpout就是使用这个唯一的标识作为这个tuple的messageID的。稍后当ack或fail被调用的时候，KestrelSpout会把ack或者fail连同messageID一起发送给kestrel队列，kestrel会将消息从队列中真正删除（take the message off）或者将它重新放回队列中。
英文原文：Let‘s use KestrelSpout again to see what a Spout needs to do to guarantee message processing. When KestrelSpout takes a message off the Kestrel queue, it "opens" the message. This means the message is not actually taken off the queue yet, but instead placed in a "pending" state waiting for acknowledgement that the message is completed. While in the pending state, a message will not be sent to other consumers of the queue. Additionally, if a client disconnects all pending messages for that client are put back on the queue. When a message is opened, Kestrel provides the client with the data for the message as well as a unique id for the message. The KestrelSpout uses that exact id as the "message id" for the tuple when emitting the tuple to the SpoutOutputCollector. Sometime later on, when ack or fail are called on the KestrelSpout, the KestrelSpout sends an ack or fail message to Kestrel with the message id to take the message off the queue or have it put back on.
为了使用Storm提供的可靠处理特性，我们需要做两件事情：
通过上面的两步，storm就可以检测到一个tuple tree何时被完全处理了，并且会调用相关的ack或fail方法。Storm提供了简单明了的方法来完成上述两步。
By doing both these things, Storm can detect when the tree of tuples is fully processed and can ack or fail the spout tuple appropriately. Storm‘s API provides a concise way of doing both of these tasks.
为tuple tree中指定的节点增加一个新的节点，我们称之为锚定（anchoring）。锚定是在我们发送消息的同时进行的。为了更容易说明问题，我们使用下面代码作为例子。本示例的bolt将包含整句话的消息(tuple)分解为一系列的子消息，每个子消息包含一个单词(tuple)。
public class SplitSentence extends BaseRichBolt { OutputCollector _collector; public void prepare(Map conf, TopologyContext context, OutputCollector collector) { _collector = collector; } public void execute(Tuple tuple) { String sentence = tuple.getString(0); for(String word: sentence.split(" ")) { _collector.emit(tuple, new Values(word)); } _collector.ack(tuple); } public void declareOutputFields(OutputFieldsDeclarer declarer) { declarer.declare(new Fields("word")); } }
看一下这个execute方法， emit的第一个参数是输入tuple， 第二个参数则是输出tuple， 这其实就是通过输入tuple anchoring了一个新的输出tuple。因为这个“单词tuple”被anchoring在“句子tuple”一起， 如果其中一个单词处理出错，那么这整个句子会被重新处理。作为对比， 我们看看如果通过下面这行代码来发射一个新的tuple的话会有什么结果。
_collector.emit(new Values(word));
如果以这种方式发送消息，将会导致这个消息不会被锚定。如果此tuple tree中的消息处理失败，派生此tuple tree的根消息不会被重新发送。根据任务的容错级别，有时候很适合发送一个非锚定的消息。这种方法发射会导致新发射的这个tuple脱离原来的tuple树(unanchoring), 如果这个tuple处理失败了， 整个句子不会被重新处理。到底要anchoring还是要 unanchoring则完全取决于你的业务需求。
一个输出消息可以被锚定在一个或者多个输入消息上tuple，这在做join或聚合的时候是很有用的（streaming joins or aggregations）。一个被多重锚定的消息tuple处理失败，会导致与之关联的多个spout消息被重新发送replayed。多重锚定通过在emit方法中指定多个输入消息tuple来实现：
List<Tuple> anchors = new ArrayList<Tuple>(); anchors.add(tuple1); anchors.add(tuple2); _collector.emit(anchors, new Values(1, 2, 3));
多重锚定会将被锚定的消息tuple加到多棵tuple tree上。
注意：多重绑定可能会破坏传统的树形结构，从而构成一个DAGs（有向无环图），如图2所示：
图2 多重锚定构成的钻石型结构
Storm的实现可以像处理树那样来处理DAGs。
我们通过anchoring来构造这个tuple树，最后一件要做的事情是在你处理完当个tuple的时候告诉storm, 通过OutputCollector类的ack和fail方法来做，如果你回过头来看看SplitSentence的例子， 你可以看到“句子tuple”在所有“单词tuple”被发出之后调用了ack。
你可以调用OutputCollector 的fail方法去立即将从消息源头发出的那个tuple标记为fail， 比如你查询了数据库，发现一个错误，你可以马上fail那个输入tuple， 这样可以让这个tuple被快速的重新处理， 因为你不需要等那个timeout时间来让它自动fail。
每个你处理的tuple， 必须被ack或者fail。因为storm追踪每个tuple要占用内存。所以如果你不ack/fail每一个tuple， 那么最终你会看到OutOfMemory错误。
很多bolt遵循特定的处理流程： 读取一个消息、发送它派生出来的子消息、在execute结尾处应答此消息。一般的过滤器（filter）或者是简单的处理功能都是这类的应用。Storm有一个BasicBolt接口封装了上述的流程。示例SplitSentence可以使用BasicBolt来重写：
public class SplitSentence extends BaseBasicBolt { public void execute(Tuple tuple, BasicOutputCollector collector) { String sentence = tuple.getString(0); for(String word: sentence.split(" ")) { collector.emit(new Values(word)); } } public void declareOutputFields(OutputFieldsDeclarer declarer) { declarer.declare(new Fields("word")); } }
使用这种方式，代码比之前稍微简单了一些，但是实现的功能是一样的。发送到BasicOutputCollector的消息会被自动的锚定到输入消息，并且，当execute执行完毕的时候，会自动的应答输入消息。
很多情况下，一个消息需要延迟应答，例如聚合或者是join。只有根据一组输入消息得到一个结果之后，才会应答之前所有的输入消息。并且聚合和join大部分时候对输出消息都是多重锚定。然而，这些特性不是IBasicBolt所能处理的。
Storm 系统中有一组叫做“acker”的特殊的任务，它们负责跟踪DAG（有向无环图）中的每个消息。每当发现一个DAG被完全处理，它就向创建这个根消息的spout任务发送一个信号。拓扑中acker任务的并行度可以通过配置参数Config.TOPOLOGY_ACKERS来设置。默认的acker任务并行度为1，当系统中有大量的消息时，应该适当提高acker任务的并发度。
storm里面有一类特殊的task称为：acker， 他们负责跟踪spout发出的每一个tuple的tuple树。当acker发现一个tuple树已经处理完成了。它会发送一个消息给产生这个tuple 的那个task。你可以通过Config.TOPOLOGY_ACKERS来设置一个topology里面的acker的数量， 默认值是一。 如果你的topology里面的tuple比较多的话， 那么把acker的数量设置多一点，效率会高一点。
为了理解Storm可靠性处理机制，我们从研究一个消息的生命周期和tuple tree的管理入手。当一个消息被创建的时候（无论是在spout还是bolt中），系统都为该消息分配一个64bit的随机值作为id。这些随机的id是acker用来跟踪由spout消息派生出来的tuple tree的。
每个消息都知道它所在的tuple tree对应的根消息的id。每当bolt新生成一个消息，对应tuple tree中的根消息的messageId就拷贝到这个消息中。当这个消息被应答的时候，它就把关于tuple tree变化的信息发送给跟踪这棵树的acker。例如，他会告诉acker：本消息已经处理完毕，但是我派生出了一些新的消息，帮忙跟踪一下吧。
理解storm的可靠性的最好的方法是来看看tuple和tuple树的生命周期， 当一个tuple被创建， 不管是spout还是bolt创建的， 它会被赋予一个64位的id，而acker就是利用这个id去跟踪所有的tuple的。每个tuple知道它的祖宗的id(从spout发出来的那个 tuple的id), 每当你新发射一个tuple， 它的祖宗id都会传给这个新的tuple。所以当一个tuple被ack的时候，它会发一个消息给acker，告诉它这个tuple树发生了怎么样的变化
举个例子，假设消息D和E是由消息C派生出来的，这里演示了消息C被应答时，tuple tree是如何变化的。
因为在C被从树中移除的同时D和E会被加入到tuple tree中，因此tuple tree不会被过早的认为已完全处理。
关于Storm如何跟踪tuple tree，我们再深入的探讨一下。前面说过系统中可以有任意个数的acker，那么，每当一个消息被创建或应答的时候，它怎么知道应该通知哪个acker呢？
系统使用一种哈希算法来根据spout消息的messageId确定由哪个acker跟踪此消息派生出来的tuple tree。因为每个消息都知道与之对应的根消息的messageId，因此它知道应该与哪个acker通信。
当spout发送一个消息的时候，它就通知对应的acker一个新的根消息产生了，这时acker就会创建一个新的tuple tree。当acker发现这棵树被完全处理之后，他就会通知对应的spout任务。
tuple是如何被跟踪的呢？系统中有成千上万的消息，如果为每个spout发送的消息都构建一棵树的话，很快内存就会耗尽。所以，必须采用不同的策略来跟踪每个消息。由于使用了新的跟踪算法，Storm只需要固定的内存（大约20字节）就可以跟踪一棵树。这个算法是storm正确运行的核心，也是storm最大的突破。
一个acker task存储了一个spout-tuple-id到一对值的一个mapping。这个对子的第一个值是创建这个tuple的taskid， 这个是用来在完成处理tuple的时候发送消息用的。 第二个值是一个64位的数字称作：”ack val”, ack val是整个tuple树的状态的一个表示，不管这棵树多大。它只是简单地把这棵树上的所有创建的tupleid/ack的tupleid一起异或(XOR)。
当一个acker task 发现一个 ack val变成0了， 它知道这棵树已经处理完成了。 因为tupleid是随机的64位数字， 所以， ack val碰巧变成0(而不是因为所有创建的tuple都完成了)的几率极小。算一下就知道了， 就算每秒发生10000个ack， 那么需要50000000万年才可能碰到一个错误。而且就算碰到了一个错误， 也只有在这个tuple失败的时候才会造成数据丢失。 关于Acker的详细工作流程的分析可以看看这篇文章: Twitter Storm源代码分析之acker工作流程。
到现在为止，大家已经理解了Storm的可靠性机制，并且知道了如何选择不同的可靠性级别来满足需求。接下来我们研究一下Storm如何保证在各种情况下确保数据不丢失。
Acker任务是轻量级的，所以在拓扑中并不需要太多的acker存在。可以通过Storm UI来观察acker任务的吞吐量，如果看上去吞吐量不够的话，说明需要添加额外的acker。
如果你并不要求每个消息必须被处理（你允许在处理过程中丢失一些信息），那么可以关闭消息的可靠处理机制，从而可以获取较好的性能。关闭消息的可靠处理机制意味着系统中的消息数会减半（每个消息不需要应答了）。另外，关闭消息的可靠处理可以减少消息的大小（不需要每个tuple记录它的根id了），从而节省带宽。
有三种方法可以关系消息的可靠处理机制：
本章介绍了storm集群如何实现数据的可靠处理。借助于创新性的tuple tree跟踪技术，storm高效的通过数据的应答机制来保证数据不丢失。
storm集群中除nimbus外，没有单点存在，任何节点都可以出故障而保证数据不会丢失。nimbus被设计为无状态的，只要可以及时重启，就不会影响正在运行的任务。
标签：
原文地址：http://www.cnblogs.com/200911/p/5003280.html
