一、Trident State概述
我们知道Trident的计算都是以batch为单位的，但是batch中的tuple在处理过程中有可能会失败，所 以基于一致性语义的规则，对于失败之后bach又有可能会被重播的情况，我们如何提交，保存，更新 Trident的计算结果。那么Trident State给出了方案。
Batch处理分成两个阶段：
- 1、processing阶段： 这个阶段很多batch可以并行计算。
- 2、commit阶段：这个阶段各个batch之间需要有强顺序性的保证。所以第二个batch必须要在第一个batch成功提交之后才能提交。
二、Transactional Spouts详解
storm应该能够提供不同的容错级别，因为某些情况下我们并不需要强一致性。为了更灵活的处 理，Trident提供了三类spout，分别是：
Transactional spouts : 事务spout，提供了强一致性
Opaque Transactional spouts： 不透明事务spout，提供了弱一致性
No-Transactional spouts： 非事务spout，对一致性无法保证
所有的Trident Spout都是以batch的形式发送数据，每个batch也都会分配一个唯一的txid，决定它 们有不同性质的地方在于它们对各自的batch提供了什么样的保证
Transactional spouts，也叫事务spout，提供了强一致性，有如下三点保障：
1.一个txid对应一个batch，如果一个batch被重发，txid不变
2.任意两个batch中不会有tuple相同
3.每个tuple都会被放到一个batch中，不会有tuple被漏掉
三、Opaque Transactional Spout详解
并不是所有情形下都需要保证强一致性。例如在TransactionalTridentKafkaSpout中 ，如果它的一个batch中的tuples来自一个topic的所有partitions，如果要满足Transactionnal Spout语义的话，一旦这个 batch因为某些失败而被重发，重发batch中的所有tuple必须与这个batch中的完全一致，而恰好kafka集群某个节点down掉 导致这个topic其中一个partition无法使用，那么就会导致这个batch无法凑齐所有tuple（无法获取失败partition上的数据） ，整个处理过程被挂起。 而Opaque Transactional spouts就可以解决这个问题。
Opaque Transactional spouts提供了如下保证：
每个tuple只在一个batch中被成功处理，如果一个batch中的tuple处理失败的话，会被后面的batch继续处理。
其实OpaqueTransactional spout和Transactional spouts基本差不多，只是在Opaque Transactional spout中，相同txid的 batch中的tuple集合可能不一样。OpaqueTridentKafkaSpout就是符合这种特性的spout的，所以它可以容忍kafka节点失败。 因为重播的Batch中的tuple集合可能不一样，所以对于Opaque Transactional Spout，就不能根据txid是否一致来决定是否需要更新 状态了。我们需要在数据库中保存更多的状态信息，除了单词名，数量、txid之外，我们还需要保存一个pre-value来记录前一次计算 的值。
四、Trident中Spout与State的关系
总的来说， Opaque transactional states即有一定的容错性又能保证数据一致性，但它的代 价是需要在数据库中保存更多的状态信息（txid和preValue）。Transactional states虽然需要较 少的状态信息(txid)，但是它需要transactional spouts的支持。non-transactional states需要在数据库中保存最少的状态信息但难以保证“数据只被处理一次”的语义。
因此，在实际应用中，spout和state类型的选择需要根据我们具体应用需求来决定，当然在容 错性和增加存储代价之间也需要做个权衡。
五、事务性Spout的实现机制
事务性的spout需要实现ITransactionalSpout，这个接口包含两个内部类Coordinator 和Emitter。在topology运行的时候，事务性的spout内部包含一个子的topology,其中 coordinator是spout，emitter是bolt。coordinator为事务性batch发射tuple，Emitter负 责为每个batch实际发射tuple。
六、DRPC详解
什么是DRPC？
分布式RPC（distributed RPC，DRPC）用于对Storm上大量的函数调用进行并行计算。 对于每一次函数调用，Storm集群上运行的拓扑接收调用函数的参数信息作为输入流，并将计算结果作为输出流 发射出去。
一句话概括：Storm进行计算，根据客户端提交的请求参数，而返回Storm计算的结果。
DRPC通过DRPC Server来实现，DRPC Server的整体工作过程如下：
接收到一个RPC调用请求；
发送请求到Storm上的拓扑；
从Storm上接收计算结果；
将计算结果返回给客户端。
注：在client客户端看来，一个DRPC调用看起来和一般的RPC调用没什么区别
工作流程：
- 1、服务端进行实时计算，声明调用的函数名称和参数；
- 2、Client向DRPC
Server发送被调用执行的DRPC函数名称及参数，获取结果；
DRPC服务配置及访问方式：
