二阶段提交事务的实现和缺点

背景

说起分布式事务，我们最绕不开的一个话题就是该不该使用分布式事务，而要理解为什么做出使用与否的决定，就必须要提到分布式事务中的最经典的实现：两阶段提交事务,本文我们就简答介绍下这个两阶段提交事务以及它的优缺点

技术实现

所谓的两阶段提交事务顾名思义就是分成两个阶段完成的事务，它包括两种角色： 事务管理者和事务参与者，事务管理者往往是运行应用程序的进程本身，而事务参与者就是各个不同节点的数据库管理系统，我们以Mysql数据库和Oracle数据库作为事务参与者为例来看一下两阶段提交事务的流程图

阶段一：

1.1事务管理器首先向各个参与者发送prepare命令来让参与者(此处的Mysql数据库和Oracle数据库)准备好数据库资源，包括锁定必要的数据记录，这个阶段参与者一旦做出是或者否的决定都是不可撤销的，也就是说如果回答了是，那么表明所有的准备工作包括锁定所有必要的数据记录等已经完成
1.2 事务管理器收到各个参与者对prepare准备命令的回复后，确定整个事务是要提交还是终止(只要有一个参与者回复不OK，整个事务就要终止)，并把这个决定(提价或者终止)写入持久性存储设备(一般是本地磁盘)，写入磁盘的目的是防止此时事务管理器崩溃，事务处于一种中间状态

阶段二：

2.1 事务管理器决定事务是提交还是终止后，把这个消息发送给所有的参与者，事务参与者收到消息后进行事务提交或者回滚。

总结

前面讲述的就是两阶段提交事务的执行流程，那么这个流程中有哪些缺点呢：
1.事务管理者(大部分情况下就是应用进程自身)是一个单点，一旦发生故障，那就是只能等待它自身的重启恢复
2.由于事务管理器(大部分情况下就是应用进程自身)会把事务提交或者终止的决定保存到本地磁盘中，所以应用进程自身不再是一个无状态的服务器，也就是重启时不能随意重启一个运行相同代码的服务器取代，因为他需要读取磁盘上的事务日志文件来决定事务的状态
3.两阶段事务中对于事务参与者来说，第一阶段已经对数据记录加锁并等待第二阶段的事务提交或者终止命令，这一过程中有可能要经过很长时间的等待，导致数据库参与者长时间的锁定数据记录，对整个数据库的性能造成极大的性能损失
4.当数据库参与者第一阶段已经对数据记录加锁并等待第二阶段的事务提交或者终止命令的过程中，事务管理器崩溃并且真的没法恢复时(比如事务管理器的本地磁盘损坏时，这是极有可能的，因为事务管理器大部分情况下就是应用进程自身)，那么数据库就会长期处于不一致状态(比如第一阶段锁定的记录完全无法释放-需要人工介入)，这不仅仅影响数据库的性能而且对于数据库的一致性状态都造成了破坏。

以上的缺点就是我们不使用分布式事务二阶段提交的原因，当然公司的DBA更是强烈的不推荐应用使用二阶段提交事务的原因，毕竟谁会愿意半夜三更起来杀死处于不一致状态的事务呢?谁愿意数据库的性能因为几个分布式事务就下降到极低的水平呢