规范介绍及Mysql底层实现机制数据库分布式事务XA

3. XA优化与异常处理

优化1：持久化事务协调阶段的各个状态

　　TM作为一个单点的事务协同器，很有可能宕机，出现单点故障。其本身的职责主要是事务协调，属于无状态的服务。宕机重启后，可以根据持久化的全局事务状态来恢复TM的执行逻辑，所以，需要将阶段的各个协调阶段以及该阶段中每个RM的执行状态持久化到独立的DB中，多个TM共享一个持久化DB。具体的阶段有，prepare阶段的子阶段有branch_tansaction_ send、prepare_send、prepare_ack阶段，commit阶段的子阶段有commit_send、commit_ack阶段，记录每个子阶段每个RM的执行状态

 

优化2：并行发送语句

　　在branch_tansaction_ send、prepare_ send、commit_send阶段，如果TM往RM发送语句是串行执行的，单个global transaction的执行时间加长，TM的TPS（每秒事务请求数）会降低，可以在这些阶段将已生成的语句，通过线程池并行发送到各个RM，TM同时同步等待语句的返回值，延时大为降低。

 

异常1：TM在prepare_send阶段前宕机，重启恢复后，继续执行prepare_send动作。

异常2：TM在prepare_send阶段时宕机，可能会有部分RM收到prepare语句，部份没有收到，重启后，往收到prepare语句的RM发送rollback语句。

异常3：TM在prepare_ack阶段记录完各个RM的执行状态后宕机，重启后，根据日志状态发起rollback或者commit语句。

异常4：TM在commit_send阶段时宕机，可能会有部分RM收到commit语句，部份没有收到，重启后，往没有收到commit语句的RM发送commit语句。

异常5：TM在commit_ ack阶段记录完各个RM的执行状态后宕机，重启后，根据日志状态发起重试commit语句或者不操作。

异常6：RM超长时间没有收到TM的rollback或者commit语句，一直持有记录锁，RM要有自动rollback或者commit的功能。

 

4. 2PC与1PC对比

　　XA的两阶段提交，直观感觉和RM的交互次数太多，RPC次数太多，影响单个全局事务的响应时间，TPS肯定降低。但是，prepare阶段有存在的意义，如果某个单机事务处于prepare状态，一直没有commit，mysql重启时，进行崩溃恢复时，如果binlog中没有该事务，对该事务进行rollback，如果有，则对该事务进行commit。

　　XA两阶段提交满足了事务的ACID属性，原子性：在prepare和commit阶段保障了事务的原子性。隔离性：通过mysql原生的记录锁，做到读写隔离。持久性：基于mysql单机事务的redo实现了持久性。一致性：基于mysql单机事务。

　　如果放弃prepare阶段，只有commit阶段，全局事务的原子性无法保障，例如这个场景，全局事务的部分分支事务commit成功，另一部分分支事务commit失败，此时全局事务就处于既不能commit成功，也不能rollback成功，因为已经成功commit的分支事务无法rollback。

　　即使通过解析binlog，生成反向SQL进行补偿达到rollback的效果，此时也会多产生一次交互，RPC次数和两阶段提交是一样的了。但是此时又引发一个新问题，全局事务的隔离性难以保障，因为另一个全局事务2可能会修改此时全局事务1的已经commit了的记录，而全局事务1正在反向补偿同一条已经commit了的记录。

　　即使通过以下方法达到了隔离性，只满足Read Commited隔离级别，Repeated Read等隔离级别没有实现，而且隔离的粒度比较大，记录上的Xid，相当于一把记录写锁。

　　在每个记录上，增加一个字段全局事务ID（Xid），只有满足以下两个条件之一方可访问该记录。

　　1）记录上Xid是本全局事务的Xid，

　　2）记录上Xid不是本全局事务ID，且该Xid已经不活跃

 　　总结，TM和各个RM都处于完全正常的情况下，1PC的性能比起2PC会好，尤其是TPS。但是在RM处于异常的场景下，例如全局事务的部分分支事务commit成功，另一部分分支事务commit失败。1PC的TPS可能跟2PC差不多。

  

5.  XA各个阶段的Mysql处理流程