分布式事务对于两阶段提交的错误处理

一、背景

笔者和团队在昆仑分布式数据库中的两阶段提交方式，可以成功避免经典的两阶段提交算法的缺陷。

而在此分布式事务处理两阶段提交机制和原理上，笔者和团队增强其容灾能力和错误处理能力，可以做到任意时刻昆仑数据库集群的任意节点宕机或者网络故障、超时等都不会导致集群管理的数据发生不一致或者丢失等错误。

本文会详述分布式事务对于两阶段提交算法的错误处理原理和机制及延时损耗~

二、昆仑数据库如何对两阶段提交算法错误处理？

在生产环境的分布式数据库集群的工作场景中，通常只有不到 0.01%的分布式事务提交会发生错误，但是我们仍然需要处理所有可能发生的错误。

因为哪怕执行了 100 亿笔事务，只要有 1 笔发生了提交错误，都会导致用户数据出错。

数据库系统就是要确保事务永远正确地提交，ACID 保障始终成立，没有例外。

这对于分布式数据库系统来说，会比单机数据库更加复杂，因为可能的错误来源更多（多个计算节点和多个存储节点，及其之间的网络连接）。

这也是为什么数据库系统的设计和实现会如此复杂，而分布式数据库系统的设计和实现更加复杂。

下面，我们就看一下昆仑分布式数据库集群如何处理分布式事务提交过程中发生的错误。我们分别讲述两阶段提交的每个阶段的错误处理，以及批量写入 commit log 的错误处理。

2.1 第一阶段错误处理

图 1. 第一阶段提交失败的处理

如果 prepare 阶段发生语句错误，网络断连或者超时，那么 GTM 会提交 rollback 记录请求给 GTSS，并且不等待其返回结果就立刻发送 rollback 命令给出错的节点并且断连超时的连接，然后返回错误给客户端，告知客户端该事务 GT 被回滚。

GTSS 会在 commit log 中记录 GT 的提交指令为 ROLLBACK, 这样 cluster_mgr 随后处理 GT 的 prepared 事务分支时会回滚它们。

2.2 批量写入 Commit logging 错误处理

图 2. commit log 写入失败的处理

如果 GTSS 写入 commit  log 出错或者超时，那么 GTM 会回滚 GT 的所有 preapred 事务分支，也就是发送 XA ROLLBACK 给 GT 写入的所有存储集群，然后不论其结果如何都返回‘Aborted’给客户端标明 GT 被回滚了。

即使 XA ROLLBACK 发送失败了那么这个事务分支仍然会按预期被 cluster_mgr 回滚。

2.3 第二阶段错误处理

图 3. 第二阶段提交失败的处理

如果第二阶段发生网络错误或者超时，那么仍然返回提交成功给客户端。

这是因为只要记录了 commit log 提交的任何分布式事务，都必须完成提交。

如果执行第二阶段期间任何计算、存储节点发生宕机或者网络故障，那么 cluster_mgr 进程会根据 commit log 的指令，来处理这些事务分支 --- 如果指令是提交那么就提交 GT 的所有事务分支。

如果指令是回滚或者无法找到 GT 的 commit log，那么就回滚 GT 的所有事务分支。

如果第二阶段进行过程中计算节点宕机或者断网了那么这个事务仍将提交，此时应用系统后端（也就是数据库的客户端）会发现自己的 commit 语句没有返回直到数据库连接超时（通常应用层也会让终端用户连接超时）或者返回了断连错误。

三、延时损耗

由于两阶段提交的 prepare 和 commit 阶段都需要等待存储引擎 flush WAL 日志，并且在两个阶段之间还需要等待 commit log 写入元数据集群，所以两阶段提交的时耗一定比执行相同的 SQL DML 语句但做一阶段条会增加一些。

根据这个性能报告：http://www.zettadb.com/blogs/perf-cmp1，昆仑数据库的两阶段提交在普通的服务器硬件配置和千兆网络情况下会增加约 30 毫秒的延时。

在商用服务器硬件和网络环境下，这个延时增加会少于 30 毫秒。这个 30 毫秒包括了 commitlog 的写入，多执行一个阶段的等待时间以及所有增加的网络通信时间开销等。

四、总结

昆仑分布式数据库的分布式事务处理机制，确保了分布式事务执行和提交的一致性和容灾能力，在事务提交期间任何节点、网络故障都不会导致事务的 ACID 保障失效，从而确保了用户数据正确。

在 0.9 版本中，昆仑数据库将支持全局 MVCC 一致性，那时将另外撰文介绍昆仑分布式数据库的全局 MVCC 的工作机制（敬请期待~）。

需要技术支持可以微信搜索微信号（KunLunDB-Linda），添加客服，在线沟通即可。

END