在单机数据库事务中，事务的一致性是指事务的任何操作都不会使得数据违反数据库定义的约束、触发器等规则。在分布式数据库中，由于数据分布在不同节点，有些约束难以保证，比如主键和唯一性约束，中信银行当前实现的版本未从数据库本身保证该约束的完整性，只能从使用规范角度进行约束，由应用保证主键和唯一索引的全局唯一性。

　　事务的隔离性

　　事务隔离性的本质就是如何正确处理读写冲突和写写冲突，这在分布式事务中又是一个难点，因为在我们的分布式事务控制方案中，可能会出现提交不同步的现象，这个时候就有可能出现“部分已经提交”的事务。一旦并发应用访问“已经提交”节点中的数据，就需要根据GTID的状态来判断是“部分提交”还是“全部提交”，否则就出现了分布式数据库中特有的一种“脏读”。因此GTID方案可以确保分布式事务的隔离性。

　　事务的持久性

　　和单机一样，分布式事务也需要保证事务的持久性，通过单节点数据的持久化和全局事务状态的持久化来完成，数据的持久化由单节点数据库保证，全局事务状态的持久化由全局事务管理器负责，全局事务管理器采用定时全量和实时增量方式实现事务状态的持久化：将GTID申请和释放的动作实时写到磁盘，同时每隔一定时间将全局事务管理中的活跃GTID列表以异步方式写到磁盘，通过定时的全量活跃GTID列表和实时的增量记录，可以获得任意时刻的活跃GTID列表。

　　异常处理

　　分布式环境下，事务处理涉及的组件、服务器和网络比单机复杂太多，各个环节都可能出现故障，因此异常处理也成为分布式事务的重点。根据故障环节的不同可分为数据节点异常、计算节点异常和全局事务管理器异常。

　　数据节点异常

　　数据节点异常时，全局事务将无法提交，已经提交的本地事务将会被回滚。具体考虑如下几个场景（假设分布式事务涉及三个数据节点：DB1、DB2、DB3，其中DB2发生了异常）：

　　1. 分布式事务还未发起提交：向DB1、DB3发起回滚操作，DB2的回滚由数据节点自身保证；

　　2. 分布式事务已经发起提交：DB2上也已提交，但结果未知。此时需要向所有数据节点发起已提交事务回滚。

　　计算节点异常

　　分布式事务正常运行时，计算节点（假设为计算节点A）发生异常，与数据节点集群及客户端的所有连接都已中断，数据节点上未提交的事务由数据节点自动回滚。客户端通过其他计算节点（假设为计算节点B）重新建立连接进行数据库集群访问，不会影响业务新发起的事务，但由于计算节点A异常时，处于部分已提交状态的事务将无法结束，计算节点B上的事务一旦访问到这些事务涉及的数据就会被阻塞，直到这些事务回滚。

　　具体考虑以下两种场景：

　　1. 每台计算节点上部署监控程序，atv，当计算节点异常时，监控程序将重启计算节点，重启完成后由计算节点自己与全局事务管理器交互并完成异常事务的回滚；

　　2. 如果计算节点服务器已经宕机且无法启动或者监控程序无法重启计算节点服务，则由计算节点管理器协调对等的计算节点（该集群的其他计算节点），完成异常事务的回滚。

　　全局事务管理器异常

　　全局事务管理器采用主备部署，申请或释放GTID时通过实时同步到备机内存、实时增量持久化到本地磁盘、定时全量持久化三重保护机制确保全局事务信息不丢失。在单机异常时会进行主备切换，在双机都异常时，需通过持久化的全局事务信息进行恢复。

　　组合异常

　　1. 组合异常，考虑如下两种场景：

　　数据节点和计算节点同时异常。数据节点和计算节点走各自的异常处理流程即可解决问题，影响的是计算节点上的当前活跃事务以及涉及异常数据节点上的活跃事务的合集。