随着系统越来越大，不断的模块化和SOA化，你的系统可能被分散于不同的机器上，这时候，你原先的单机本地事务可能已经无法满足你的需求，你可能要跨系统跨资源的去使用事务。这就是分布式事务。
事务有四个特性：- 原子性
- 一致性
- 隔离性
- 持久性
具体就不多介绍了，相信大家都能明白ACID特性的基本含义。
事务模型
而一个具体的事务需要涉及到的模型（无论哪种模型）一般由下面几部分组成：
- AP 应用程序
- RM 资源管理器
- TM 事务管理器
这里的资源管理器一般指数据库资源，而事务管理器，大多是由数据库厂商提供。
那么其实在分布式事务中，也应该符合以上事务的特性和模型，只是资源管理器(RM)变得多了起来.
分布式事务介绍
分布式事务最大的问题在于
如何确定资源的状态，以及保证一致性，原子性。
一般来说分布事务由
- 原子提交协议
- 协调器
- 参与者
- 事务恢复器
- 死锁检测器
五部分组成。
原子提交协议指的是如何保证原子提交，一般分为
单阶段原子提交协议，
两阶段原子提交协议，
三阶段原子提交协议。
对于单阶段原子提交协议来说，根本没有办法保证分布式事务的原子性，所以不适用于分布式事务中。
两阶段原子提交协议则是 各种分布式事务实现中使用最广泛的一种原子提交协议：它主要是交事务提交的过程分为二阶段，投票和最终提交。事务由协调者发起一个事务，参与者加入到事务 中后，第一阶段时候，所有的参与者准备资源，并将资源hold住，协调者询问所有的参与者是否可以提交？所有的参与者向协调者响应结果YES/NO,当所 有的协调者都响应YES的时候，协调者才会发起第二阶段，向所有的参与者通知提交事务，当所有的参与者都提交确认会会再通知协调者。至此事务处理完毕。
三阶段提交协议由于协调者与参与者多次进行沟通所以代价很大，一般不会使用。但是它能缩小事务处理“不确定”状态的延迟时间。
所谓“不确定”状态就是指当参与者向协调者反馈可以提交的时候，长时间没有收到协调者的通知，这时候参与者没有办法确定事务最终需要如何处理，所以状态为不确定状态。
协调者，参与者一般通过如下动作来进行通信：- join:由协调者提供，用来注册新的参与者
- canCommit：协调者询问参与者是否能够提交
- doCommit ：协调者通知参与者提交事务
- doAbort：协调者通知参与者放弃事务
- haveCommit：参与者向协调者确认已经提交事务
- getDecision：当处于“不确定”状态时，参与者用来询问协调者事务的目前状态。
对于haveCommit特别说明一下，是当第一阶段的时候，协调者发现长时间参与者没有向协调者反馈事务状态，则协调者会主动调用该接口事务的情况，如果仍然无响应，则会通知所有的参与者放弃该事务。
任何事情都会有意外产生，特别是对于跨系统间的通信更容易产生问题，比如网络异常，机器down机，这个时候就需要事务恢复器来作相应的处理。
对于处于第一阶段的事务，如果参与者发生意外，则协调者会通知所有的参与者进行事务放弃，但是如果协调者出生故障时，就必须要能 够就行事务恢复，所以协调者必须在开始事务的时候，产生唯一的事务ID,并且对事务进行持久化，在协调者恢复的时候，参够让人参与者继续进行事务。
而对于第二阶段出现的故障，由于第一阶段进行了资源的个决，则事务认为是必然能成功的，这个事候，如果这个时候参与者发生故障，则协调者需要一套重试机制，让参与者在恢复过来后，能够将事务进行完成或者人工介入。
关于死锁检测器这里就不多描述了，以后有机会再描述。