pgxc架构下两阶段提交异常分析

在当前去IOE的大潮下，分布式数据库正如火如荼的发展起来，特别是国产数据库呈现了井喷态势。一个典型的分布式数据库应该具有如下组件：①协调节点，也叫sql转发节点，用来进行sql协议支持，分布式执行计划生成与下发；②数据节点：用来存储数据，同时进行运算；③全局事务管理器，用来保证事务一致性。为了保证高可用，成熟的分布式数据库这些节点都具有主备切换功能。

Pgxc就是这样cn+dn+gtm的经典架构，底层基于postgresql数据库，pgxc架构如下：

应用连接到协调节点coordinator，数据hash到每个数据节点datanode，所有数据库节点组成完整一份数据，协调节点具有多副本，多个cn节点是无状态的（其实这里并不是真正意义上的无状态，首先ddl元信息需要在每个cn进行同步，否则连到不同的cn可能查到不一致的结果；还有一方面是两阶段残留的问题，这个问题我们后面再细细讨论）。Dn是主备架构，主备通过流复制进行同步。Gtm负责生成全局gxid+snapshot，这里的snapshot是为了保证全局的读一致性，做读可见性判断。

pgxc两阶段提交流程

下图只以一个DN为例，主要分为下面几个阶段：

①：CN prepare ->②：所有DN prepare ->③：CN commit->④：所有DN commit

现在我们假设在如上四个阶段发生异常探讨数据库的处理机制。

①cn prepare阶段发生cn/dn宕机：

这种情况下不需要处理，如果cn宕机能够重新启动，那事务继续执行，如果cn无法启动，那么会引入超时机制将事务进行回滚。同理如果dn宕机，那事务也会等待一个超时时间，然后进行回滚。总之，这种情况不会造成事务不一致。

②dn prepare ok阶段发生cn/dn宕机：

这种情况其实和上面类似，也是会阻塞一个超时时间进行回滚，不会造成不一致现象。

③cn commit阶段发生cn/dn宕机：

如果在cn下发完cn commit命令后宕机，这时dn收到commit命令后会进行提交，但是返回commit ok时发生cn宕机，事务进入阻塞状态。如果cn下发commit之后某个dn发生宕机，则会造成某些dn commit成功，某些dn commit失败，造成不一致，但是如果dn重新启动后会继续去cn上拿事务提交信息，发现是commit状态，则会继续执行commit操作，提交之前的事务。在这个地方我们可以探讨一个更极端的情况，如果此时cn也宕机了，那么失败的dn重启后去cn拿状态发现拿不到，这是这个失败dn上的事务就处于一个未决态，不知道是应该提交还是回滚，这时候应该有一个进程能够从其他dn上发现该状态并报告给故障dn，通知它进行提交。这个角色就是pgxc_clean进程，其实之前几种情况下的事务的回滚也是该进程的工作。那我们再深入一下，如果该dn是事务的唯一参与者，那么此时pgxc_clean就无法从其他dn以及cn获取状态，这时该dn就是真正的未决态了。我们知道pgxc有个剔除cn的功能，剔除cn一方面是解决了cn宕机时无法执行ddl，另一方面解决了这个未决态的问题。

④dn commit ok阶段发生cn/dn宕机：

这种情况下其实每个dn都已经提交成功，只是返回ack失败，此时事务已经是一致的了，如果cn宕机，会选举新的cn，如果dn宕机也没有影响，数据已经落盘，启动后数据不会丢失。

为了测试两阶段事务我们还专门研发了跨节点转账程序，转账程序逻辑如下：

一个transfer_test表包含客户号、余额等信息，随机选取两个账户进行两条update转账，两条转账放在一个事务里。转账跨节点的概率为(n-1)/n，n为DN个数。转账程序支持高并发，支持指导账户，支持记录tps值。使用改程序我们也测试出某些分布式数据库不一致的问题，同时也测试出了两阶段协议的阻塞问题。