分布式事务中的两阶段提交

       在分布式环境中，不同节点上的数据库系统发生错误及错误恢复的操作都是互相独立的。如果一个分布式事务跨越多个节点上的数据库系统(主要是数据库系统，当然还有诸如Queue, JMS等网络共享资源), 在这种环境下保证事务的ACID特性是很有挑战性的。这篇文章我们来谈谈广泛用于分布式事务中的两阶段提交协议，即 2PC(2 phase commit)。这里，先列出几个分布式事务常见的问题，希望大家读完这篇文章，对这些问题的解决会有更进一步认识。

• 由于分布式事务中分布在节点上的资源之间是互相独立的，有可能事务中的某一个节点上的资源操作由于某种原因失败，但其他节点的资源操作则提交成功。
• 一个节点上的资源在事务提交过程中失败，在系统恢复后，试图知道事务是否已经被提交。它找谁去获取这些消息？ 如果当时事务涉及的其他的所有节点的资源都处于不可访问状态怎么办？
• 如果某一个节点上的资源在进行事务提交时没有响应，那事务涉及的其他节点的资源需要做如何处理？

      在此之前，我们需要简单了解一些X/Open (OpenGroup) 定义的关于分布式事务的操作规范，这也是两阶段提交协议应用的一个大场景。

       

      如上图所示，分布式事务管理的角色一般都是有Transaction Manager (简称TM)来承担。其负责与Application Program（简称AP）、Resource Manager (简称RM) 以及其他的TM进行交互。这里RM所管理的Resource在分布式事务中涉及数据库、队列、文件、消息或其他在事务中被访问到的共享对象。TM一般负责处理基本的事务操作:Start、Commit和Abort。AP调用Start来启动事务的执行，调用 Commit来请求TM提交事务，调用Abort来请求TM中断事务操作。TM在分布式事务执行过程中会跟踪所有事务访问的RM。一旦事务准备提交，TM就需要和事务涉及到的所有TM打交道来执行2PC.

      如上图示，当执行2PC时，TM分两个阶段进行操作。第一个阶段， TM发送消息通知所有事务涉及到的RM准备提交事务更新，如果一切正常，RM会回复TM一个消息以表明自己可以进行事务提交，但在这之前， RM一般要将事务在该Resource上进行的更新进行保存。相反，如果发生错误，将回复未就绪状态给TM。当TM收到所有的RM的回复时，进入第二个阶段。如果所有的RM都是就绪状态，TM发送提交的消息给所有事务涉及到的RM，最终完成一个分布式事务的提交；但如果有其中任何一个RM由于本地错误未就绪，那TM将进行事务终止操作。由于所有RM在第一阶段回复TM 准备提交的消息前保存了事务操作的结果。这样，即使某一个节点在提交过程中失败了，那么在该节点正常运行后完全可以进行事务的提交以保证事务的一致性。否则, 事务一致性就很难保证。

     在上面2PC的执行过程中，RM会有一个不确定期。这发生在RM就绪后到收到TM提交或中断消息之前的这个阶段。

       在这个阶段，如果TM发生错误，那么RM会处于阻塞状态，既不能提交也不能终止，而且RM会持有在事务运行阶段在该Resource上获得的数据锁。这个问题，目前还无法彻底避免。但针对这个问题，还是有一些技术在试图解决这个问题。例如启发式技术，说白了就是让系统去对结果进行猜测，系统的判断可能是错的，但至少事务可以被终止，产生的锁可以被释放。另一种技术就是三阶段提交。但也不能完全彻底的解决阻塞这个问题。这里不做过多介绍，否则就跑题儿了。

       在分布式事务中，不同节点间协作过程中，之间发生的异常和错误主要是靠timeout捕获。也就是说调用者在向另一个进程发送消息的同时，会设定一个计时器，并假设如果在计时器过期时还没收到回复，那么一定在被调用方的节点发生了异常或错误。Timeout这个概念对于两阶段提交也会产生影响，具体如下

• TM 在发送 “准备提交” 消息后，如果在设定的Timeout时间内，还没有收到所有参与事务的RM的回复，则会终止事务。结果就像某一个参与事务的RM 回复了 “未就绪” 的消息一样。
• RM 如果完成了事务所涉及的所有工作后，如果在timeout指定的时间内没有收到来自TM的”准备提交”的确认消息，RM会单方面终止事务。如果稍后才收到来自TM的”准备提交” 的确认消息，那RM会回复 “未就绪” 状态。
• RM 回复 “就绪” 后，在为收到TM发送的”提交” 或 “终止” 消息前会进入一个不确定期，由于RM处于阻塞状态，如果这时候Timeout 过期， 像我们前面提到虽有可用的技术缓解不确定期阻塞带来的影响。但并不彻底。