PolarDB for PostgreSQL（简称 PolarDB-PG）是一款阿里云自主研发的云原生关系型数据库产品，100% 兼容 PostgreSQL，高度兼容Oracle语法；采用基于 Shared-Storage 的存储计算分离架构，具有极致弹性、毫秒级延迟、HTAP 的能力和高可靠、高可用、弹性扩展等企业级数据库特性。同时，PolarDB 具有大规模并行计算能力，可以应对OLTP与OLAP混合负载。
本文会介绍单机如何支撑分布式事务，以及如何保证可见性、一致性等特性，这些在开源的代码里面也已经有了，我们在后期会把分布式协调节点的逻辑开源，就可以真正地跑起一个分布式的数据库，并且保证分布式事务全局一致性，提供ACID特性。
基于提交时间戳的MVCC的设计动机
我们基于提交时间戳的MVCC的设计动机有两个，一方面是改进单机的性能，就是消除基于快照的多核可拓展瓶颈，Postgre采用的是基于ID的快照来保证事务的隔离性，这样的话会有一些快照的生成，还有生成的瓶颈。
另一方面，我们在单机上支持基于时间戳的分布式事务协议。这样的话，我们既可以单机来跑，在部署成分布式以后，也可以去支持分布式事务。
消除基于快照的多核可扩展瓶颈
可以看到传统PG基于快照的一些瓶颈，MySQL也是一样的，都会从运行事务列表里获取一个快照来获知在事务或语句开始的时候，当前正在运行的事务。
这样的话会有一个问题，就是它会去加Proc Array的锁去遍历，虽然是共享锁，那么这在高并发下就有一个遍历的开销。另外一个就是共享锁的竞争，因为事务在结束的时候需要加互斥锁去清理，那么这个时候就会造成锁的竞争以及获取快照的开销，O（N）的开销，即要遍历N个Proc。
支持基于时间戳的分布式事务协议
我们在分布式场景下也是一样的，如果在分布式场景也采用XID Snapshot的话，也会造成生成全局快照的单点GTM瓶颈，每个节点也需要通过网络从GTM获取一个分布式的快照，当集群并发事务很高的时候，快照获取的开销也很大。
基于提交时间戳的MVCC
基于提交时间戳的MVCC的话，假如有任意的两个事务T1、T2，T1提交的修改对T2可见的条件就会很简单，就只要T1的提交时间戳小于或等于T2的开始时间戳。事务开始和提交的时候，我们都会给它分配时间戳，对于单机数据库，比如说现在开源的，我们就会采用一个原子变量来生成单调递增的64位时间戳。
我们以一个事例来看，图中有三个事务T1、T2、T3，我们可以看到T1、T2是串行的，相当于T2在T1结束以后才开始的，所以T1的修改对T2是可见的。T3和T2是并行的，这样的话T3对T2不可见，我们可以通过时间戳来确定它的开始及结束的绝对顺序，来保证可见性和隔离性。
提交时间戳存储和访问
在基于时间戳的MVCC中，为了做可见性判断，我们就要存储每个事务的提交时间戳。
存储的管理有空间分配、回收、持久化、故障恢复等。对于单机数据库可以采用非持久化的存储机制，就是PG社区里CSN（Commit Sequence Number）的方案，它维护了一个对全局所有事务都可见的最小的Transaction Xmin。
当XID小于Transaction Xmin的提交时间戳的空间就可以回收，因为它对所有的事务都可见了，只要它的XID小于这个，判断它可见性的时候就可以直接判定为可见，所以就不需要存储，它存储提交时间戳的空间就可以回收，用来存储其他务的时间戳。
XID小于Transaction Xmin可以通过CLOG去判断可见性，就是提交即可见。对于数据库重启，重启之前提交的事务对当前正在运行的事务均可见。
对于一个分布式数据库就不一样，它需要一个持久化的存储，为什么？一是我们的每个节点是去中心化的，每个节点都独立维护了自己的XID的分配，要去计算一个全局的Transaction Xmin不太可行。我们可能会有另外一种方法，就是用一个中心节点，比如说GTM，去维护全局唯一的XID，这样的话计算全局Transaction Xmin就会有开销。
同时分布式的逻辑就会很复杂，而且这样的话XID消耗也会比较快。当规模很大的时候，比如几百个节点的时候，XID消耗就会很快，因为32位的XID很快就会进入回卷的状态。
当没有全局XID分配的情况下，分布式数据库中一个节点重启，重启之前的事务不一定可见，所以需要恢复提交时间戳去判断可见性，所以一个理想的方案就是要把提交时间戳持久化存储。
提交时间戳存储设计与实现
可以看一下持久化存储的系统。
最底层是提交时间戳的一个存储，这是一个物理上的按页持久化存储，并且可故障恢复。上面Buffer层用来缓存访问过的物理页面。
我们同时用了Hash-Partitioned的方法，实现多分区的LRU Buffer，来提高它的可扩展性，减少锁竞争。
事务在提交的时候就会以XID为Key，以CTS为值，写入整个存储中。在做MVCC Scan可见性判断的时候，我们就会去存储里面去读XID的Timestamp。为了加速，我们在Tuple Header里也会缓存这些Timestamp ，这就跟缓存CLOG的提交状态一样，就是为了减少对CTS的访问。
