MySQL(InnoDB剖析):44---事务之（XA事务（分布式事务））

一、MySQL数据库分布式事务

• InnoDB存储引擎提供了对XA事务的支持，并通过XA事务来支持分布式事务的实现
• 分布式事务指的是：允许多个独立的事务资源参与到一个全局的事务中。事务资源通常是关系型数据库系统，但也可以是其他类型的资源
• 全局事务要求在其中的所有参与的事务要么都提交，要么都回滚，这对于事务原有的ACID要求又有了提高。另外，在使用分布式事务时，InnoDB的事务隔离级别必须设置为SERIALIZABLE
• XA事务允许不同数据库之间的分布式事务，如一台服务器是MySQL数据库的，另一台是Oracle数据库的，又可能还有一台服务器是SQL Server的，只要参与在全局事务中的每个节点都支持XA事务
• 分布式事务可能在银行系统的转账中比较常见，如用户David需要从上海转10000到北京的用户Mariah的银行卡中：

• 在这种情况下，一定需要使用分布式事务来保证数据的安全。如果发生的操作不能全局提交或回滚，那么任何一个结点出现问题都会导致严重的结果。要么是David的账户被扣款，但是Mariah没收到，又或者是David的账户没有扣款，Mariah却收到钱了

innodb_support_xa参数

• 该参数用来控制是否支持XA事务
• 默认值为ON，表示支持XA事务

二、XA事务的组成

• XA事务由下面3部分组成：
  • 资源管理器（Resource Managers）：提供访问事务资源的方法。通常一个数据库就是一个资源管理器
  • 事务管理器（Transaction Manager）：协调参与全局事务中的各个事务。需要和参与全局事务的所有资源管理器进行通信
  • 应用程序（Application Program）：定义事务的边界，指定全局事务中的操作
• 在MySQL数据库的分布式事务中，资源管理器就是MySQL数据库，事务管理器为连接MySQL服务器的客户端
• 下图显示了一个分布式事务的模型：

• 分布式事务使用两段式提交的方式：
  • 第一阶段，所有参数全局事务的节点都开始准备（PREPARE），告诉事务管理器它们准备好提交了
  • 第二阶段，事务管理器告诉资源管理器质性ROLLBACK还是COMMIT。如果任何一个节点显示不能提交，则所有的节点都被告知需要回滚
• 可见与本地事务不同的是，分布式事务需要多一次的PREPARE操作，待收到所有节点的同一信息后，再进行COMMIT或是ROLLBACK操作

三、XA事务的语法

单节点运行实例

• 在单个节点上运行分布式事务没有太大的实际意义，但是要在MySQL数据库的命令下演示多个节点参与的分布式事务也是行不通的

五、内部XA事务

• 之前讨论的分布式事务是外部事务，即资源管理器是MySQL数据库本身。在MySQL数据库中还存在另外一种分布式事务，其在存储引擎与插件之间，又或者在存储引擎与存储引擎之间，称之为内部XA事务

内部XA事务保证主从

• 最为常见的内部XA事务存在于binlog与InnoDB存储引擎之间
• 由于复制的需要，因此目前绝大多数的数据库都开启了binlog的功能。在事务提交时，先写二进制日志，再写InnoDB存储引擎的重做日志。对上述两个操作的要求也是原子的，即二进制日志和重做日志必须同时写入。若二进制日志先写了，而在写入InnoDB存储引擎时发生了宕机，那么slave可能会接收到master传过去的二进制日志并执行，最终导致了主从不一致的情况。如下图所示：
  • 在图中，如果执行完①、②后在步骤③之前MySQL数据库发生了宕机，则会发生主从不一致的情况

• 为了解决这个问题，MySQL数据库在binlog与InnoDB存储引擎之间采用XA事务。当事务提交时，InnoDB会先做一个PREPARE操作，将操作的xid写入，接着进行二进制日志的写入，如下图所示：
  • 如果在InnoDB存储引擎提交前，MySQL数据库发生宕机了，那么MySQL数据库在重启后会先检查准备的UXID事务是否已经提交，若没有，则在存储引擎层再进行一次提交操作