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節點上查詢事務的狀態來決定事務繼續提交還是回滾。
dynamo 的最終一致性和兩階段提交
插一句,在寫這個東東的時候,發現我發的那個 dynamo 簡介中,關於 w n r 模型的一致性說明是有錯誤的,在那個文章裡加了個注釋.因為沒有原始碼可看,很多東西只能靠自己的理解來寫了,請發現問題的同學不吝指出,謝謝.最近聊天時,有些同學提出用兩階段提交來實現分布式系統中的一致性.下面以 dyna...
分布式系統中的一致性協議之兩階段提交協議
分布式系統中的一致性協議之兩階段提交協議 兩階段提交協議是很常見的解決分布式事務的方式，他可以保證分布式事務中，要麼所有參與的程序都提交事務成功，要麼都取消事務，這樣做可以在分布式環境中保持acid中a 原子性 在兩階段提交協議中，包含了兩種角色 協調者與參與者。參與者就是實際處理事務的機器，而協調...
事務的一致性
首先,我們需要搞清楚為什麼會出現事務.這句話的大體含義就是,事務的產生,其實是為了當應用程式訪問資料庫的時候,事務能夠簡化我們的程式設計模型,不需要我們去考慮各種各樣的潛在錯誤和併發問題.可以想一下當我們使用事務時,要麼提交,要麼回滾,我們不會去考慮網路異常了,伺服器宕機了,同時更改乙個資料怎麼辦對...