《PolarDB for PostgreSQL源码与应用实战》——PolarDB-PostgreSQL开源核心Feature介绍（1） https://developer.aliyun.com/article/1232762?groupCode=polardbforpg

多核可扩展CTS buffer管理

接下来看一下多核可扩展CTS buffer的管理。

CTS在存储上跟CLOG类似,是连续的空间，就是存储32位连续XID的提交时间戳，每个XID占用8字节去存储它的Timestamp，物理上用连续的一些的文件来存储。同时将文件逻辑上切分成一组物理页，然后可以按需加载到LRU Buffer里面。如果有一个全局的Buffer的话，我们可能会在LRU发生替换的时候，写回的时候会有全局锁的竞争，在加锁的时等待IO的完成，这样会序列化IO访问，并造成比较严重的可扩展性瓶颈。

我们实现了一个LRU多分区划分。每个XID对应在一个固定的物理页里，然后物理页再按照固定的算法映射到Hash partitioned的LRU分区中，这样的话我们可以去掉中心的竞争，这样每个分区可以独立地进行LRU替换、刷盘、读取磁盘，这样可以消除全局锁的竞争，并且并行化IO处理。

多核可扩展性

上图是一个实验，我们在一个机器上，实验是客户端数目从1并发到128，LRU从1个LRU分区到64个LRU分区，但即便是不同的分区，它总的Buffer大小是一样的。

在上图中可以看到在不同并发（1~128）下不同LRU Partition的数目的吞吐。随着LRU的数目越多，它的性能和可扩展性越好。最下方的那条线就是单LRU，在32个并发的时候，它的性能就开始出现转折，就会慢慢变差，甚至会并发越高性能越低，而多分区LRU会保证并发越高，性能能够线性增长。

总体来说，我们可以保证性能更好，这样频繁访问CTS不会带来很大的瓶颈和开销。

CTS持久化和故障恢复

关于CTS持久化和故障恢复，我们每个事务XID在CTS中有四个状态，分别是提交，终止，运行和 2PC prepared。那么在同步提交模式下，事务提交时间戳先写入WAL，再写入CTS，从而支持故障恢复。同时，我们用 2PC record 记录来恢复CTS中prepared状态。异步提交模式下就跟CLOG一样，我们会去记录最大提交的LSN，在CTS页面在写入磁盘之前，保证WAL已经持久化到该LSN。

CTS快速事务状态查询机制（1）

另外一个就是，我们相比社区CSN也好，PG也好，我们可以更好地做到快速事务状态查询。

Postgre SQL判断事务状态的时候，会结合CLOG和Proc Array去判断，我们从CLOG中能够获取事务是否提交状态，而判断事务是否正在运行，需要遍历Proc Array来确定，判断事务是否运行在tuple update，hot-chain pruning的时候关键路径会被频繁调用，造成 Proc Array锁的竞争，以及高并发下遍历开销O（N）的时间开销。

那PostgreSQL为什么不能用CLOG来独立地判断事务是否运行，而要去遍历Proc Array呢？

这是因为CLOG中每个XID的Commit的状态都是准确的,REDO可以恢复所有提交状态，只要提交了肯定都有。Abort的状态就不一定了，因为Abort分为事务主动Abort，或者是报错，它会记录在CLOG中。但是数据库Crash的时候，比如断电或其他原因造成的事务abort，就来不及写入CLOG，REDO也没法恢复。对于CLOG中未写入提交状态的事务，它可能是正在运行，也有可能是Crash Aborted，这个时候我们就没法通过CLOG去做判断，所以PG需要结合Proc Array去判断是否正在运行。

CTS快速事务状态查询机制（2）

我们设计了一种oldest active xid机制实现通过CTS O(1) 免锁快速查询所有事务状态，可以去掉Proc Array的遍历。和CLOG一样，CTS中提交事务状态都是准确的，重启以后，我们可以确定一个oldest active xid。这个XID怎么确定,就是通过next xid, next xid也是故障恢复以后会确定下一个可用的xid初始化，并且要小于等于所有的2PC prepared xid。故障恢复时，我们会把oldest active xid到next xid这一段区间里面，CTS为0的全部会设成aborted，“P”就恢复成Prepared，“C”就恢复成Commit。“0”表示未设置，我们就认为它是在上一次故障的时候就aborted掉了还没来得及写，我们就把它主动恢复成abort。

运行时，小于oldest active xid的CTS，如果是非提交的，例如0，它就是aborted，是在上一次crash aborted。如果大于这个的，就通过CTS直接去返回。这样的话我们就不需要去遍历Proc Array，Proc Array在高并发的时候开销就会很大。这样的话只要O(1)的时间查询就可以确定状态是提交，abort还是运行，这样性能会更好，并且会没有锁的竞争。

CTS存储空间回收

下面介绍CTS存储空间回收。

因为我们是以XID为索引的Key，从2的32次方，PG会存在XID回卷，我们会跟着XID回卷去truncate CTS的空间。

PG的XID逻辑就是它有2的32次方的空间，它会一分为二，这样它在回卷的时候保证可见性判断。如上图所示，next xid往上是它过去的xid，往下是它未来的xid。它不管怎么转，都是可以回卷，都可以正确比较两个XID的大小。它会定期地创建一个Frozen xid cutoff，等于oldest xid减去一个配置的guc的一个Frozen参数，这样把之前的xid全给回卷了。

并将之前回卷的XID在每个tuple中改成Frozen xid，这样表示它对其它所有正在运行的事务均可见的，这一部分xid就被回收，可以再用了。

CTS就随着xid的逻辑，在它回卷的时候会把回收的XID空间对应的CTS存储空间给Truncate掉，然后回卷的时候又重复利用来存储提交时间戳。这样的话就可以2的32方XID对应32GB的CTS文件存储就可以保证一直用下去，不会溢出。

基于CTS支持分布式全局一致性事务（1）

我们基于CTS支持分布式全局一致性的事务，相当于每个节点都会有个CTS，但是同一个分布式事务的提交时间戳是一样的，比如1001。但是它在每个节点，XID是各自独立分配的，各自独立维护，但是它的提交时间戳是一样的，可见性判断都是全局一致的。开始和提交时间戳可以用中心化的时钟GTM来生成，或者用混合逻辑时钟HLC来生成。

《PolarDB for PostgreSQL源码与应用实战》——PolarDB-PostgreSQL开源核心Feature介绍（3） https://developer.aliyun.com/article/1232755?groupCode=polardbforpg