TDSQL 的分布式事务处理技术：高效的分布式事务双一致性

分享一下 TDSQL 在实现“双一致性（事务一致性、分布式一致性）”，并提高分布式事务型集群的处理效率的探索实践。

众所周知，数据库是一个高并发系统，所有的操作通过事务的语义加以约束。而事务的语义，表现为事务的四个特性——ACID：原子性（A）、一致性（C）、隔离性（I）、持久性（D）。而一个数据库系统，其最核心的技术，就是事务处理技术。为了保障 ACID，数据库使用了多种复杂技术，其中，技术的核心是并发访问控制算法。

**事务处理技术，有两个初衷：**一是数据正确性，二是并发高效率。TDSQL 的分布式事务处理模型，经历了 2 代，第一代采用的技术是 2PL+MVCC，第二代采用的是 OCC+2PL+MVCC。OCC 技术融合了 2PL 以解决高冲突不能高效率的问题，OCC 融合了 MVCC 消除了读写、写读互相阻塞的并发问题进一步提高了性能，自适应的 OCC 使得在 OCC 和 2PL 间动态自动切换，使得分布式事务处理机制更聪明。

**但是，这些还不足以体现 TDSQL 如何着手提高分布式事务的效率。**在架构上，TDSQL 是去中心化的架构，没有集中式单 Master 那样的处理分布式事务的单点瓶颈，事务协调器间传递相关联的分布式事务控制信息量被优化，分布式并发访问控制算法的冲突粒度控制在数据项一级从而提高了事务的并发度，因而效率更高。另外还有很多其他方面的优化，使得 TDSQL 的分布式事务处理效率较高。

而我们继续探讨，在分布式背景下，怎么实现“双一致性（事务一致性、分布式一致性），并提高分布式事务型集群的处理效率？”

实现分布式事务面临的问题

该问题，是业界一个难题。Google 的 Spanner 系统实现了双一致，但事务处理的效率很低。TDSQL 在深入研究分布式事务处理的技术时，不仅解决了全局一致性问题（2019DTCC 大会分享：分布式数据库全局读一致性），而且提出了一个“统一致性模型”，不仅在正确性上实现了双一致的功能，而且高效地解决了该问题。

在 TDSQL 看来，双一致性的正确性相对容易实现（尽管这也是一个很难解决的问题），但分布式事务型数据库的性能难以有效提高。

那么，有哪些因素，制约着分布式事务型数据库性能的提高呢？

一些研究者认为，是网络带宽限制了性能；一些研究者认为，制约分布式事务型数据库性能的提高有 2 个因素，一是“latency”本身，二是“latency”延长了事务的生命周期，而长的事务生命周期导致并发事务发生冲突的概率增大，进而引发事务回滚降低了性能。

** 分布式事务的瓶颈**

另外，影响正确性和性能的，是事务处理技术中的核心技术——并发访问控制算法。

如图 3 所示，实验表明，在事务型数据库中，OCC 算法效率更高，在多核环境下，OCC 算法比 2PL 算法性能高出 170 倍。但是，高的并发冲突下，OCC 的回滚率增加，表明 OCC 算法的缺点也很明显。

并发访问控制算法的优劣

但是，还有研究者对于多种并发访问控制算法进行了较验证，如图 4，发现传统的 OCC 算法比很多种知名的改进的 OCC 算法（如知名的 Tictoc、自适应的 OCC 等算法）更有效。这表明，不同人实现的不同的系统尽管采用了一样的算法思路，但是实际效果却大不相同（如 Tictoc 自身的测试结果表明其改进的 OCC 算法效率好于传统的 OCC 算法）。所以，我们在思考，不同实验得到不同的结论，其背后，真的影响分布式事务的效率的因素究竟是什么？

多种并发访问控制算法的比较之一

其实可以发现，不同的研究者的验证结果，是不能互相推证的，他们的验证结果，只能表明算法之间的大致趋势（如 OCC 性能会比 2PL 更好一些）差异，但不能精确表明算法之间的差异点究竟在哪里。

多种并发访问控制算法的比较之二

腾讯在 MySQL 上做了热点更新功能，发现在高并发高竞争同一个数据项的情况下，影响 MySQL 性能的，不是 2PL 这个算法本身，而是为解决死锁问题时死锁检测算法消耗的 CPU 资源，故 MySQL 的事务吞吐量近乎为 0。禁止了死锁检测后，并用系统锁（非事务锁）互斥了在同一个数据项上的并发竞争后，MySQL 系统事务处理吞吐量上升的万倍左右。

真实系统下的真实问题

这说明了，在不同系统下实现的相同算法的结果，只具有参考价值。如果在实际系统中，如 MySQL、PostgreSQL 中做实现，才更有实际参考意义。