Storm的Trident特性

      我们知道把Bolt的运行状态仅仅保存在内存中是不可靠的，如果一个node挂掉，那么这个node上的任务就会被重新分配，但是之前的状态是无法恢复的。因此，比较聪明的方式就是把Storm的计算状态信息持久化到database中，基于这一点，trident就变得尤为重要。因为在处理大数据时，我们在与database打交道时通常会采用批处理的方式来避免给它带来压力，而trident恰恰是以batch groups的形式处理数据，并提供了一些聚合功能的API。

        Trident是对Storm的一个更高层次的抽象，Trident最大的特点以batch的形式处理stream，这样一来，可以使得一些处理更简单和高效。

Trident定义了如下语义规则：

1)所有的Tuple都是以batch的形式处理的

2)每个batch都会被分配一个唯一的“transactionid”(txid)，如果batch被重发，txid不变

3)各个batch状态的更新是有序的，也就是说batch2一定会在batch3之前更新

有了这三个规则，我们就可以通过txid知道batch是否被处理过，然后就可以根据实际情况来更新状态信息了。很明显，要满足这几个语义规则，就需要spout来支持，因为把tuple封装成batch，分配txid等等都是有spout来负责的。

但是在具体应用场景中，Storm应该能够提供不同的容错级别，因为某些情况下我们并不需要强一致性。为了更灵活的处理，Trident提供了三类spout，分别是：

1)Transactional spouts : 事务spout，提供了强一致性

2)Opaque Transactional spouts：不透明事务spout，提供了弱一致性

3)No-Transactional spouts：非事务spout，对一致性无法保证

注意，所有的Trident Spout都是以batch的形式发送数据，每个batch也都会分配一个唯一的txid，决定它们有不同性质的地方在于它们对各自的batch提供了什么样的保证。

总的来说， Opaque transactional states即有一定的容错性又能保证数据一致性，但它的代价是需要在数据库中保存更多的状态信息（txid和preValue）。Transactionalstates虽然需要较少的状态信息(txid)，但是它需要transactionalspouts的支持。non-transactional states需要在数据库中保存最少的状态信息但难以保证“数据只被处理一次”的语义。

因此，在实际应用中，spout和state类型的选择需要根据我们具体应用需求来决定，当然在容错性和增加存储代价之间也需要做个权衡。