TSO全局時鐘
PolarDB-X分布式事務支援MVCC多版本，分布式的版本号依賴于全局時鐘服務來生成全局單調遞增的時間戳，基于全局時鐘作為版本來提供事務的一緻性讀取。
PolarDB-X中繼資料服務（GMS）基于Paxos共識協定提供一個具備三節點高可用性的服務，PolarDB-X的計算節點（CN）會通過RPC接口和中繼資料服務（GMS）進行通訊并擷取全局時鐘。
事務2PC送出
以轉賬場景為例，假設使用者賬戶是一張分區表，那麼同一筆轉賬交易的轉入方和轉出方很可能位于不同的資料節點上，是以需要分布式事務來保證轉賬結果正确。
BEGIN;
UPDATE account SET balance = balance - 20 WHERE name = 'Alice';
UPDATE account SET balance = balance + 20 WHERE name = 'Bob';
COMMIT; 
如果事務内寫入的資料涉及多個分區，PolarDB-X的計算節點将會使用兩階段送出（2PC）方式送出事務，即便在事務送出過程中發生節點當機等問題，基于2PC的事務恢複機制也能確定事務原子性。
MVCC多版本
以上面的轉賬場景為例，如何在轉賬的同時查詢所有賬戶的餘額總額（“對賬”）：
SELECT SUM(balance) FROM account; 因查詢操作的資料涉及多個分區，PolarDB-X首先會擷取全局時鐘确定讀取版本，讀取過程中會對每行資料的MVCC多版本進行可見性判斷，確定隻會讀取在全局時間戳之前已完成送出的事務。
例如轉賬事務在多個資料節點的送出有先後時間差，已送出的分支事務因為資料版本号不滿足可見性，正在送出的事務資料全部不可見，進而確定總額資料讀取的一緻性。
分布式事務的下遊生态
讀寫分離的一緻性
事務型的分布式資料庫一般會采用讀寫分離的模式提升讀的性能，是以分布式事務除了保障主庫的一緻性以外，還需要保證使用者在使用讀寫分離模式下對于備庫的一緻性。
PolarDB-X産品支援主執行個體和隻讀執行個體，主執行個體由基于Paxos多數派協定的 Learder/Follower角色組成，隻讀執行個體由基于Paxos協定的Learner角色組成。PolarDB-X針對分布式事務一緻性的設計，除了在存儲節點（DN）的leader主副本中儲存事務資訊之外，也會将資料的事務多版本資訊同步到learner副本中，可以保證隻讀執行個體上的多個分區資料的讀的一緻性，具體特性請參見
混合負載HTAP。
例如，主庫裡寫入了一個版本為100的資料，而下一次的查詢中帶着全局時鐘傳回的版本為101。當查詢被路由到隻讀的learner節點時，即使learner節點有資料複制延遲，PolarDB-X也可以阻塞讀來滿足讀的一緻性。
全局變更日志CDC
事務型的分布式資料庫除了面向線上業務的高并發寫入以外，一般還需要将線上資料同步給下遊的災備資料、彙聚業務、或資料倉庫系統等，下遊業務對于事務日志的一緻性也有比較強的訴求，例如事務不能亂序、事務原子性、DDL支援同步等。
MySQL binlog是MySQL資料庫中記錄變更資料的“二進制日志”，它可以看做是一個消息隊列，隊列中按順序儲存了MySQL中詳細的增量變更資訊，通過消費隊列中的變更條目，下遊系統或工具實作了與MySQL的實時資料同步，這樣的機制也稱為CDC（Change Data Capture，增量資料捕捉）。
PolarDB-X存儲節點（DN）在變更日志設計上也會儲存分布式事務資訊，通過PolarDB-X日志元件（CDC）收集分布式下多個存儲節點（DN）的日志流，進行彙總、重組、排序、落盤等過程，提供滿足分布式事務一緻性語義的“二進制日志”，并全面相容MySQL binlog協定和生态。具體特性請參見
全局日志變更備份恢複的一緻性
傳統關系型資料庫一般會采用資料庫的全量備份來保證資料安全。在遇到資料異常、删庫跑路的風險時，需要通過資料庫的備份集進行快速恢複，其中資料恢複也要保證事務的一緻性。另外，分布式資料庫通常資料存儲規模更大，對于備份恢複的一緻性有更大的挑戰。
PolarDB-X在存儲節點（DN）的資料和變更日志中都儲存了分布式事務的全局時鐘（包含了時間戳資訊），任意時間點的資料恢複（PITR，point-in-time recovery）都可以快速将時間戳轉化為分布式的全局時鐘，在備份恢複中按資料的版本可見性進行處理，同時PolarDB-X結合分布式的多節點并行來全面提升備份恢複的效率。具體特性請參見
資料備份與恢複