« openGauss 数据库并发控制 | Blog首页 | MacOS Monterey在腾讯会议声音不起作用coreaudiod重置 »

openGauss 分布式事务

前面我们简要介绍了单机事务和分布式事务的区别，也指出了在分布式情况下，可能存在特有的原子性和一致性问题。本文主要介绍在openGauss数据库中，如何保证分布式事务的原子性和强一致性。

1 分布式事务原子性和两阶段提交协议

为了保证分布式事务的原子性，防止出现如图10-2中所示的部分DN提交、部分DN回滚的"中间态"事务，openGauss采用两阶段提交（2PC）协议。

如上图所示，顾名思义，两阶段提交协议将事务的提交操作分为两个阶段：

• 阶段一，准备阶段（prepare phase），在这个阶段，将所有提交操作所需要使用到的信息和资源全部写入磁盘，完成持久化；

• 阶段二，提交阶段（commit prepared phase），根据之前准备好的提交信息和资源，执行提交或回滚操作。 两阶段提交协议之所以能够保证分布式事务原子性的关键在于：一旦准备阶段执行成功，那么提交需要的所有信息都完成持久化下盘，即使后续提交阶段某个DN发生执行错误，该DN可以再次从持久化的提交信息中尝试提交，直至提交成功。最终该分布式事务在所有DN上的状态一定是相同的，要么所有DN都提交，要么所有DN都回滚。因此，对外来说，该事务的状态变化是原子的。

下表总结了在openGauss分布式事务中的不同阶段，如果发生故障或执行失败，分布式事务的最终提交/回滚状态，读者可自行推演，本文不再赘述。

发生故障或执行失败时事务的最终状态

2 分布式事务一致性和全局事务管理

为了防止瞬时不一致现象，支持分布式事务的强一致性，我们需要全局范围内的事务号和快照，以保证全局MVCC和快照的一致性。在openGauss中，GTM负责提供和分发全局的事务号和快照。对于任何一个读事务，其都需要到GTM上获取全局快照；对于任何一个写事务，其都需要到GTM上获取全局事务号。

为了防止瞬时不一致现象，支持分布式事务的强一致性，我们需要全局范围内的事务号和快照，以保证全局MVCC和快照的一致性。在openGauss中，GTM负责提供和分发全局的事务号和快照。对于任何一个读事务，其都需要到GTM上获取全局快照；对于任何一个写事务，其都需要到GTM上获取全局事务号。

在上图中加入GTM，并考虑两阶段提交流程之后，分布式读-写并发事务的流程如下图所示。对于读事务来说，由于写事务在其从GTM获取的快照中，因此即使写事务在不同DN上的提交顺序和读事务的执行顺序不同，也不会造成不一致的可见性判断和不一致的读取结果。

细心的读者会发现，在上图的两阶段提交流程中，写事务T1在各个DN上完成准备阶段之后，首先第一步是到GTM上结束T1事务（将T1从全局快照中移除），然后第二步再到各个DN上进行提交阶段。在这种情况下，如果查询事务T2是在第一步和第二步之间在GTM上获取快照，并到各个DN上执行查询的话，那么T2事务读到的T1事务插入的记录v1和v2，它们xmin对应的XID1已经不在T2事务获取到的全局快照中，因此v1和v2的可见性判断会完全基于T1事务的提交状态。然而，此时XID1对应的T1事务在各个DN上可能还没有全部或部分完成提交阶段，那么就会出现各个DN上可见性不一致的情况。

为了防止上面这种问题出现，在openGauss中采用本地二阶段事务补偿机制。如下图所示，对于在DN上读取到的记录，如果其xmin或者xmax已经不在快照中，但是它们对应的写事务还在准备阶段，那么查询事务将会等到这些写事务在DN本地完成提交阶段之后，再进行可见性判断。考虑到通过两阶段提交协议，可以保证各个DN上事务最终的提交或回滚状态一定是一致的，因此在这种情况下各个DN上记录的可见性判断也一定是一致的。

3 小结

本文主要结合openGauss数据库的事务机制和实现原理，基于显式事务和隐式事务，介绍事务块状态机的变化，以及openGauss事务ACID特性的实现方式。尤其的，对于分布式场景下的事务原子性和一致性问题，介绍openGauss采取的多种解决技术方案，以保证数据库最终对外呈现的ACID不受分布式执行框架的影响。

By enmotech on 2021-11-25 14:52 | Comments (0) | modb.pro | 3441 |

openGauss，