银行的核心系统数据是强一致性，那么分布式数据库的数据强一致性如何保证？安全性如何保证？

Newsql分布式数据库基本都是通过获取全局时钟时间戳，采用二阶段提交实现一致性，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。

分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。

数据库最重要的一个特性就是事务，事务是数据库最小执行单元，具有原子性、隔离性、一致性和持久性的特点，即ACID ，在传统的单机数据库中已经完美的支持这个特性。业务开发时将交易代码封装到事务中，这样就不需要关注数据的状态，只要关注业务逻辑就好了，一旦交易失败，数据库自动保证数据恢复到交易之前的状态。

分布式环境中，由于数据被水平切分，原来集中在单一节点变成分散在多个节点上，数据之间关系的完整性被割裂。原来一个节点内完成的交易，要到多个节点完成。如果其中若干节点已经完成提交，有一个节点的操作失败，则对于已经提交数据要进行回滚，让数据回到交易前的状态，数据库本身不能回滚已经提交的数据，只能由业务实现补偿操作，每个业务都要准备相应的补偿业务来保证业务失败带来的数据不一致，工作量巨大，业务逻辑复杂起来，改造过于痛苦。

不能让业务来关注数据的状态，来处理数据状态的回滚。针对分布式事务的原子性，我们从两方面入手，对于节点上未提交的事务，由数据本身的回滚机制保证；对接节点上已提交的事务， 由 系统从日志中找到对应的语句，自动生成一个反向的补偿语句，让系统自动执行这个补充操作，使数据最终回到交易初始状态，完成事务的原子性。

引入了全局事务管理器，为每个事务分配一个全局事务ID，事务操作会将ID记录到日志中，一旦这个分布式事务失败，系统就会根据ID在日志中进行检索，识别出该事务执行的操作。

例子，A-50已经提交，B+50未提交，但整个事务失败。B+50的由于数据库未提交，数据回滚交给数据库保证，已提交的A-50操作，数据库本身没办法回滚，我们就会从日志中解析出A-50的语句，生成A+50的操作，再执行一遍，使数据恢复到交易之前的状态。这就是我们的自动补偿机制，来保证分布式事务的原子性。

（在分布式事务里，两阶段提交也能保证分布式事务的原子性，相对于两阶段提交，我们的优势是支持已提交数据回滚，这样能够极大的提升系统的性能，而不是等待未提交事务最终提交，导致数据一直处在被锁定的状态，增加了锁冲突几率。）

隔离性用于阻止分布式环境中的脏读问题。即读到不该读到的数据，用刚刚的例子来说，如果在A-50已提交，B+50尚未提交，有一个事务来统计所有的账户数据，这个时候读取到的数据是150，总账少了50元，数据产生不一致。这个是两阶段提交方案，没有全局锁导致的脏读问题。

针对事务隔离性的问题，将全局事务ID作为每个事务的全局锁，事务开始时为其分配一个ID，保存在GTM中，事务结束后从GTM中释放掉对应的ID，这样GTM中就有当前所有处在活跃状态的事务信息，因此，在读写操作前查看操作的数据是否处在活跃状态，如果是活跃状态，则等待事务结束后，再进行读写操作。这样的优势是有全局锁就能够彻底解决分布式环境中的脏读问题。