1.分布式事务
事务的参与者，支持事务的服务器，资源服务器分别位于不同的分布式系统的不同节点之上，且属于不同的应用。分布式事务需要保证这些操作要么全部成功，要么全部失败。本质上说，分布式事务就是保证不同数据库的一致性。
最早的分布式事务应用架构很简单，不涉及服务间的访问调用，仅仅是服务内操作涉及到多个对数据库资源的访问。
当一个服务需要调用另外一个服务时，这时的事务就需要跨越多个服务了，在这种情况下，起始于某个服务的事务在调用另外一个服务时，需要以某种机制流转到另外一个服务，从而使被调用的服务的访问的资源也自动加入到该事务中来。
若将以上两种场景结合起来，对此延伸，整个分布式事务的参与者会组成一个树形拓扑结构，服务A有自己的调用资源，也调用了服务B和服务C，服务C调用了自己的资源，服务B调用了服务D和服务E......
2.分布式事务相关理论
CAP定理
分布式系统有三个指标：
-
Consistenct:一致性
-
Availability:可用性
-
Partition tolerance：分区容错
这三个指标不可能同时做到，这个结论叫做CAP定理。
Partition tolerance：分区容错 ：
大多数分布式系统都分布在多个子网络，每个子网络叫做一个区。分区容错的意思就是，区间通信可能失败，可以理解为网络故障造成的问题。
上图中，G1和G2是两台跨区的服务器，G1向G2发送一条数据，G2可能无法收到，系统设计时必须考虑到这种情况。
一般来说，分区容错无法避免，因此可以认为CAP的P总是成立的，CAP定理告诉我们，剩下的C和A无法同时做到。
Availability:可用性 ：
可用性意思是，只要收到用户的请求，服务器就必须做出回应。
用户可以向G1和G2发起读操作，不管是哪台服务器，只要收到请求，就必须告诉用户到底是v0还是V1，否则就不满足可用性了。
Consistenct:一致性
意思是写之后的读操作，必须返回该值。
如某条记录是V0，用户向G1发起一个写操作，将其改为V1，而用户有可能向G2发起读操作，G2的值没有变化，因此返回的的是V0，G1和G2读操作的结果不一样，这就不满足一致性了。
为了能让G2也能变为V1，就要在G1写操作时，让G1向G2发送一条消息，要求G2也改为V1。
一致性和可用性的矛盾 ：
一般来说，分区容错无法避免，因此可以认为CAP的P总是成立的。
一致性和可用性为什么不可能同时成立？因为可能通信失败（即出现分区容错）。
如果保证G2的一致性，那么G1必须在写操作时，锁定住G2的读操作和写操作，只有数据同步后，才能重新开放读写。锁定期间，G2没有可用性。
如果保证G2的的可用性，那么势必不能锁住G2，所以一致性不能成立。
综上，G2无法同时做到一致性可可用性，系统设计时只能选择一个目标，如果追求一致性，那么无法保证所有节点的可用性，如果追求所有节点的可用性，那么无法保证所有节点的一致性。
