PGXC是一个基于PostgreSql 构建的分布式数据库，通过Sharding的方式将数据分布在不同的数据库实例中。
PG-XC的系统架构包含：Global Transaction Manager （GTM)、Coordinater(简称CN)、Datanode（简称DN）
其中GTM 为两阶段事务分配全局的XID和 Snapshot；CN是统一的服务入口，具有数据分布的整体视图；DN存储实际的数据，一般按照哈希值进行数据分布，分别存储在不同的DN节点。
先来看一下，PGXC如何保证事务的强一致
假设有一张表以及定义在这个表上的一个事务运行在包含2个CN和2个DN的系统上：
create table account (id int , name varchar(32), money int);
1 张三 10；
2 李四 20；
start transaction;
update account money - 10 where name = '张三'；
update account money + 10 where name = '李四'；
end transaction；
事务隐含的一致性约束是 张三和李四的money 之和是30，假如恰好这2条数据分别分布在DN的2个Shard上，那么执行这个事务需要启动2阶段提交。
PG的事务引擎，通过全局的Snapshot来做可见性判断，而且PG的XID是逻辑意义上的序列号。正常情况下为了保证强一致性，执行的CN节点需要先
从GTM获取全局的Snapshot和GXID，然后下发到DN节点执行：
DN1： update account money - 10 where name = '张三'；
DN2：update account money + 10 where name = '李四'；
2个DN执行完之后再将事务的提交状态上报给GTM；
而且，一旦2阶段事务残留，pgxc_clean可以通过GXID分别找的CN、DN上的两阶段事务，即使执行的CN节点出现宕机的情况，还是可以通过GTM
上持久化的GXID来找到各个节点上残留的2阶段事务并进行清理，使数据库恢复一致性的状态。不过可以看出在这个过程中CN节点和其他参与2阶段事务
的节点与GTM之间需要经过多次通信，必然会影响执行的效率。如果对事务的一致性要求不严格的场景下可以考虑不使用全局的GXID和Snapshot，都使用
各自节点的local xid，这样就不用与GTM进行通信，当然由于各个节点的local xid都不一致，还需要设置一个统一的Txn来串联起各个节点上的事务，以便
做2阶段事务清理。
典型的DML处理流程如下：
2阶段事务的状态都持久化到了CN1节点上，pgxc_clean清理的时候，在DN1和DN2上通过解析出CN1节点和xid，然后到CN1节点上查询事务的状态来决定事务继续提交还是回滚。