面向shared-nothing架构分布式数据库高冲突事务处理方法及系统技术方案

本发明专利技术公开了一种面向shared

【技术实现步骤摘要】
面向shared
‑
nothing架构分布式数据库高冲突事务处理方法及系统


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

技术介绍

[0002]自2000年以来，随着互联网的快速发展，各类应用的规模不断增长，对应用的持续在线能力提出了更高的要求。而作为互联网应用的重要组成部分，这一现状也就对数据库的可扩展性和高可用性提出了更高的要求[1]。传统的单机关系型数据库不再适用于这个场景，为了应对可扩展性与高可用性的挑战，分布式数据库应运而生。
[0003]从NoSQL到NewSQL[1]，分布式数据库取得了长足的进展，在解决事务一致性和可扩展性上都有很大的进步，但是还存在着一些还未解决的挑战，在参考文献[2]中提到，当前分布式数据库的吞吐主要被三个因素限制：(1)消息传递的额外开支；(2)网络的带宽；(3)资源竞争。随着网络技术的快速发展，实际上前面两个问题已经得到了很大的缓解。而分布式场景下，消息延迟被大大增加。举例来说，以太网中单次小消息传递的代价约为35μs，不考虑磁盘和网络延迟的情况下，事务的延迟约为10
‑
60μs[3,4]，网络延迟已经成了短事务延迟的主要瓶颈，而短事务又是联机事务处理(Online Transactional Processing,OLTP)的主要类型。消息延迟的增加恶化了分布式数据库的冲突，已经有研究指出，事务的冲突概率和访问单个记录的延迟成指数级关系[2]。
[0004]对于目前流行的shared
‑
nothing架构而言，在逻辑上，往往有一个无状态的Transaction Component层用于计算和一个Data Component层用于存储数据和事务状态[5]，如TiDB[6]，CockroachDB[7]，Spanner[8]，FoundationDB[9]等。这样的架构，在高冲突的场景下，可能由于检测冲突的时间太长而导致冲突升高，进而降低吞吐。举例来说，对于乐观的并发控制协议如Percolator[10]来说，事务在提交和读取数据时需要在存储层检测冲突，而在那之前事务可能已经进行了多次网络I/O，这样就造成，实际发生冲突的时间和检测到冲突的时间被拉长。
[0005]综上所述，目前shared
‑
nothing架构的分布式数据库普遍存在着在高冲突负载下的性能问题，高冲突负载对其性能的影响不容忽视。

技术实现思路

[0006]Shared
‑
nothing架构的分布式数据库是为了应对互联网业务的高可扩展性和高可用性诞生的，其架构设计上，一般会有一个无状态的Transaction Component层用于计算和一个Data Component层用于存储数据和事务状态，每次的冲突检测和数据访问都会有网络的开销。因此会有冲突检测链路过长的问题，针对这一问题，本专利技术提出了面向shared
‑
nothing架构分布式数据库高冲突事务处理的方法及系统，其中包括了两个高冲突处理的策略，一是用预先加锁来提前对一些高冲突事务进行回滚，从而减少了冲突检测链路的长度；二是用本地缓存来减少高冲突数据项的读操作延迟，避免了高冲突数据项频繁RPC对性能的影响。
[0007]本专利技术提出了面向shared
‑
nothing架构分布式数据库高冲突事务处理的方法，包括以下步骤：
[0008]步骤一：冲突检测：冲突检测节点(resolver)通过检测key的冲突率，系统当前处于高冲突状态，然后收集高冲突的数据项集合并发送给监控节点(monitor)，monitor会随机选择一个事务处理节点(proxy)作为高冲突处理节点；所述高冲突状态指很多事务会同时访问一个数据项，引起很多事务回滚；
[0009]步骤二：客户端判断高冲突事务：客户端通过事务是否会访问高冲突数据项判断事务是否属于高冲突事务，并发送给步骤一中选定的高冲突处理节点；
[0010]步骤三：高冲突处理：选定好高冲突处理节点以后，对高冲突事务进行预先加锁和本地缓存等策略，对高冲突事务进行处理。
[0011]步骤一中，所述resolver节点指的是按照访问数据项的范围(range)进行划分，负责检测事务之间冲突的节点。该节点检测事务之间冲突的算法和FoundationDB[9]的一致，记录每个range的写时间戳，如果事务的读集合检测到被其他事务修改，即range的写时间戳大于本事务的提交时间戳，那么该事务就会回滚；所述monitor指的是监控整个集群，即系统中的所有节点，负责时间戳分发等操作的节点。高冲突数据项指的是在一定时间内事务在该数据项上发生冲突的概率较高的数据项。
[0012]步骤二中，所述proxy是事务处理节点，负责与客户端交流，同时负责进行高冲突事务处理。高冲突事务，指的是涉及到高冲突数据项的事务。
[0013]步骤三中，预先加锁指的是在正常的乐观事务处理流程之外，在选定的高冲突处理proxy节点额外增加了加锁的步骤，事务执行阶段需要先获取相应的锁然后才能获取资源，这一加锁步骤的算法是根据MOCC[11]改进而来(MOCC中的读锁在事务执行阶段就获取，而写锁在事务提交阶段才会获取，死锁提交)，对于高冲突的事务可以做到在执行时就发现冲突并提前abort；本地缓存指的是在高冲突处理节点维护的读取高冲突数据项的缓存。
[0014]本专利技术还基于FoundationDB的论文及代码提供了实现上述方法的系统，系统分为计算层和存储层，计算层包括monitor、resolver、proxy，存储层包括了一个建立在内存上的storage，所述系统主要创新点在于冲突检测模块和高冲突处理模块。
[0015]具体地，所述冲突检测模块中包含了根据访问键值范围(key range)划分的resolver节点，所述冲突检测模块会检测系统中的冲突，当冲突大到一定程度时，就会启动收集高冲突的数据项，将一定比率的高冲突数据项发送给monitor节点；
[0016]所述高冲突处理模块，会采用预先加锁和本地缓存等方法降低事务执行的延迟，预先加锁通过将回滚事务提前在执行阶段进行回滚，降低了回滚事务的执行时间；而本地缓存则通过减少高冲突数据项的读操作延迟，降低了事务的延迟。这两个手段共同作用，进而提升系统在高冲突负载下的性能。
[0017]本专利技术提出了一种面向shared
‑
nothing架构分布式数据库高冲突事务处理的方法及系统，可以有效地检测系统中出现的高冲突，并针对系统中的高冲突，使用预先加锁和
本地缓存等方法来提升系统性能，同时降低回滚事务(abort事务)的本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种面向shared
‑
nothing架构分布式数据库高冲突事务处理方法，其特征在于，包括以下步骤:步骤一：冲突检测节点通过检测key的冲突率，若检测发现系统当前处于高冲突状态，收集高冲突的数据项集合并发送给监控节点；步骤二：客户端判断事务是否属于高冲突事务，并发送给步骤一中选定的高冲突处理节点；步骤三：选定好高冲突处理节点以后，对高冲突事务进行预先加锁和本地缓存进行处理。2.如权利要求1所述的面向shared
‑
nothing架构分布式数据库高冲突事务处理方法，其特征在于，步骤一中，在冲突检测节点对每个检测冲突节点的abort率进行检测，当abort率高于阈值时，启动记录高冲突数据项。3.如权利要求2所述的面向shared
‑
nothing架构分布式数据库高冲突事务处理方法，其特征在于，所述阈值设定为0.05。4.如权利要求1所述的面向shared
‑
nothing架构分布式数据库高冲突事务处理方法，其特征在于，步骤一中，对高冲突数据项的集合，取一定比率的数据项来发送给监控节点，即其中，key代表某个访问的数据项，Akey表示一段时间内某个key的访问次数，λ表示阈值，λ被设置为采样时间内的回滚率与触发收集高冲突数据项回滚率之间的差值，即λ＝采样时间内的回滚率
‑
触发收集高冲突数据项回滚率。5.如权利要求1所述的面向shared
‑
nothing架构分布式数据库高冲突事务处理方法，其特征在于，步骤二中，客户端根据事务ID和事务的输入输出来判断...

【专利技术属性】
技术研发人员：连薛超，倪葎，张蓉，
申请(专利权)人：华东师范大学，
类型：发明
国别省市：