GaussDB分布式事务的读一致性
为了防止瞬时不一致性，确保分布式事务的强一致性，一般需要全局范围内的事务快照，来保证全局MVCC和快照的一致性。
在GaussDB中，GTM负责提供和分发全局的快照，也就是CSN。任何一个读事务都需要到GTM上获取全局快照，任何一个写事务都需要到GTM上获取全局事务提交号，GaussDB通过全局一致性的时间戳快照来保证分布式事务的读一致性。
图6 GaussDB分布式事务的读一致性示意图
如图6所示，T1事务在DN1和DN2上修改了数据，T2在各个时机读取T1修改的数据，分析各种情况下的数据一致性：
1）T2事务在t1，同时发起向DN1和DN2的读操作（对应read3和read4），DN1和DN2分别返回data_a_v1和data_b_v1，两个都是V1版本，所以，此时T1读取的数据是一致的。
2）T2事务在t2，同时发起向DN1和DN2的读操作（对应read6和read8），DN1和DN2的读事务操作都需要阻塞到写事务结束后，再进行可见性判断，如果写事务最终被回滚时返回的是data_a_v1和data_b_v1，最终被提交时返回的是data_a_v2和data_b_v2，那么，此时T2读取的数据是一致的。
3）T2事务在t3，同时发起向DN1和DN2的读操作（对应read11和read12），DN1返回data_a_v2，DN2阻塞到commit13消息后返回data_b_v2，两个都是V2版本，所以，此时T3读取的数据是一致的。
4）T2事务在t4，同时发起向DN1和DN2的读操作（对应read14和read15），DN1返回data_a_v2，DN2阻塞到commit13消息后返回data_b_v2，两个都是V2版本，所以，此时T4读取的数据是一致的。
可见，在上述几个时机下，数据都是一致的。
对于各DN上的记录，如果其对应的写事务是处于活动状态时，可以根据该记录其相对于commit_in_progress和commit_determined的不同流程段进行可见性判定，具体判断规则如下：
若记录对应的写事务在DN上是处于活动状态时，且处于prepare阶段之前，本数据不可见；
若记录对应的写事务在DN上是处于活动状态时，且处于prepare和commit阶段之间，则需要阻塞等待到对应的写事务结束后，再进行可见性判定；
