分布式系统中事务提交

    /**
     * @分布式提交
     *      @单阶段提交协议（one-phase commit protocol）
     *                    @协作者方式
     *                        协作者通知所有涉及到的称为参与者的其他进程是否按要求执行操作。
     *                        如果一个操作者不能真正执行操作，那么就说明它存在着明显的缺陷，因为他没有办法来通知协作者。
     *                        在分布式事务的情况下，不可能进行本地提交，因为这会破坏并发控制约束。
     *      @两阶段提交
     *          @设计到的问题：要使一个操作被进程组中的每个成员都执行或一个成员都不执行。
     *              不能有效的处理协作者失败的情况，还有研究三阶段提交协议。
     *
     *          @协议由两个阶段组成，每个阶段又由两部组成
     *              1.协作者向所有的参与者发送一个VOTE_REQUEST 消息
     *              2.当参与者接收到VOTE_REQUEST 消息时，就像协作者返回一个VOTE_COMMIT消息通知协作者它准备好本地事务中属于它的部分
     *                  否则就返回一个VOTE_ABORT消息
     *              3.协作者收集来自参与者的所有选票。如果所有的参与者都表决要提交事务，那么协作者就提交事务。
     *                  这种情况下，协作者向所有参与者发送一个GLOBAL_COMMIT消息。
     *                  但是，如果有一个参与者决定要取消事务，那么协作者就决定取消事务并且多播一个GLOBAL_ABORT消息给所有的参与者
     *              4.每个提交表决的参与者都在等待协调者的最后回应，如果参与者接收到一个GLOBAL_COMMIT的消息，那么就在本地提交事务。
     *                  否则就是接收到一个GLOBAL_ABORT消息，本地取消事务
     *
     *              @要确保进程可以真正恢复，必须持久在存储器中保存有限状态机制。
     *
     *              @经常发生的常见问题是
     *                  @当协作者崩溃，参与者不能做出最后的决定，因此参与者可能在协作者恢复之前保持阻塞。
     *
     *                  协作者和参与者都具有阻塞等待消息的状态。因为当一个进程崩溃，而其他进程又正在无限等待来自该进程的消息时，这个协议就崩溃了。
     *                  @使用定时机制解决这个问题的机制
     *                      @参与者可能在INIT的状态等待来自协作者的VOTE_REQUEST消息，如果在一段时间之后还是没有收到协作者的消息，
     *                          那么参与者就简单的在本地终止事务，并向协作者发送一个VOTE_ABORT消息
     *
     *                      @同样协作者可能在WAIT状态阻塞，等待协作者发送全局表决消息。
     *                          如果在既定时间内没有接收到全局的参与者的决策消息。那么协作者就决定终止表决。
     *                          然后向所有的参与者发送GLOBAL_ABORT消息。
     *
     *                      @参与者可能在READY的状态阻塞，等待协作者发送全局表态
     *                          如果在一段时间内没有接收到消息，参与者不能简单的决定终止事务。
     *                          必须查明协作者发送的是什么消息！
     *                              @让一个参与者P和另一个参与者Q联系，以便根据Q的当前状态来决定做什么（同行的状态进行判断）
     *                                  如果Q的状态到达了COMMIT,那么有可能在协作者崩溃之前只向Q发送了GLOBAL_COMMIT消息。
     *                                      显然这个消息没有发送给P,因此，P应该决定进行提交。
     *                                  如果Q的状态为ABORT那么P也可以安全的进行终止事务。
     *
     *      @三阶段提交
     *          @避免了在出现故障停机时的阻塞过程。
     *          @该协议的本质在于协作者和每个参与者读满足以下两个条件
     *              这两个条件是使提交协议不阻塞的充分必要条件。
     *              1.没有一个可以直接转换到COMMIT或ABORT状态的单独状态。
     *              2.没有一个这样的状态，它不能做出最后决定，而且可以从它直接转换到COMMIT状态
     *
     *          @3PC中协作者首先向所有的参与者发送一个VOTE_REQUEST消息，然后等待参与者应答。
     *              @如果任何一个参与者投票终止事务，那么最后决定就是终止事务。协作者多播一个GLOBAL_ABORT消息。
     *              @如果事务可以提交，就发送一个PREPARE_COMMIT消息。
     *                  只有在每个参与者都确认它已经准备提交，协作者才发送最后的GLOBAL_COMMIT消息，事务才真正提交。
     */