是在是抱歉，本来每周一都是 POSTGRESQL 的，但由于某些原因这周更换顺序，下周会恢复的。
最近有点不大爽，主要是有的人认为MYSQL分布式中间件并没有那么复杂，就是一个通过设置分区键进行数据下发的软件而已，实际上呵呵
首先要说明的是，什么是XA 协议，XA是一种两阶段提交协议，很多数据库和事务监视器都支持，它通过协调访问多个关系数据库的单个事务来确保数据完整性。XA保证在所有参与的数据库中提交事务更新，或者从所有数据库中完全回滚，恢复到事务开始之前的状态。
为了参与XA事务，XA资源必须让事务管理器知道其自身。一旦登记了XA资源，事务管理器将确保XA资源参与事务，并在事务的生存期内对XA资源进行适当的方法调用。要完成XA事务，所有资源管理器都参与一个两阶段提交(2pc)。XA事务中的提交称为两阶段提交，因为在提交过程中有两次传递。
在第一轮中，事务管理器询问每个资源管理器是否在提交事务时遇到任何问题。如果任何资源管理器反对提交事务，则任何一方对XA事务中涉及的任何资源所做的所有工作都必须全部回滚。
事务管理器对每个已征募的XA资源调用rollback()方法。如果没有资源管理器反对提交，那么第二轮将涉及事务管理器对每个已征募的XA资源实际调用commit()。这个过程保证了可以跨多个资源的事务的ACID(原子性、一致性、隔离性和持久性)属性。
到这里不拉不拉，你说了老半天，到底这些有什么关系，DBLE 分布式中间数据库的中间件，就是利用MYSQL 通用的 XA 协议来做的，如果不知道DBLE，那请百度一下。
所以XA 协议对于分库分库分表是很重要的一个协议。
下面是XA 协议的一些步骤
1 XA START
2 Some SQL statement
3 XA END
4 XA Prepare
5 XA Commit or Rollback
下面我们看一下
举例，如果三个物理数据中的一个数据库，在中间件下发数据的时候，其中一个进行了重启，回怎么样，如果是在 MYSQL 5.6 版本的时候，那很可能就丢数据的情况，上面的话如果不理解的话我们还是捋一捋
- 中间件已经向分库1和分库2，分库3，上发送完了 xa prepare ‘xid1’语句，并得到了成功的回复
- 中间件向分库1，3上发送了 ‘xa commit ‘xid1’语句，并已经成功返回
- 当 中间件向分库2上发送 ‘xa commit ‘xid1’时，网络断开了，或者分库2的数据库实例被kill了
- 当网络恢复（这时相关的Session已经退出了）或数据库实例再启动后（或切换到备库），XA prepare了的事务已经回滚了， 当中间件 XA commit ‘xid1’发过来后数据库实例根本找不到xid1这个xa事务
上面的流程就导致了分布式事务的不一致：分库1，3提交了事务，分库2回滚了事务，整个事务提交了一半，回滚了一半。
所以使用MYSQL5.6的同学你要注意了，MYSQL5.6中是没有 xa prepare 的严格的持久化的，当Session断开，数据库CRASH等情况下这些事务会被回滚掉，并且一个主库配了SemiSync的情况下xa prepare了的事务也不会被发送的SLAVE库，当主库切换到备库这些事务也就丢失。
所以安全的使用中间件的情况一定是你使用了MYSQL.5.7 的情况下，分布式的MYSQL 才能有安全的保证。
我们来做一个实验
然后，机器突然就崩溃了。如果是一般的事务，那一定就消失了。下图是机器已经重启了，同时数据也没有插入。
然后我们在commit
数据就回来了。通过这样的方式分布式中间件是可以保证某个物理库出现问题后，在变得正常后的数据是可以进行恢复的。
XA RECOVER;
xa recover; 是可以看到在prepare 状态的事务，参见上图
同时在BINLOG 中也是有相关的XA的记录，所以就算是切换，也不会导致分布式事务的丢失。
所以，说分布式中间件就是一个通过数据分片键进行数据分发谁都可以做的这样的说法，我只能表达 呵呵 二字。
'
