分布式事务简述

随着系统越来越大，不断的模块化和SOA化，你的系统可能被分散于不同的机器上，这时候，你原先的单机本地事务可能已经无法满足你的需求，你可能要跨系统跨资源的去使用事务。这就是分布式事务。
  事务有四个特性：

1.    原子性
2.    一致性
3.    隔离性
4.    持久性

  具体就不多介绍了，相信大家都能明白ACID特性的基本含义。

事务模型

而一个具体的事务需要涉及到的模型（无论哪种模型）一般由下面几部分组成：

1. AP 应用程序
2. RM 资源管理器
3. TM 事务管理器

这里的资源管理器一般指数据库资源，而事务管理器，大多是由数据库厂商提供。
那么其实在分布式事务中，也应该符合以上事务的特性和模型，只是资源管理器(RM)变得多了起来.

分布式事务介绍

分布式事务最大的问题在于如何确定资源的状态，以及保证一致性，原子性 。
一般来说分布事务由

1. 原子提交协议 
2. 协调器
3. 参与者
4. 事务恢复器
5. 死锁检测器

五部分组成。

原子提交协议 指的是如何保证原子提交，一般分为单阶段原子提交协议 ，两阶段原子提交协议 ，三阶段原子提交协议 。

对于单阶段原子提交协议 来说，根本没有办法保证分布式事务的原子性，所以不适用于分布式事务中。

两阶段原子提交协议则 是 各种分布式事务实现中使用最广泛的一种原子提交协议：它主要是交事务提交的过程分为二阶段，投票和最终提交。事务由协调者发起一个事务，参与者加入到事务 中后，第一阶段时候，所有的参与者准备资源，并将资源hold住，协调者询问所有的参与者是否可以提交？所有的参与者向协调者响应结果YES/NO,当所 有的协调者都响应YES的时候，协调者才会发起第二阶段，向所有的参与者通知提交事务，当所有的参与者都提交确认会会再通知协调者。至此事务处理完毕。

三阶段提交协议 由于协调者与参与者多次进行沟通所以代价很大，一般不会使用。但是它能缩小事务处理“不确定”状态的延迟时间。

所谓“不确定”状态就是指当参与者向协调者反馈可以提交的时候，长时间没有收到协调者的通知，这时候参与者没有办法确定事务最终需要如何处理，所以状态为不确定状态。

协调者，参与者一般通过如下动作来进行通信：

1. join:由协调者提供，用来注册新的参与者
2. canCommit：协调者询问参与者是否能够提交
3. doCommit ：协调者通知参与者提交事务
4. doAbort：协调者通知参与者放弃事务
5. haveCommit：参与者向协调者确认已经提交事务
6. getDecision：当处于“不确定”状态时，参与者用来询问协调者事务的目前状态。

对于haveCommit特别说明一下，是当第一阶段的时候，协调者发现长时间参与者没有向协调者反馈事务状态，则协调者会主动调用该接口事务的情况，如果仍然无响应，则会通知所有的参与者放弃该事务。

任何事情都会有意外产生，特别是对于跨系统间的通信更容易产生问题，比如网络异常，机器down机，这个时候就需要事务恢复器来作相应的处理。

对于处于第一阶段的事务， 如果参与者发生意外，则协调者会通知所有的参与者进行事务放弃，但是如果协调者出生故障时，就必须要能 够就行事务恢复，所以协调者必须在开始事务的时候，产生唯一的事务ID,并且对事务进行持久化，在协调者恢复的时候，参够让人参与者继续进行事务。

而对于第二阶段出现的故障， 由于第一阶段进行了资源的个决，则事务认为是必然能成功的，这个事候，如果这个时候参与者发生故障，则协调者需要一套重试机制，让参与者在恢复过来后，能够将事务进行完成或者人工介入。

关于死锁检测器这里就不多描述了，以后有机会再描述。