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

nothing架构分布式数据库高冲突事务处理的方法及系统，其中包括了两个高冲突处理的策略，一是用预先加锁来提前对一些高冲突事务进行回滚，从而减少了冲突检测链路的长度；二是用本地缓存来减少高冲突数据项的读操作延迟，避免了高冲突数据项频繁rpc对性能的影响。7.本发明提出了面向shared-nothing架构分布式数据库高冲突事务处理的方法，包括以下步骤：8.步骤一：冲突检测：冲突检测节点(resolver)通过检测key的冲突率，系统当前处于高冲突状态，然后收集高冲突的数据项集合并发送给监控节点(monitor)，monitor会随机选择一个事务处理节点(proxy)作为高冲突处理节点；所述高冲突状态指很多事务会同时访问一个数据项，引起很多事务回滚；9.步骤二：客户端判断高冲突事务：客户端通过事务是否会访问高冲突数据项判断事务是否属于高冲突事务，并发送给步骤一中选定的高冲突处理节点；10.步骤三：高冲突处理：选定好高冲突处理节点以后，对高冲突事务进行预先加锁和本地缓存等策略，对高冲突事务进行处理。11.步骤一中，所述resolver节点指的是按照访问数据项的范围(range)进行划分，负责检测事务之间冲突的节点。该节点检测事务之间冲突的算法和foundationdb[9]的一致，记录每个range的写时间戳，如果事务的读集合检测到被其他事务修改，即range的写时间戳大于本事务的提交时间戳，那么该事务就会回滚；所述monitor指的是监控整个集群，即系统中的所有节点，负责时间戳分发等操作的节点。高冲突数据项指的是在一定时间内事务在该数据项上发生冲突的概率较高的数据项。[0012]步骤二中，所述proxy是事务处理节点，负责与客户端交流，同时负责进行高冲突事务处理。高冲突事务，指的是涉及到高冲突数据项的事务。[0013]步骤三中，预先加锁指的是在正常的乐观事务处理流程之外，在选定的高冲突处理proxy节点额外增加了加锁的步骤，事务执行阶段需要先获取相应的锁然后才能获取资源，这一加锁步骤的算法是根据mocc[11]改进而来(mocc中的读锁在事务执行阶段就获取，而写锁在事务提交阶段才会获取，死锁提交)，对于高冲突的事务可以做到在执行时就发现冲突并提前abort；本地缓存指的是在高冲突处理节点维护的读取高冲突数据项的缓存。[0014]本发明还基于foundationdb的论文及代码提供了实现上述方法的系统，系统分为计算层和存储层，计算层包括monitor、resolver、proxy，存储层包括了一个建立在内存上的storage，所述系统主要创新点在于冲突检测模块和高冲突处理模块。[0015]具体地，所述冲突检测模块中包含了根据访问键值范围(keyrange)划分的resolver节点，所述冲突检测模块会检测系统中的冲突，当冲突大到一定程度时，就会启动收集高冲突的数据项，将一定比率的高冲突数据项发送给monitor节点；[0016]所述高冲突处理模块，会采用预先加锁和本地缓存等方法降低事务执行的延迟，预先加锁通过将回滚事务提前在执行阶段进行回滚，降低了回滚事务的执行时间；而本地缓存则通过减少高冲突数据项的读操作延迟，降低了事务的延迟。这两个手段共同作用，进而提升系统在高冲突负载下的性能。[0017]本发明提出了一种面向shared-nothing架构分布式数据库高冲突事务处理的方法及系统，可以有效地检测系统中出现的高冲突，并针对系统中的高冲突，使用预先加锁和本地缓存等方法来提升系统性能，同时降低回滚事务(abort事务)的延迟。回滚事务指的是最终结果为回滚的事务。[0018]本发明的有益效果包括：相比于现有工作，本发明首次在分布式场景下采用了类似mocc的提前加锁策略，有效降低了高冲突场景下冲突检测链路的长度，降低abort事务延迟最多达23.98％。同时用本地缓存来减少高冲突数据项的读操作延迟，避免了高冲突数据项频繁rpc对系统性能的影响，在ycsb负载的zipf参数大于等于0.85的情况下，本地缓存延迟均在通过远程rpc返回的12％以内。使用两个策略以后，系统的吞吐最多提升了84％。附图说明[0019]图1为本发明高冲突事务处理系统的系统架构图。[0020]图2为本发明中高冲突状态和低冲突状态的状态变化图。[0021]图3为本发明实施例中高冲突处理策略的有效性结果图。[0022]图4为本发明实施例中高冲突检测的有效性结果图。具体实施方式[0023]结合以下具体实施例和附图，对本发明作进一步的详细说明。实施本发明的过程、条件、实验方法等，除以下专门提及的内容之外，均为本领域的普遍知识和公知常识，本发明没有特别限制内容。[0024]shared-nothing架构的分布式数据库是为了应对互联网业务的高可扩展性和高可用性诞生的，针对shared-nothing架构分布式数据库存在的冲突检测链路过长的问题，本发明提出了面向shared-nothing架构分布式数据库高冲突事务处理的方法及系统。[0025]本发明提出了面向shared-nothing架构分布式数据库高冲突事务处理的方法，包括以下步骤：[0026]步骤一：冲突检测：resolver节点检测并发现系统当前处于高冲突状态，然后收集高冲突的数据项集合并发送给monitor节点；[0027]步骤二：客户端判断高冲突事务：客户端判断事务是否属于高冲突事务，并发送给对应的proxy节点；[0028]步骤三：高冲突处理：选定好高冲突处理节点以后，对高冲突事务进行预先加锁和本地缓存等策略。[0029]步骤一中，如图1所示高冲突检测模块从resolver节点处检测高冲突并在一小段时间内，例如1秒，收集高冲突的数据项集合，且仅在回滚率达到一定阈值时，优选阈值为0.05，才会启动记录高冲突的数据项，为了防止假阳性(即实际上只有很少的事务)，记录高冲突的数据项时，对事务载荷(每秒事务数)也进行了一定的限制。在启动高冲突检测以后，resolver节点内的跳表索引就会在进行检测冲突时发送给后台协程当前产生冲突的key，后台协程在收集完毕以后，取占据访问热度一定比率λ的key作为高冲突数据项集合，即[0030][0031]其中，key代表某个访问的数据项，akey表示一段时间内，例如1秒，某个key的访问次数，λ表示阈值，λ被设置为采样时间内的回滚率(abort_rate)与触发收集高冲突数据项回滚率(hc_abort_rate_threshold)之间的差值，即λ＝abort_rate-hc_abort_rate_threshold。这样设置λ的原因是：第一，随着abort_rate的增加，λ也会增加，这样在冲突更高时，可以确保将高冲突数据项都收集到hotkeys中；第二，减去hc_abort_rate_threshold以后，可以避免hotkeys中包含一些较低冲突的key，减少对非高冲突负载的影响。hot_keys已经按访问次数从大到小进行排序。resolver节点就会每隔一段时间发送给monitor节点一个高冲突状态请求，里面包含了当前的高冲突数据项集合，直到高冲突现象被消除，为了避免不必要的重复发送，resolver节点会比较每次高冲突数据项集合的变化，如果新增的高冲突数据项在1秒内的访问次数总和大于阈值100，即，就会发送给monitor新的高冲突数据项集合，如果没有，就不发送。[0032]步骤二中，所述的proxy节点是事务处理节点，负责与客户端交流，同时负责进行高冲突事务处理。高冲突事务，指的是涉及到高冲突数据项的事务。[0033]步骤三中，预先加锁的请求锁的方法如算法1所示，事务获取锁的算法如算法2所示。请求锁的流程和mocc[11]类似，都是提前加锁，读锁在事务执行阶段就获取，而写锁要等到提交阶段才会获取，获取锁时总是按照键值的大小来获取，从而避免了死锁，对于未按顺序获取的锁会释放。本发明通过使用预先加锁，确保了回滚事务可以在执行阶段就发现冲突，从而减短了冲突检测链路。[0034]算法1的priority指锁请求的优先级，max_priority指计算等待者最大优先级，max_allowed_waiters指最多允许的等待者数量，granted代表返回结果为允许获取，aborted代表返回结果为不允许获取。[0035]算法2的violations指不符合加锁顺序的锁的集合，locks.release(violations)指从当前已经获取的锁(locks)中释放不符合加锁顺序的锁(violations)，lock_table.lock(record,request_mode)指按照申请的锁模式(request_mode)来获取对应记录(record)的锁。[0036]本发明与mocc的主要不同之处在于，如算法1的行11-12所示，本发明的设计里，只允许写者等待读者，而不允许读者等待写者；第二个不同之处是，如算法1的行5-10所示，请求锁时还限制了同一时间允许获取同一记录读锁的数量，以免产生lockthrashing的现象(即由于太多事务等待同一个锁，造成锁等待链路过长，从而引发性能迅速下滑的现象)。如算法2的6-7行所示，第三个不同之处是，mocc[11]为了解决死锁的问题，会在加锁时，直接释放掉不符合加锁顺序的锁。而在本发明的设计里，仅仅在获取写锁时才会触发这个机制，这是由于读和读之间是不会发生冲突的，而读和写的冲突，由于不允许读者等待写者，只可能是写指向读的；因此，获取新的读锁不会引发死锁，所以，可以在获取读锁时，保留不符合加锁顺序的锁。[0037]在高冲突策略里，高冲突处理proxy节点还可以维护一个本地缓存，在proxy节点缓存所有高冲突数据项。缓存一致性策略是write-through策略(即数据被同步更新到本地缓存和存储节点)。每个缓存都维护一个策略版本(strategy_version)，当高冲突处理节点在尝试读取本地缓存时，可能会发现自己的strategy_version和本地缓存的strategy_version已经不一致，此时，本地缓存就可以被清除。同时，对于已经读取了之前本地缓存，但尚未完成执行或提交的事务，高冲突处理节点会在提交时检查该事务读取本地缓存的strategy_version，如果和自己记录的不一致，事务就会回滚。[0038]算法1[0039][0040]算法2[0041][0042]基本架构[0043]图1中，节点中包含了模块。本系统的基本架构如图1所示，包含了监控节点(monitor)，事务处理节点(proxy)，冲突检测节点(resolver)，存储节点(storage)，这四种节点类型。[0044]其中，monitor节点包含了时间戳发送器(sequencer)和监控模块两个部分，sequencer是用于派发时间戳的模块，当一个事务开始提交时会从sequencer处获取一个提交时间戳，作为提交时检验读写集的时间戳；监控模块则负责在收到高冲突状态申请请求和低冲突状态申请请求以后改变系统的状态[0045]系统的状态变化如图2所示，monitor节点在收到resolver节点发来的高冲突状态请求以后，会对内部的策略版本(strategy_version)变量加1，这里的strategy_version是一个全局的变量，系统通过它来标识当前的并发控制是高冲突处理策略还是正常策略。在对内部的strategy_version加1以后，monitor节点会向所有的proxy节点请求更新proxy处的strategy_version，都完成以后，本次的状态就改变完毕。而在客户端也会维护一个strategy_version，当客户端向proxy发送请求时，客户端的strategy_version可能已经过期，这时就需要从monitor处更新strategy_version并获取可能需要的高冲突数据项集合。从高冲突状态变回低冲突状态也是类似的，但是变为从proxy节点发送请求，因为proxy节点可以知道当前有多少个事务是高冲突事务，当连续5秒内高冲突事务均低于每秒1000个，就可以向monitor节点发送请求，改变系统的并发控制策略。[0046]resolver节点除了检测事务之间冲突的功能之外，还包含了高冲突检测模块：包含两个功能，第一是检测并发现目前系统当前处于高冲突状态，第二是收集高冲突的数据项集合。事务被发到proxy节点以后，proxy节点会启动一个协程来服务该事务。而proxy节点除了本身的事务处理功能之外，还包括了高冲突处理模块，高冲突处理模块包含了两个方法：预先加锁和本地缓存。[0047]其中storage节点是基于内存的存储节点，内部维护了5秒钟的多版本数据，5秒之前的数据是无版本的，事务将数据在storage节点完成应用后就完成了提交的流程。[0048]实验结论[0049]实验环境[0050]实验硬件配置：本系统部署在6个节点上，其中3个节点的配置为4vcpu和16gb的内存，cpu型号为intelxeonplatinum(cooperlake)8369；另外3个节点的配置为4vcpu和8gb，cpu型号为intelxeon(icelake)platinum8369b。3个存储节点分别部署在3个4vcpu16gb节点上，3个resolver节点均部署在1个4vcpu8gb的节点上，3个proxy节点和1个monitor节点均部署在1个4vcpu8gb的节点上，client部署在1个4vcpu8gb节点上。[0051]测试负载[0052]本实验的测试负载为ycsb，theyahoo！cloudservingbenchmark(ycsb)[12]是一套由互联网公司开发的模拟大规模服务的负载。实验中为对负载进行了改造的ycsb评测标准，在本次实验里使用的事务负载包含10条sql语句，每个sql语句有均等的概率为读或者写，所有sql语句涉及的记录均按照相同的分布产生。在本次实验里，加载了50万条数据，每条数据由包含10个列，每个列的长度为1000。resolver节点和storage节点均按照range均匀分割所有的key。[0053]性能评测[0054]实验一：高冲突处理策略的有效性[0055]ycsb负载的zipf参数从0.5到1.05之间变化，分别测试启用预先加锁和预先加锁 本地缓存的吞吐变化，采集吞吐稳定后一分钟内的平均值，实验结果如图3所示。ycsb负载的zipf参数从0.5到1.05之间变化，实验结果如图3所示，所有的实验数据均采集为稳定后一分钟的平均值。一般来说，zipf参数大于0.7就可以被认为是高冲突的负载。大于0.7以后的实验结果显示本文设计的高冲突处理策略对吞吐率都有一定的提升，在zipf参数为1.05时，吞吐最多提升了84％；而小于等于0.7的实验结果则几乎没有差别。[0056]实验二：高冲突检测的有效性[0057]一开始先执行20秒的均匀分布负载，然后在第20至40秒执行zipf参数为0.99的高冲突负载，最后在40-60秒执行均匀分布负载。[0058]高冲突策略从检测冲突到生效的时延约在3-4秒，在第23秒时预先加锁已经取得al.acm,2021,pp.2653–2666.doi:10.1145/3448016.3457559.url:https://doi.org/10.1145/3448016.3457559.[0069][10]danielpengandfrankdabek.“large-scaleincrementalprocessingusingdistributedtransactionsandnotifications”.in:9thusenixsymposiumonoperatingsystemsdesignandimplementation,osdi2010,october4-6,2010,vancouver,bc,canada,proceedings.ed.byremzih.arpaci-dusseauandbradchen.usenixassociation,2010,pp.251–264.url:http://www.usenix.org/events/osdi10/tech/full％5c_papers/peng.pdf.[0070][11]tianzhengwangandhideakikimura.“mostly-optimisticconcurrencycontrolforhighlycontendeddynamicworkloadsonathousandcores”.in:proc.vldbendow.10.2(2016),pp.49–60.doi:10.14778/3015274.3015276.url:http://www.vldb.org/pvldb/vol10/p49-wang.pdf.[0071][12]brianf.cooperetal.“benchmarkingcloudservingsystemswithycsb”.in:proceedingsofthe1stacmsymposiumoncloudcomputing,socc2010,indianapolis,indiana,usa,june10-11,2010.ed.byjosephm.hellerstein,surajitchaudhuri,andmendelrosenblum.acm,2010,pp.143–154.doi:10.1145/1807128.1807152.url:https://doi.org/10.1145/1807128.1807152.[0072]本发明的保护内容不局限于以上实施例。在不背离本发明构思的精神和范围下，本领域技术人员能够想到的变化和优点都被包括在本发明中，并且以所附的权利要求书为保护范围。当前第1页12