《PolarDB for PostgreSQL源码与应用实战》——PolarDB-PostgreSQL开源核心Feature介绍(2) https://developer.aliyun.com/article/1232761?groupCode=polardbforpg
基于CTS支持分布式全局一致性事务(2)
我们目前主要开源的是HLC的版本,在分布式下,每个提交时间戳提交的物理时间并不一定完全一致。比如T1在A节点和B节点,我们不能保证完全同时提交,另一个并发事务T2,可能会看到T1部分的修改,比如看到A提交了,看到了它的修改,但是B正在运行还没提交,根据隔离性它不可见,此时就无法保证分布式的一致性和隔离性。
我们可以采用2PC Prepare等待机制来解决全局提交一致性:采用2PC来提交一个分布式事务,在Prepare阶段,每个节点在CTS中写入该分布式事务的Prepared状态。Commit的时候,我们会去决策一个提交时间戳,再把提交时间戳发下去,把Prepare的状态原子的替换成提交时间戳,当另外一个并发事务T2对T1的修改进行可行性判断时,如果T1处于prepare的状态,我们就要等待T1结束,再进行时间戳的比较。
这样的话,我们就能避免在A节点、B节点看到部分提交结果的问题。
基于PostgreSQL数据结构的读等待机制设计
我们在读等待的时候,不能把Buffer的锁加上,这样的话会阻塞写,影响并发性能。如果发现它是prepare的,要等待它,我们首先要解锁Buffer shared锁,允许并发写进来,同时等待xid结束再去加buffer。
这个地方可以保证它还能找到原来的位置进行扫描,这是因为PG的逻辑就是它会有item去指向这些Tuple,Tuple可能会移动进行页面的compact,但是item是不会动的,它可以找到正确的位置,这样的话就可以保证正确性。同时buffer也会引用计数,这样保证buffer不会被删掉或做其它的操作。
基于HLC的分布式事务时钟算法(1)
我们基于HLC的去中心化的分布式事务时钟来支持分布式事务。
这个 HLC的算法在开源的代码里已经有了,但是协调逻辑分布式的代码还没有开源。我们后面加上分布式协调逻辑的代码以后,就可以支持真正的分布式事务。
我们现在单机上采用HLC来支持单机的事务,就是跑一个单机也能正确地跑,跑分布式的时候,基于HLC可以保证全局一致的事务。HLC的设计是物理和逻辑时钟混合,64位时钟由最低16位为逻辑时钟,中间46位物理时钟(毫秒)和最高两个保留位组成。
这样的话,逻辑时钟主要是用来追踪事务之间的因果先后顺序。物理时钟主要是用NTP或PTP去同步不同节点之间的物理时钟,来保证它们可以读到一个相对很新的快照。
每个节点维护一个max_ts时钟,并周期性持久化,重启后REDO恢复最大值。
我们有三个时钟操作,分别是ClockCurrent,ClockUpdate和ClockAdvance。
ClockCurrentc就是读取当前的Clock,相当于我们用Max_ts和本地的物理时钟local-phys-ts取最大值返回。ClockUpdate就是用一个Timestamp去更新Max_ts,我们取最大值。
ClockAdvance是把max_ts和 local-phys-ts取最大值后再加1返回,整个过程都是加锁来保证原子性。
上述操作中,local-phys-ts是本地机器获取的物理时钟,并取毫秒时间。左移16位与max_ts对其进行运算(max-ts最低16位是逻辑时钟)。
不同机器的物理时钟可以通过NTP或PTP协议进行同步,保证很小的时钟倾斜,保证跨协调节点之间的事务可以获取一个freshness的快照。
基于HLC的分布式事务时钟算法(2)
我们的时钟算法就是在事务Begin的时候,会在协调节点上为它分配ClockCurrent进行startTS,startTS到了每个DN节点以后,会用startTS去更新本地的Max-ts混合逻辑时钟。事务Prepare的时候会去每个参与节点调用ClockAdvance,获取prepareTS,同时返回给协调节点。协调节点会从所有的prepareTS选最大值作为commitTS,同时更新CN的混合逻辑时钟,并且下发给每个DN去提交事务,并且用commitTS去推动每个参与DN的混合逻辑时钟前进。
版本链提交时间戳递增
这个特性可以保证在版本链提交时间戳递增。
假设我们在一个DN上有两个事务T2、T3,T2先获得锁先进行提交,那么ClockUpdate就会用T2的commit_ts,使得该节点的max_ts大于等于T2的commit_ts,那T3获得锁再进行提交,决策的T3的commit-ts,就会大于等于DN1的prepare_ts,它就会大于等于 max{max_ts, local_phys_ts}+1,这样就能保证T3.commit_ts > max_ts >= T2.commit_ts,这样的话版本链时间戳是递增的。
Repeatable Read下,T3会被abort,从而避免丢失写问题。
《PolarDB for PostgreSQL源码与应用实战》——PolarDB-PostgreSQL开源核心Feature介绍(4) https://developer.aliyun.com/article/1232753?groupCode=polardbforpg