ACID分布式事务
PolarDB分布式版原生支持分布式事务，并保证事务的ACID性质。
- 原子性（Atomicity）
- 一致性（Consistency）
- 隔离性（Isolation）
- 持久性（Durability）
PolarDB分布式版通过引入中心授时服务（TSO），结合多版本并发控制（MVCC），确保读取到一致的快照，而不会读到事务的中间状态。如下图所示，提交事务时，计算节点（CN）执行事务时从TSO获取到时间戳，随着数据一同提交到存储节点（DN）多版本存储引擎上，CN通过读取快照时间戳去DN上读取相应版本的数据。
TSO中心授时
PolarDB分布式版分布式事务支持MVCC多版本，分布式的版本号依赖于中心授时服务来生成全局单调递增的时间戳，基于中心授时为版本提供事务的一致性读取。
PolarDB分布式版元数据服务（GMS）基于Paxos共识协议提供一个具备三节点高可用性的服务，PolarDB分布式版的计算节点（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分布式版的计算节点将会使用两阶段提交（Two-phase Commit Protocol，简称2PC）方式提交事务，即便在事务提交过程中发生节点宕机等问题，基于2PC的事务恢复机制也能确保事务原子性。
MVCC多版本
以上面的转账场景为例，如何在转账的同时查询所有账户的余额总额（“对账”）：
SELECT SUM(balance) FROM account;因查询操作的数据涉及多个分区，PolarDB-X首先会获取中心授时确定读取版本，读取过程中会对每行数据的MVCC多版本进行可见性判断，确保只会读取在全局时间戳之前已完成提交的事务。
例如转账事务在多个数据节点的提交有先后时间差，已提交的分支事务因为数据版本号不满足可见性，正在提交的事务数据全部不可见，从而确保总额数据读取的一致性。
