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節點上查詢事務的狀態來決定事務繼續提交還是回滾。