GTM 提供分布式数据库中所有事务的GXID,并且这些GXID 是唯一的并且是有序的,在事务的开始和结束这段时间保证来控制所有节点中的tuple的可见性.这个功能称之为global snapshot. 并且保证事务的一致性.
在事务中如果选择了read committed 来作为分布式数据库的isolation的话,则事务中的每一个语句都会需要一个SNAPSHOT, 如果是更高级别的方式则SNAPSHOT 会在事务运行中对其进行变动.
在系统的部署中GTM 往往被认为是一个性能瓶颈,而瓶颈的来源于网络的开销, DN, CN 频繁的与GTM进行交互, 所以这三者建议部署在一个网段中,而不是将其分割在不同网段以及不同的交换设备中.
Coordinator 节点在接受到应用端对数据库的访问,在coordinator中会使用GTM client library 来与GTM 沟通获得事务的GXID和事务的SNAPSHOT, 并报告事务运行的状态.
而GTM 则通过自身提供的端口来接受连接,每一个coordinator 和 datanode 的通讯,当接受一个连接,产生一个GTM THREAD 线程去handle GTM于 datanode 和 coordinator之间的通讯. 在通讯的过程中线程始终在CN 和 DN 之间建立事务snapshot,以及发送事务GXID,只有事务完成后,这个线程才退出服务.
实际上GTM 并不直接与coordinator通用,而是通过GTM proxy来进行更有效的通讯.一般来说一个GTM proxy 可以负责上百个 coordinator 的请求.
GTM proxy 通过对coordinator所有的请求扫描的方式,将多个请求进行分组发送给GTM,减少coordinator 与GTM 之间的交互频率.
分布式事务在POSTGRES-XL 通过2PC的来实现, 对于每一个分布式事务本身是强一致的,对于自己的的事务的一致性是完成了,但是对于其他事务对于自己的事务的可见性来看,则无法保证,GTM 就是为了完成这个任务而存在的.
GTM 的配置上比较简单,处于GTM 对于整体POSTGRES-XL架构的重要性,GTM 一定要有一个STANDBY 的节点,本身GTM 的配置文件并不复杂, 大部分的配置项都是与STANDBY有关的配置,而POSTGRES-XL 的GTM 的standby节点一定是要和GTM 节点是要同步的,而不是异步的数据复制. 同时对于PG 的control 文件是要定期进行备份的,这也是对GTM重要性的一种保护. 其中最重要的配置项就是startup 如果选择项是ACT 则说明这个节点是主节点对外提供服务的节点,如果是STANDBY 则这个GTM节点是备用节点.
下面我们从几个图来窥探一下coordinator , GTM 之间以及GTM 本身的工作的基本情况.
1 在coordinator获得应用的请求后,通过本身的事务生成器 去请求本身的gtm.client 去产生请求包,其中包含相关的请求的事务信号类型,以及事务所需的隔离级别.
2 这些信息通过gtm_proxy 将信息汇总后,发往GTM (需要看隔离级别,不同的隔离级别对产生的gtm_proxy包的封包类型不同)
3 GTM 接受到命令后通过下图方块中的逻辑来对不断的请求进行处理
4 每个请求都需要获取到全局锁, 通过全局锁来将操作原子性,将获得的信息来进行排序,并进行处理保证处理信息的有序性.
5 将产生的xid 信息发送回gtm_proxy, 最终coordinator 将信息获得返回给申请的GXID的事务.
