在Storm内部，有一组“acker”任务持续追踪来自每条元组消息的DAG。这些任务的数量可通过storm.yaml中的TOPOLOGY—ACKERS参数设定。在处理大量消息时，可能将不得不增大这个数字。每个消息元组得到一个64—bit ID，用于ackers追踪。元组的DAG状态由一个叫作ack val的64—bit值维护，只是简单地把树中每个确认过的ID执行异或运算。当ack val成为0时，acker任务就认为这棵元组树被完全处理了。
在某些情况下，当性能至关重要，而可靠性又不是问题时，可靠性也可以被关闭。在这些情况下，程序员可以指定TOPOLOGY—ACKERS为0，并在分发新元组时，不指定输入元组的非锚定消息（unanchor messages）。这样就跳过了确认消息，节省了带宽，提高了吞吐量。到目前为止，我们已经讨论且只讨论了至少处理一次数据流的语义。
仅处理一次数据流的语义可以采用事务性拓扑实现。Stonn通过为每条元组提供相关联的事务ID为数据流处理提供事务性语义（仅一次，不完全等同于关系数据库的ACID语义）。对于重新发送数据流来说，相同的事务ID也会被发送并担保这个元组不会被重复处理。这方面牵涉对于消息处理的严格顺序，就像是在处理一个元组。由于这样做效率很低，Storm允许批量处理由一个事务ID关联的元组。不像早先的情况，程序不得不将消息锚定到输入元组，事务性拓扑对程序员是透明的。Storm内部将元组的处理分为两阶段——第一阶段为处理阶段，可以并行处理多个批次，99—阶段为提交阶段，强制严格按照批次ID提交。
事务性拓扑已经过时了——它已被整合进一个叫作Trident的更大的框架。Trident允许对流数据进行查询，包括聚合、连接、分组函数，还有过滤器。Trident构建于事务性拓扑之上并提供一致的一次性语义。
基于Storm的设计模式
我们将要学习如何实现基于Storm的一些通用设计模式。设计模式，我们也称之为软件工程意识，是在给定上下文环境中，针对设计问题的可重用的通常解决方案（Gamma等，l995）。它们是分布式远程过程调用（DRPC）、持续计算以及机器学习。
……
展开
