Java分布式：分布式事务
分布式事务
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
二阶段提交协议
事务管理器分两个阶段来协调资源管理器，第一阶段准备资源，也就是预留事务所需的资源，如果每个资源管理器都资源预留成功，则进行第二阶段资源提交，否则协调资源管理器回滚资源。
准备阶段要完成资源操作，如果准备过程出现问题，可以回滚，提交阶段不允许出现问题。
但因为2PC的协议成本比较高，又有全局锁的问题，性能会比较差。 现在大家基本上不会采用这种强一致解决方案。
TCC协议
TCC实际上是服务化的两阶段提交协议，TCC名字的由来是其中包含了 try, confirm, cancel三个操作。
Try：尝试执行业务
完成所有业务检查，预留必须的业务资源。
Confirm：确认执行业务
真正执行业务，不做业务检查
Cancel：取消执行业务
释放Try阶段预留的业务资源
业务开发者需要实现这三个服务接口，第一阶段服务由业务代码编排来调用 Try 接口进行资源预留，所有参与者的 Try 接口都成功了，事务管理器会提交事务，并调用每个参与者的 Confirm 接口真正提交业务操作，否则调用每个参与者的 Cancel 接口回滚事务。
Saga
Saga是30年前的一篇数据库论文里提到的一个概念。在论文中一个Saga事务就是一个长期运行的事务，这个事务是由多个本地事务所组成， 每个本地事务有相应的执行模块和补偿模块，当saga事务中的任意一个本地事务出错了， 可以通过调用相关事务对应的补偿方法恢复，达到事务的最终一致性。
分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。
Saga的两种执行顺序及恢复策略
横线上下分别为两张执行顺序：
向前恢复，适用于必须要成功的场景，执行顺序类似于这样的：T1, T2, ..., Tj(失败), Tj(重试),..., Tn，其中j是发生错误的sub-transaction。该情况下不需要Ci。
向后恢复，即上面提到的第二种执行顺序，其中j是发生错误的sub-transaction，这种做法的效果是撤销掉之前所有成功的sub-transation，使得整个Saga的执行结果撤销。
Saga 正向服务与补偿服务也需要业务开发者实现。
