分布式事务简述

  随着系统越来越大，不断的模块化和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,并且对事务进行持久化，在协调者恢复的时候，参够让人参与者继续进行事务。

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

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

语言组织能力比较差，太久没有写东西，凑合着写给自已看吧。