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

Abstract

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

Description

面向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)作为高冲突处理节点；所述高冲突状态指很多事务会同时访问一个数据项，引起很多事务回滚；

步骤二：客户端判断高冲突事务：客户端通过事务是否会访问高冲突数据项判断事务是否属于高冲突事务，并发送给步骤一中选定的高冲突处理节点；

步骤三：高冲突处理：选定好高冲突处理节点以后，对高冲突事务进行预先加锁和本地缓存等策略，对高冲突事务进行处理。

步骤一中，所述resolver节点指的是按照访问数据项的范围(range)进行划分，负责检测事务之间冲突的节点。该节点检测事务之间冲突的算法和FoundationDB[9]的一致，记录每个range的写时间戳，如果事务的读集合检测到被其他事务修改，即range的写时间戳大于本事务的提交时间戳，那么该事务就会回滚；所述monitor指的是监控整个集群，即系统中的所有节点，负责时间戳分发等操作的节点。高冲突数据项指的是在一定时间内事务在该数据项上发生冲突的概率较高的数据项。

步骤二中，所述proxy是事务处理节点，负责与客户端交流，同时负责进行高冲突事务处理。高冲突事务，指的是涉及到高冲突数据项的事务。

步骤三中，预先加锁指的是在正常的乐观事务处理流程之外，在选定的高冲突处理proxy节点额外增加了加锁的步骤，事务执行阶段需要先获取相应的锁然后才能获取资源，这一加锁步骤的算法是根据MOCC[11]改进而来(MOCC中的读锁在事务执行阶段就获取，而写锁在事务提交阶段才会获取，死锁提交)，对于高冲突的事务可以做到在执行时就发现冲突并提前abort；本地缓存指的是在高冲突处理节点维护的读取高冲突数据项的缓存。

本发明还基于FoundationDB的论文及代码提供了实现上述方法的系统，系统分为计算层和存储层，计算层包括monitor、resolver、proxy，存储层包括了一个建立在内存上的storage，所述系统主要创新点在于冲突检测模块和高冲突处理模块。

具体地，所述冲突检测模块中包含了根据访问键值范围(key range)划分的resolver节点，所述冲突检测模块会检测系统中的冲突，当冲突大到一定程度时，就会启动收集高冲突的数据项，将一定比率的高冲突数据项发送给monitor节点；

所述高冲突处理模块，会采用预先加锁和本地缓存等方法降低事务执行的延迟，预先加锁通过将回滚事务提前在执行阶段进行回滚，降低了回滚事务的执行时间；而本地缓存则通过减少高冲突数据项的读操作延迟，降低了事务的延迟。这两个手段共同作用，进而提升系统在高冲突负载下的性能。

本发明提出了一种面向shared-nothing架构分布式数据库高冲突事务处理的方法及系统，可以有效地检测系统中出现的高冲突，并针对系统中的高冲突，使用预先加锁和本地缓存等方法来提升系统性能，同时降低回滚事务(abort事务)的延迟。回滚事务指的是最终结果为回滚的事务。

本发明的有益效果包括：相比于现有工作，本发明首次在分布式场景下采用了类似MOCC的提前加锁策略，有效降低了高冲突场景下冲突检测链路的长度，降低abort事务延迟最多达23.98％。同时用本地缓存来减少高冲突数据项的读操作延迟，避免了高冲突数据项频繁RPC对系统性能的影响，在YCSB负载的Zipf参数大于等于0.85的情况下，本地缓存延迟均在通过远程RPC返回的12％以内。使用两个策略以后，系统的吞吐最多提升了84％。

附图说明

图1为本发明高冲突事务处理系统的系统架构图。

图2为本发明中高冲突状态和低冲突状态的状态变化图。

图3为本发明实施例中高冲突处理策略的有效性结果图。

图4为本发明实施例中高冲突检测的有效性结果图。

具体实施方式

结合以下具体实施例和附图，对本发明作进一步的详细说明。实施本发明的过程、条件、实验方法等，除以下专门提及的内容之外，均为本领域的普遍知识和公知常识，本发明没有特别限制内容。

Shared-nothing架构的分布式数据库是为了应对互联网业务的高可扩展性和高可用性诞生的，针对shared-nothing架构分布式数据库存在的冲突检测链路过长的问题，本发明提出了面向shared-nothing架构分布式数据库高冲突事务处理的方法及系统。

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

步骤一：冲突检测：resolver节点检测并发现系统当前处于高冲突状态，然后收集高冲突的数据项集合并发送给monitor节点；

步骤二：客户端判断高冲突事务：客户端判断事务是否属于高冲突事务，并发送给对应的proxy节点；

步骤三：高冲突处理：选定好高冲突处理节点以后，对高冲突事务进行预先加锁和本地缓存等策略。

步骤一中，如图1所示高冲突检测模块从resolver节点处检测高冲突并在一小段时间内，例如1秒，收集高冲突的数据项集合，且仅在回滚率达到一定阈值时，优选阈值为0.05，才会启动记录高冲突的数据项，为了防止假阳性(即实际上只有很少的事务)，记录高冲突的数据项时，对事务载荷(每秒事务数)也进行了一定的限制。在启动高冲突检测以后，resolver节点内的跳表索引就会在进行检测冲突时发送给后台协程当前产生冲突的key，后台协程在收集完毕以后，取占据访问热度一定比率λ的key作为高冲突数据项集合，即

其中，key代表某个访问的数据项，Akey表示一段时间内，例如1秒，某个key的访问次数，λ表示阈值，λ被设置为采样时间内的回滚率(abort_rate)与触发收集高冲突数据项回滚率(hc_abort_rate_threshold)之间的差值，即λ＝abort_rate-hc_abort_rate_threshold。这样设置λ的原因是：第一，随着abort_rate的增加，λ也会增加，这样在冲突更高时，可以确保将高冲突数据项都收集到hot keys中；第二，减去hc_abort_rate_threshold以后，可以避免hot keys中包含一些较低冲突的key，减少对非高冲突负载的影响。hot_keys已经按访问次数从大到小进行排序。resolver节点就会每隔一段时间发送给monitor节点一个高冲突状态请求，里面包含了当前的高冲突数据项集合，直到高冲突现象被消除，为了避免不必要的重复发送，resolver节点会比较每次高冲突数据项集合的变化，如果新增的高冲突数据项在1秒内的访问次数总和大于阈值100，即，就会发送给monitor新的高冲突数据项集合，如果没有，就不发送。

步骤二中，所述的proxy节点是事务处理节点，负责与客户端交流，同时负责进行高冲突事务处理。高冲突事务，指的是涉及到高冲突数据项的事务。

步骤三中，预先加锁的请求锁的方法如算法1所示，事务获取锁的算法如算法2所示。请求锁的流程和MOCC[11]类似，都是提前加锁，读锁在事务执行阶段就获取，而写锁要等到提交阶段才会获取，获取锁时总是按照键值的大小来获取，从而避免了死锁，对于未按顺序获取的锁会释放。本发明通过使用预先加锁，确保了回滚事务可以在执行阶段就发现冲突，从而减短了冲突检测链路。

算法1的priority指锁请求的优先级，max_priority指计算等待者最大优先级，MAX_ALLOWED_WAITERS指最多允许的等待者数量，GRANTED代表返回结果为允许获取，ABORTED代表返回结果为不允许获取。

算法2的violations指不符合加锁顺序的锁的集合，locks.release(violations)指从当前已经获取的锁(locks)中释放不符合加锁顺序的锁(violations)，lock_table.lock(record,request_mode)指按照申请的锁模式(request_mode)来获取对应记录(record)的锁。

本发明与MOCC的主要不同之处在于，如算法1的行11-12所示，本发明的设计里，只允许写者等待读者，而不允许读者等待写者；第二个不同之处是，如算法1的行5-10所示，请求锁时还限制了同一时间允许获取同一记录读锁的数量，以免产生lock thrashing的现象(即由于太多事务等待同一个锁，造成锁等待链路过长，从而引发性能迅速下滑的现象)。如算法2的6-7行所示，第三个不同之处是，MOCC[11]为了解决死锁的问题，会在加锁时，直接释放掉不符合加锁顺序的锁。而在本发明的设计里，仅仅在获取写锁时才会触发这个机制，这是由于读和读之间是不会发生冲突的，而读和写的冲突，由于不允许读者等待写者，只可能是写指向读的；因此，获取新的读锁不会引发死锁，所以，可以在获取读锁时，保留不符合加锁顺序的锁。

在高冲突策略里，高冲突处理proxy节点还可以维护一个本地缓存，在proxy节点缓存所有高冲突数据项。缓存一致性策略是write-through策略(即数据被同步更新到本地缓存和存储节点)。每个缓存都维护一个策略版本(strategy_version)，当高冲突处理节点在尝试读取本地缓存时，可能会发现自己的strategy_version和本地缓存的strategy_version已经不一致，此时，本地缓存就可以被清除。同时，对于已经读取了之前本地缓存，但尚未完成执行或提交的事务，高冲突处理节点会在提交时检查该事务读取本地缓存的strategy_version，如果和自己记录的不一致，事务就会回滚。

算法1

算法2

基本架构

图1中，节点中包含了模块。本系统的基本架构如图1所示，包含了监控节点(monitor)，事务处理节点(proxy)，冲突检测节点(resolver)，存储节点(storage)，这四种节点类型。

其中，monitor节点包含了时间戳发送器(sequencer)和监控模块两个部分，sequencer是用于派发时间戳的模块，当一个事务开始提交时会从sequencer处获取一个提交时间戳，作为提交时检验读写集的时间戳；监控模块则负责在收到高冲突状态申请请求和低冲突状态申请请求以后改变系统的状态

系统的状态变化如图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节点发送请求，改变系统的并发控制策略。

resolver节点除了检测事务之间冲突的功能之外，还包含了高冲突检测模块：包含两个功能，第一是检测并发现目前系统当前处于高冲突状态，第二是收集高冲突的数据项集合。事务被发到proxy节点以后，proxy节点会启动一个协程来服务该事务。而proxy节点除了本身的事务处理功能之外，还包括了高冲突处理模块，高冲突处理模块包含了两个方法：预先加锁和本地缓存。

其中storage节点是基于内存的存储节点，内部维护了5秒钟的多版本数据，5秒之前的数据是无版本的，事务将数据在storage节点完成应用后就完成了提交的流程。

实验结论

实验环境

实验硬件配置：本系统部署在6个节点上，其中3个节点的配置为4vCPU和16GB的内存，CPU型号为Intel Xeon Platinum(Cooper Lake)8369；另外3个节点的配置为4vCPU和8GB，CPU型号为Intel Xeon(Ice Lake)Platinum 8369B。3个存储节点分别部署在3个4vCPU16GB节点上，3个resolver节点均部署在1个4vCPU 8GB的节点上，3个proxy节点和1个monitor节点均部署在1个4vCPU 8GB的节点上，client部署在1个4vCPU 8GB节点上。

测试负载

本实验的测试负载为YCSB，The Yahoo！Cloud Serving Benchmark(YCSB)[12]是一套由互联网公司开发的模拟大规模服务的负载。实验中为对负载进行了改造的YCSB评测标准，在本次实验里使用的事务负载包含10条SQL语句，每个SQL语句有均等的概率为读或者写，所有SQL语句涉及的记录均按照相同的分布产生。在本次实验里，加载了50万条数据，每条数据由包含10个列，每个列的长度为1000。resolver节点和storage节点均按照range均匀分割所有的key。

性能评测

实验一：高冲突处理策略的有效性

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的实验结果则几乎没有差别。

实验二：高冲突检测的有效性

一开始先执行20秒的均匀分布负载，然后在第20至40秒执行Zipf参数为0.99的高冲突负载，最后在40-60秒执行均匀分布负载。

高冲突策略从检测冲突到生效的时延约在3-4秒，在第23秒时预先加锁已经取得了比基线更好的吞吐，而如果额外开启了本地缓存，那么在第24秒时获得了比基线更好的吞吐；而达到稳定吞吐所需的时间为6-7s，预先加锁在第26秒时达到较为2400tps的稳定吞吐，比基线高约20％，而如果额外开启了本地缓存，那么在第27秒时达到了约为2900tps的稳定吞吐，比基线高约45％。通过实验数据可知，本发明能够高效地检测冲突，在检测到冲突以后，可以有效地提升系统在高冲突负载下的性能。

参考文献

[1]Andrew Pavlo and Matthew Aslett.“What’s Really New with NewSQL？”In:SIGMOD Rec.45.2(2016),pp.45–55.doi:10.1145/3003665.3003674.url:https://doi.org/10.1145/3003665.3003674.

[2]Carsten Binnig et al.“The End of Slow Networks:It’s Time for aRedesign”.In:Proc.VLDB Endow.9.7(2016),pp.528–539.doi:10.14778/2904483.2904485.url:http://www.vldb.org/pvldb/vol9/p528-binnig.pdf.

[3]Franz

et al.“The SAP HANA Database–An ArchitectureOverview”.In:IEEE Data Eng.Bull.35.1(2012),pp.28–33.url:http://sites.computer.org/debull/A12mar/hana.pdf.

[4]Robert Kallman et al.“H-store:a high-performance,distributed mainmemory transaction processing system”.In:Proc.VLDB Endow.1.2(2008),pp.1496–1499.doi:10.14778/1454159.1454211.url:http://www.vldb.org/pvldb/vol1/1454211.pdf.

[5]David B.Lomet et al.“Unbundling Transaction Services in theCloud”.In:Fourth Biennial Conference on Innovative Data Systems Research,CIDR2009,Asilomar,CA,USA,January 4-7,2009,Online Proceedings.www.cidrdb.org,2009.url:http://www.db.cs.wisc.edu/cidr/cidr2009/Paper％5C_53.pdf.

[6]Dongxu Huang et al.“TiDB:A Raft-based HTAP Database”.In:Proc.VLDBEndow.13.12(2020),pp.3072–3084.doi:10.14778/3415478.3415535.url:http://www.vldb.org/pvldb/vol13/p3072-huang.pdf.

[7]Rebecca Taft et al.“CockroachDB:The Resilient Geo-Distributed SQLDatabase”.In:Proceedings of the 2020 International Conference on Managementof Data,SIGMOD Conference 2020,online conference[Portland,OR,USA],June 14-19,2020.Ed.by David Maier et al.ACM,2020,pp.1493–1509.doi:10.1145/3318464.3386134.url:https://doi.org/10.1145/3318464.3386134.

[8]James C.Corbett et al.“Spanner:Google’s Globally-DistributedDatabase”.In:10th USENIX Symposium on Operating Systems Design andImplementation,OSDI 2012,Hollywood,CA,USA,October 8-10,2012.Ed.by ChanduThekkath and Amin Vahdat.USENIX Association,2012,pp.251–264.url:https://www.usenix.org/conference/osdi12/technical-sessions/presentation/corbett.

[9]Jingyu Zhou et al.“FoundationDB:A Distributed UnbundledTransactional Key Value Store”.In:SIGMOD’21:International Conference onManagement ofData,Virtual Event,China,June 20-25,2021.Ed.by Guoliang Li etal.ACM,2021,pp.2653–2666.doi:10.1145/3448016.3457559.url:https://doi.org/10.1145/3448016.3457559.

[10]Daniel Peng and Frank Dabek.“Large-scale Incremental ProcessingUsing Distributed Transactions and Notifications”.In:9th USENIX Symposium onOperating Systems Design and Implementation,OSDI 2010,October 4-6,2010,Vancouver,BC,Canada,Proceedings.Ed.by Remzi H.Arpaci-Dusseau and BradChen.USENIX Association,2010,pp.251–264.url:http://www.usenix.org/events/osdi10/tech/full％5C_papers/Peng.pdf.

[11]Tianzheng Wang and Hideaki Kimura.“Mostly-Optimistic ConcurrencyControl for Highly Contended Dynamic Workloads on a Thousand Cores”.In:Proc.VLDB Endow.10.2(2016),pp.49–60.doi:10.14778/3015274.3015276.url:http://www.vldb.org/pvldb/vol10/p49-wang.pdf.

[12]Brian F.Cooper et al.“Benchmarking cloud serving systems withYCSB”.In:Proceedings of the 1st ACM Symposium on Cloud Computing,SoCC 2010,Indianapolis,Indiana,USA,June 10-11,2010.Ed.by Joseph M.Hellerstein,SurajitChaudhuri,and Mendel Rosenblum.ACM,2010,pp.143–154.doi:10.1145/1807128.1807152.url:https://doi.org/10.1145/1807128.1807152.

本发明的保护内容不局限于以上实施例。在不背离本发明构思的精神和范围下，本领域技术人员能够想到的变化和优点都被包括在本发明中，并且以所附的权利要求书为保护范围。

Claims (9)

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和事务的输入输出来判断一个事务是否属于高冲突事务，对于高冲突事务就发送给对应的高冲突处理节点。

6.如权利要求1所述的面向shared-nothing架构分布式数据库高冲突事务处理方法，其特征在于，步骤三中，系统维护了一个全局的策略版本来辨别冲突处理策略的版本，监控节点在收到冲突检测节点发来的高冲突状态请求后，变更内部的strategy_version，随后更新事务处理节点处的strategy_version；客户端在发现自身的strategy_version不对后，向监控节点请求更新自己的strategy_version和对应的冲突处理策略。

7.如权利要求1所述的面向shared-nothing架构分布式数据库高冲突事务处理方法，其特征在于，步骤三中，预先加锁为在正常的执行流程之外，额外增加和预先加锁的流程，在读锁在事务执行阶段就获取，而写锁等到提交阶段才获取，获取锁时总是按照键值的大小来获取，对于未按顺序获取的锁会释放。

8.如权利要求1所述的面向shared-nothing架构分布式数据库高冲突事务处理方法，其特征在于，步骤三中，本地缓存为在事务处理节点维护一个本地缓存，缓存所有的高冲突数据项。

9.一种实现如权利要求1-8之任一项所述方法的系统，其特征在于，所述系统包括冲突检测模块和高冲突处理模块；其中，

所述冲突检测模块，通过回滚率来控制何时收集高冲突数据项，并根据按照负载变化的比率来发送给监控节点高冲突数据项；

所述高冲突处理模块，核心在于用预先加锁和本地缓存两个方法来增加系统的性能。

Images