Transactionalspouts
Trident是以小批量（batch）的形式在处理tuple。而且每一批都会分配一个唯一的transaction id。不同spout的特性不同，一个transactionalspout会有例如以下这些特性：
1、有着相同txid的batch一定是一样的。
当重播一个txid相应的batch时，一定会重播和之前相应txid的batch中相同的tuples。
2、各个batch之间是没有交集的。每一个tuple仅仅能属于一个batch
3、每个tuple都属于一个batch，无一例外
这是一类很easy理解的spout。 tuple 流被划分为固定的batch而且永不改变。（trident-kafka 有一个 transactional spout 的实现。
）
你或许会问：为什么我们不总是使用transactional spout？这非常easy理解。
一个原因是并非全部的地方都须要容错的。举例来说。TransactionalTridentKafkaSpout 工作的方式是一个batch包括的tuple来自某个kafka topic中的全部partition。一旦这个batch被发出，在不论什么时候假设这个batch被又一次发出时，它必须包括原来全部的tuple以满足 transactional spout的语义。如今我们假定一个batch被TransactionalTridentKafkaSpout所发出，这个batch没有被成功处理，而且同一时候kafka的一个节点也down掉了。你就无法像之前一样重播一个全然一样的batch（由于kakfa的节点down掉，该topic的一部分partition可能会无法使用）。整个处理会被中断。
这也就是"opaque transactional" spouts（不透明事务spout）存在的原因 - 他们对于丢失源节点这样的情况是容错的，仍然可以帮你达到有且仅仅有一次处理的语义。后面会对这样的spout有所介绍。
在讨论"opaque transactional" spout之前，我们先来看看如何为transactional spout设计一个具有exactly-once语义的State实现。这个State的类型是"transactionalstate" 而且它利用了不论什么一个txid总是相应相同的tuple序列这个语义。
假如说你有一个用来计算单词出现次数的topology，你想要将单词的出现次数以key/value对的形式存储到数据库中。key就是单词。value就是这个这个单词出现的次数。你已经看到仅仅是存储一个数量是不足以知道你是否已经处理过一个batch的。你能够通过将value和txid一起存储到数据库中。
这种话，当更新这个count之前，你能够先去比較数据库中存储的txid和如今要存储的txid。假设一样。就跳过什么都不做。由于这个value之前已经被处理过了。假设不一样，就运行存储。这个逻辑能够工作的前提就是txid永不改变，而且Trident保证状态的更新是在batch之间严格顺序进行的。
考虑以下这个样例的执行逻辑。假定你在处理一个txid为3的包括以下tuple的batch：
["man"]
["man"]
["dog"]
假定数据库中当前保存了以下这种key/value 对：
man => [count=3, txid=1]
dog => [count=4, txid=3]
apple => [count=10, txid=2]
单词“man”相应的txid是1. 由于当前的txid是3，你能够确定你还没有为这个batch中的tuple更新过这个单词的数量。所以你能够放心的给count加2并更新txid为3. 与此同一时候，单词“dog”的txid和当前的txid是同样的，因此你能够跳过这次更新。此时数据库中的数据例如以下：
man => [count=5, txid=3]
dog => [count=4, txid=3]
apple => [count=10, txid=2]
很多其它精彩内容请关注：http://bbs.superwu.cn
关注超人学院微信二维码：
关注超人学院java免费学习交流群：