[发明专利]面向shared-nothing架构分布式数据库高冲突事务处理方法及系统

说明书

本发明公开了一种面向shared‑nothing架构分布式数据库高冲突事务处理方法，实现了原型系统，可以有效地检测分布式数据库中存在的高冲突负载，并启动对应的高冲突处理策略，从而达到提升分布式数据库系统在高冲突负载下性能的目的。本发明还提出了一种面向shared‑nothing架构分布式数据库高冲突事务处理系统。

技术领域

本发明属于shared-nothing架构(每个处理单元都有单独的CPU/内存/硬盘，不存在共享资源，各处理单元之间通过协议通信)的分布式数据库、并发控制技术领域，涉及一种面向shared-nothing架构分布式数据库高冲突事务处理方法及系统，用于高冲突情况下的分布式事务处理。

背景技术

自2000年以来，随着互联网的快速发展，各类应用的规模不断增长，对应用的持续在线能力提出了更高的要求。而作为互联网应用的重要组成部分，这一现状也就对数据库的可扩展性和高可用性提出了更高的要求[1]。传统的单机关系型数据库不再适用于这个场景，为了应对可扩展性与高可用性的挑战，分布式数据库应运而生。

从NoSQL到NewSQL[1]，分布式数据库取得了长足的进展，在解决事务一致性和可扩展性上都有很大的进步，但是还存在着一些还未解决的挑战，在参考文献[2]中提到，当前分布式数据库的吞吐主要被三个因素限制：(1)消息传递的额外开支；(2)网络的带宽；(3)资源竞争。随着网络技术的快速发展，实际上前面两个问题已经得到了很大的缓解。而分布式场景下，消息延迟被大大增加。举例来说，以太网中单次小消息传递的代价约为35μs，不考虑磁盘和网络延迟的情况下，事务的延迟约为10-60μs[3,4]，网络延迟已经成了短事务延迟的主要瓶颈，而短事务又是联机事务处理(Online Transactional Processing,OLTP)的主要类型。消息延迟的增加恶化了分布式数据库的冲突，已经有研究指出，事务的冲突概率和访问单个记录的延迟成指数级关系[2]。

对于目前流行的shared-nothing架构而言，在逻辑上，往往有一个无状态的Transaction Component层用于计算和一个Data Component层用于存储数据和事务状态[5]，如TiDB[6]，CockroachDB[7]，Spanner[8]，FoundationDB[9]等。这样的架构，在高冲突的场景下，可能由于检测冲突的时间太长而导致冲突升高，进而降低吞吐。举例来说，对于乐观的并发控制协议如Percolator[10]来说，事务在提交和读取数据时需要在存储层检测冲突，而在那之前事务可能已经进行了多次网络I/O，这样就造成，实际发生冲突的时间和检测到冲突的时间被拉长。

综上所述，目前shared-nothing架构的分布式数据库普遍存在着在高冲突负载下的性能问题，高冲突负载对其性能的影响不容忽视。

发明内容

Shared-nothing架构的分布式数据库是为了应对互联网业务的高可扩展性和高可用性诞生的，其架构设计上，一般会有一个无状态的Transaction Component层用于计算和一个Data Component层用于存储数据和事务状态，每次的冲突检测和数据访问都会有网络的开销。因此会有冲突检测链路过长的问题，针对这一问题，本发明提出了面向shared-nothing架构分布式数据库高冲突事务处理的方法及系统，其中包括了两个高冲突处理的策略，一是用预先加锁来提前对一些高冲突事务进行回滚，从而减少了冲突检测链路的长度；二是用本地缓存来减少高冲突数据项的读操作延迟，避免了高冲突数据项频繁RPC对性能的影响。

本发明提出了面向shared-nothing架构分布式数据库高冲突事务处理的方法，包括以下步骤：

步骤一：冲突检测：冲突检测节点(resolver)通过检测key的冲突率，系统当前处于高冲突状态，然后收集高冲突的数据项集合并发送给监控节点(monitor)，monitor会随机选择一个事务处理节点(proxy)作为高冲突处理节点；所述高冲突状态指很多事务会同时访问一个数据项，引起很多事务回滚；