GaussDB技术解读——轻量全局事务管理GTM-lite

GTM，全称Global Transaction Manager，即全局事务管理器，负责全局事务号的分发，事务提交时间戳的分发以及全局事务运行状态的登记，作为事务管理中的重要模块，为支持事务一致性提供必要的保证。

事务开始和提交时与GTM进行交互获取必要的全局事务信息，包括事务ID，全局时间戳，全局快照等等。与其他模块一个很重要的不同点就是，为了保证一致性和事务标识全局唯一，集群中只要一个主GTM，即只有一个GTM真正参与事务（不过GTM和DN一样是高可用的，支持一主多备或主备从）。

使用GTM来进行事务管理，一个很重要的问题就是会出现单点瓶颈，因为所有需要获取事务唯一标识的事务都需要连接GTM，获取全局快照的时候也都需要连接GTM，在大并发的情况下频繁的交互导致大量的网络通信和锁等待，从而限制了集群性能。在老的GTM模式下，虽然通过将活跃事务链表替换为CSN来减少了通信量，但是由于仍采用全局事务id的策略，所以每个活跃事务仍要在GTM注册槽位，GTM负责管理和分发全局事务id，这导致当并发量大的时候，GTM容易成为单点瓶颈，主要体现在以下两个方面：

（1）在一个事务的执行流程中，CN会与GTM进行多次交互，如事务开始时在GTM注册槽位、获取快照时从GTM获取全局事务id、事务结束时向GTM提交并移除槽位等，这些频繁的交互会带来大量的网络通信和等待；

（2）当并发量超过槽位数限制时，会由于槽位不够影响业务正常进行。由此可见，其影响性能的主要原因在于GTM的协调太强，通过对全局事务id的管控，虽然保证了事务的一致性，但是也限制了事务处理的效率。与GTM模式相反，GTM-FREE模式下CN/DN不与GTM交互，通过CN/DN分别维护本地事务id来保证事务系统的正常运行。这种模式下由于缺少全局事务id以及GTM的其他协调（CSN），事务的一致性会受到影响，从而限制了这种模式的适用范围。综上，现有的两种模式在效率和一致性要求上并没有达到一个很好的平衡，而影响这种平衡的主要因素在与“协调”，协调带来更多一致性的保障，但是却降低了性能。由此，一个好的模式应该是在尽可能少的协调的情况下，达到尽可能高的性能，这也是本章介绍的GTM-LITE模式GTM-LITE的主要目标就是在消除GTM瓶颈影响的同时，尽可能通过更少的信息交互，利用它来协调好事务的并发，从而保证事务一致性的同时提升性能。

为此，GTM-LITE的主要设计思路包含以下4点：

（1）本地事务id取代全局事务id。GTM不再分配全局唯一的事务id，每个CN/DN节点用本地产生的事务id，保证节点内事务id不会重复；对于跨节点的事务，由全局唯一的gid标识符前缀来保证写一致性，由全局唯一的csn号来保证事务读的一致性。

（2）GTM不再维护槽位信息，仅在事务提交时下发全局唯一的csn序列号。GTM下发的全局csn是一个递增的uint64值。这一设计消除了BEGIN, GetNewTransactionId同GTM的交互。进一步，如果事务在GTM提交时失败，可以retry重新获取最新的csn，减少网络故障对系统造成的影响。

（3）本地维护多版本过期脏元组的回收，并引入Snapshot Invalid机制，保证全局事务的一致性。由于舍弃全局事务id，无法直接根据RecentGlobalXmin确定需要清理的脏元组，所以需要利用全局csn来计算RecentGlobalXmin，从而实现GTM架构代码的有效复用。

（4）引入prepared array链表对单节点事务可见性判断进行优化。对于单节点的读事务，不再向GTM申请快照，而是使用本地的快照+prepared array链表来进行可见性判断，这种方式在保证读外部一致性的前提下，尽可能的减少同GTM的交互。基本判断方法为：对于csn<本地快照csn的事务以及本地prepared（在prepared array中）且最终提交的事务，均可见。