CN113886403A - 一种针对高竞争电商业务的数据管理系统及事务处理方法 - Google Patents

Abstract

本发明提出了一种数据管理系统，包括输入输出管理模块、执行器模块、事务管理模块、日志管理模块。本发明还提出了一种针对高竞争电商负载的事务处理方法，将工作线程与数据分区绑定，每个线程只需负责自己的分区，过滤掉无效的操作，并将相似操作合并执行，极大地减少了竞争事务之间对数据锁的竞争。

Description

一种针对高竞争电商业务的数据管理系统及事务处理方法

技术领域

本发明涉及数据库系统管理技术领域，尤其涉及针对高竞争电商业务的数据管理系统及事务处理方法。

背景技术

随着电商业务的发展，大量的离线交易被在线交易取代。作为事务处理的关键支柱，数据库管理系统承受的压力越来越大。不同于传统的实体店交易，在线交易打破了空间的限制，数以百万甚至千万的顾客可以在同一时间发起购买请求。根据[6]，阿里巴巴在购物节中每秒要处理的交易高达491,000个。这种业务需要数据库有能力处理高并发的负载。

更加棘手的是，高并发往往来带对数据的高竞争。在促销活动期间，大量的用户会在同一时间读或写相同的存货清单，导致多个事务争相访问相同的数据项，造成高竞争。高竞争的场景会使系统响应时间变长，当一个请求没有获得响应，用户很可能会重复发送请求，进一步增多了无效的负载量，给数据库管理系统带来了更大的压力。

1.并发控制(concurrency control)：并发执行的事务之间的相互影响可能导致数据库状态的不一致，即使各个事务能保持状态的正确性，而且也没有故障发生。因此，不同事务各个步骤的执行顺序必须以某种方式进行规范，该规范是由数据库管理系统的调度器部件完成，而保证并发执行的事务能保持一致性的整个过程成为并发控制。

2.可串行化调度(Serializable Schedules)：如果存在串行调度S’，使得对于每个数据库初态，调度S和S’的效果相同，我们就说这个调度S是可串行化的。

3.两阶段封锁(two-phase locking，2PL)：在每个事务中，所有的封锁请求先于所有的解锁请求。“两阶段”是获得锁的第一阶段和放弃锁的第二阶段。在这种条件下，可以保证一致事务的合法调度是竞争可串行化的。两阶段封锁像一致性一样，是对一个事务中动作的顺序进行限制的条件。服从2PL条件的事务被称为两阶段封锁事务。

4.乐观的并发控制协议(optimistic concurrency control protocol)：在调度事务的操作时假设没有非可串行化行为发生，并且只在违例很明显的时候做恢复。乐观的方法不同于封锁的地方在于，当确实发生问题时唯一的补救措施是中止并重启试图参与非可串行化的事务。

为了更好地处理高竞争负载，本发明给出如下定义：

定义一同质操作(homogeneous operations)：如果操作满足以下三个条件，则它们是同质的：

1)它们是由相同sql模板生成的update操作；

2)它们对属性的更新只涉及增加或减少一个常量；

3)他们访问相同的元组。

定义二存在一个属性a，由于某些约束的存在，a必须属于一个左闭区间。

1)如果一个更新操作O试图将属性a的值减去一个正数，那么O是一个数量限制型更新(CC-Update)；

2)如果一个更新操作O试图将属性a的值加上一个正数，那么O是一个数量补充型更新(CS-Update)；

在上述两种情况下，a都被称为O的约束属性。

现有技术存在的问题：

在当前的数据库管理系统并发控制模块的实现中，乐观的并发控制协议在高竞争的情景中回滚频繁，性能很糟糕[4]；基于锁的并发控制需要频繁地加锁放锁，当并发事务冲突率很高的时候，将会发生严重的锁竞争。即使优化了并发控制协议[13,18]，在相同数据项上的写写冲突也不会有所缓和，这严重减少了事务间的并行性，从而限制了数据库管理系统的吞吐。

近年来，很多工作为提高数据库管理系统处理高度竞争的工作负载时的性能做出了努力。Orthrus[13]提出了两个设计原则。一个是分配专门的线程管理并发控制。每个并发控制线程负责数据库对象的一个不相交子集，以避免数据移动和同步开销。另一个是以一致的顺序向事务授予锁，以避免死锁。MOCC[18]在OCC中引入了锁定机制。当事务访问高温数据时，它需要获取锁。此方法降低了访问热数据事务的回滚率。所有这些技术都没有针对同质操作和无效操作的优化。

多重查询优化(MQO)[15]只执行一次子查询，不计算子查询在OLAP查询中出现的次数。这个方法仅支持在单个查询中共享资源，前提是查询中有多个类似的子查询。MQJoin[7]和CJOIN[2]使用管道共享连接中的资源。但是连接在OLTP工作负载中非常少见。SharedDB[5]和BatchDB[8]考虑OLTP工作负载。SharedDB批处理查询，把它们编成一个大查询计划。不同的查询共享运算符。BatchDB将OLTP副本和OLAP副本分离，OLAP查询之间可以共享资源。以上方法的重点是处理OLAP查询。OLTPShare[12]最接近本发明的方法。OLTP工作负载中的语句被合并以适应高负载场景。然而，OLTPShare只合并单点只读操作，而本发明的工作重点是写。而且，OLTPShare要求被合并的操作必须是其所属事务中的唯一操作。

发明内容

在高竞争电商负载的处理中，写写冲突的解决方案很复杂。在电子商务领域，激烈的竞争主要是因为每一次销售交易都需要减少数据库中采购产品的库存。工业界通常通过构建队列限制流量[10]，从而在服务层拦截请求。此解决方案与特定的业务耦合密切。一旦业务发生变化，服务层代码也会需要修改，这增加了开发人员的负担。

本发明提出了一种针对高竞争电商业务的数据管理系统，包括以下模块：

输入输出管理模块：该模块包含过滤器和分发器；所述过滤器接受客户端发送的操作请求，先经过预处理，参照过滤表对无效操作进行过滤；所述分发器将试图对数据库进行增删改查的sql操作分发给执行器模块，将事务操作包括事务提交、事务回滚、事务开始，分发给事务管理模块；

执行器模块：所述执行器模块由若干个工作线程组成，所述工作线程的具体数量是用户可配置的；每个工作线程只负责自己的数据分区，并维护自己分区的数据锁表；所述执行器模块从存储层中读取数据，将操作的更改记入相应事务的上下文中；

事务管理模块：为事务创建、删除上下文，通知日志管理模块写日志，并将工作线程对记录在事务上下文中的更改写回到存储中；

日志管理模块：接收事务管理模块的写日志请求，将事务的日志写回磁盘。

本发明中，针对高竞争电商业务的数据管理系统，所述过滤器先将操作进行预处理，解析操作的结构，如果发现数量限制型更新，则去过滤表中检查是否具有相应表项，如果有则将该更新过滤掉；如果发现数量补充型更新，则也去过滤表中检查是否具有相应表项，如果有则将该过滤项去掉。

基于以上系统，本发明提出了一种针对高竞争电商业务的事务处理方法，所述方法包括以下步骤：

步骤一：操作的解析、过滤和分发，对操作进行语法解析，根据数据库内部情况判断操作是否有执行成功的可能，将与已经失败过多次的操作过滤掉，将其余操作按照其请求的数据分发给相应的工作线程；

步骤二：执行增删改查操作，执行器为操作加锁，从存储中读数据，并将操作所作更改写到操作所属事务的上下文中，同时将相似的操作合并执行，合并执行的操作只加一把共享写锁；

步骤三：执行事务操作，事务管理模块为事务创建上下文、删除上下文，并代表请求提交的事务发送消息给日志管理器以记录日志；

步骤四：将日志记入磁盘，日志管理模块收到事务管理模块请求写日志的消息后，将缓存中的日志刷入磁盘，并返回日志提交的消息给事务管理模块。

本发明在输入输出管理模块中增加一张过滤表，提前过滤掉注定失败的无效操作。

本发明在执行器模块中对相似的操作进行识别并合并，将相似操作一起执行。

本发明将数据和工作线程进行逻辑上的绑定，每个工作线程只负责自己分区的数据。

本发明输入输出管理模块包含两个模块：过滤器和分发器，过滤器对操作进行预处理，并过滤掉无效操作，向客户端回复结果；分发器根据操作访问的数据，将操作发送给执行器模块中相应的工作线程。

本发明提出的针对高竞争电商负载的事务处理方法，将工作线程与数据分区绑定，每个线程只需负责自己的分区，极大地减少了竞争事务之间对数据锁的竞争。本发明方法包括输入输出管理器模块，其输入是客户端发送的操作请求，其中的预处理器会对操作请求进行解析，判断操作是否有执行成功的可能；如果没有，则直接将操作过滤掉，以免后续给数据管理系统造成多余的压力。随后输入输出管理模块会根据操作试图访问的数据，将该操作分发给相应的工作线程。执行器模块由若干个工作线程构成，每个执行器负责一个指定数据分区的操作访问，并维护相应的数据锁表；为进一步增加操作间的并发性，执行器会将相似的操作合并执行，这些相似操作共享同一把数据写锁。事务管理器的输入是各种事务操作，如事务开始、事务提交、事务回滚，它还负责管理事务上下文，通知日志管理器记日志。日志管理器的输入是事务管理器通知记日志的消息，收到消息后将日志写在磁盘上，并通知事务管理器写日志成功。

参考文献

[1]Philip A.Bernstein,Vassos Hadzilacos,and NathanGoodman.1987.Concurrency Control and Recovery in Database Systems.Addison-Wesley.

[2]George Candea,Neoklis Polyzotis,and RadekVingralek.2011.Predictable performance and high query concurrency for dataanalytics.The VLDB Journal 20,2(2011),227–248.

[3]Giuseppe DeCandia,Deniz Hastorun,Madan Jampani,GunavardhanKakulapati,Avinash Lakshman,Alex Pilchin,Swaminathan Sivasubramanian,PeterVosshall,and Werner Vogels.2007.Dynamo:Amazon’s Highly Available Key-ValueStore.In Proceedings of Twenty-First ACM SIGOPS Symposium on OperatingSystems Principles.205–220.

[4]Jose M.Faleiro and Daniel J.Abadi.2015.Rethinking SerializableMultiversion Concurrency Control.Proceedings of the VLDB Endowment 8,11(2015),1190–1201.

[5]Georgios Giannikis,Gustavo Alonso,and DonaldKossmann.2012.SharedDB:killing one thousand queries with onestone.Proceedings of the VLDB Endowment 5,6(2012),526–537.

[6]Gui Huang,Xuntao Cheng,Jianying Wang,Yujie Wang,Dengcheng He,Tieying Zhang,Feifei Li,Sheng Wang,Wei Cao,and Qiang Li.2019.X-Engine:Anoptimized storage engine for large-scale E-commerce transaction processing.InProceedings of the 2019 International Conference on Management of Data.651–665.

[7]Darko Makreshanski,Georgios Giannikis,Gustavo Alonso,and DonaldKossmann.2016.MQJoin:efcient shared execution of main-memoryjoins.Proceedings of the VLDB Endowment 9,6(2016),480–491.

[8]Darko Makreshanski,Jana Giceva,Claude Barthels,and GustavoAlonso.2017.BatchDB:Efcient Isolated Execution of Hybrid OLTP+OLAP Workloadsfor Interactive Applications.In Proceedings of the 2017 ACM InternationalConference on Management of Data.37–50.

[9]Neha Narula,Cody Cutler,Eddie Kohler,and Robert Morris.2014.Phasereconciliation for contended in-memory transactions.In Proceedings of the11th USENIX conference on Operating Systems Design and Implementation.511–524.

[10]Oracle.2015.Oracle Database 12c:Advanced Queuing Whitepaper.

[11]Ippokratis Pandis,Ryan Johnson,Nikos Hardavellas,and AnastasiaAilamaki.2010.Data-oriented transaction execution.Proceedings of the VLDBEndowment 3,1-2(2010),928–939.

[12]Robin Rehrmann,Carsten Binnig,Alexander

Kihong Kim,WolfgangLehner,and Amr Rizk.2018.Oltpshare:the case for sharing in OLTPworkloads.Proceedings of the VLDB Endowment 11,12(2018),1769–1780.

[13]Kun Ren,Jose M Faleiro,and Daniel J Abadi.2016.Design principlesfor scaling multi-core oltp under high contention.In Proceedings of the 2016International Conference on Management of Data.1583–1598.

[14]Ohad Rodeh.2008.B-trees,shadowing,and clones.ACM Transactions onStorage 3,4(2008),2.

[15]Timos K Sellis.1988.Multiple-query optimization.ACM Transactionson Database Systems(TODS)13,1(1988),23–52.

[16]Michael Stonebraker,Samuel Madden,Daniel J.Abadi,StavrosHarizopoulos,Nabil Hachem,and Pat Helland.2007.The End of an ArchitecturalEra:(It’s Time for a Complete Rewrite).In Proceedings of the 33rdInternational Conference on Very Large Data Bases.1150–1160.

[17]Boyu Tian,Jiamin Huang,Barzan Mozafari,and GrantSchoenebeck.2018.Contention-aware lock scheduling for transactionaldatabases.Proceedings of the VLDB Endowment 11,5(2018),648–662.

[18]Tianzheng Wang and Hideaki Kimura.2016.Mostly-optimisticconcurrency control for highly contended dynamic workloads on a thousandcores.Proceedings of the VLDB Endowment 10,2(2016),49–60.

附图说明

图1为本发明的系统架构。

图2为本发明过滤器的过滤流程。

图3为本发明执行器模块的合并流程。

具体实施方式

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

本发明提出的针对高竞争电商业务的事务处理方法，用于建立、使用和维护数据库，对数据库进行统一的管理和控制，以保护数据库的安全性和完整性；所述方法针对高竞争的电商负载，将数据分区管理，数据分区同工作线程绑定，尽可能早的识别出无效操作并过滤，将相似的操作合并执行，包括以下步骤：

步骤一：输入输出管理模块记录已失败操作的信息，然后基于这些信息，对接下来到达数据管理系统的操作进行过滤。一些操作不会被继续执行，而是直接返回失败。本发明方法节省了那些注定失败的操作消耗的系统资源。

输入输出管理器模块由两个模块组成：过滤器和分发器。

所述过滤器先将操作进行预处理，解析操作的结构，如果发现数量限制型更新，则去过滤表中检查是否具有相应表项，如果有则将该更新过滤掉；如果发现数量补充型更新，则也去过滤表中检查是否具有相应表项，如果有则将该过滤项去掉。

步骤二：步骤一中所述分发器根据操作请求访问的数据，将操作分发给执行器模块中指定的工作线程。

步骤三：执行器模块中的工作线程负责操作的具体执行，从存储器中读取数据，将操作请求的更改记录在相应的事务上下文中。倘若有若干个操作试图对同一数据项进行常数项的加减，执行器会将这些操作合并执行。这些操作不再需要单独锁定数据项，而是共享相同的写锁。这使得操作所属的事务可以并行执行，并且数据项的修改从多次减少到一次。写入的合并大大减少了对相同数据的事务争用。

步骤四：事务管理模块为事务创建上下文、删除上下文，并代表请求提交的事务发送消息给日志管理模块以记录日志；日志管理模块将日志记入磁盘，日志管理模块收到事务管理模块请求写日志的消息，就将缓存中的日志刷入磁盘，并返回日志提交的消息给事务管理模块，最终通知客户端事务完成。

本发明根据所提方法设计并实现了针对高竞争电商业务的数据管理系统，包括以下模块：

输入输出管理模块：该模块包含两部分，过滤器和分发器。过滤器接受客户端发送的操作请求，先经过预处理，参照过滤表对无效操作进行过滤。分发器将试图对数据库进行增删改查的sql操作分发给执行器模块，将事务操作(事务提交、事务回滚、事务开始)分发给事务管理模块。

执行器模块：执行器模块由若干个工作线程组成，工作线程的具体数量是用户可配置的。每个工作线程只需负责自己的数据分区，并维护自己分区的数据锁表。执行器从存储层中读取数据，将操作的更改记入相应事务的上下文中。

事务管理模块：为事务创建、删除上下文，通知日志管理模块写日志，并将工作线程对记录在事务上下文中的更改写回到存储中。

日志管理模块：接收事务管理模块的写日志请求，将事务的日志写回磁盘。

实施例

过滤无效操作旨在减少不必要的系统资源使用。为了更好地实现这个目标，应在输入输出管理器模块(IOM)中进行过滤，因为输入输出管理器模块位于整个系统的入口处。这将最小化无效操作的时间在系统中驻留的时间。在电子商务应用程序中，更新操作最有可能无效的操作。在抢购后的一段时间，尽管货物已售罄，但是，仍然会有很多操作试图减少这个货物的库存。这些更新必然是无效的。为了高效地识别无效操作和节省系统开销，过滤行为只针对数量限制型更新，其定义如定义二中所示。过滤表用来记录无效的更新，以判断后续到来的数量限制型更新是否是有效的。过滤表中的条目是一个三元组：<表名，主键，列号>。如果一个数量限制型更新失败了，它的信息将会被记入过滤表，表名和主键明确该更新试图修改的元组，列号指明该更新修改的具体列。

整个过滤流程如图2所示。如前所述，客户端发送的请求首先到达输入输出管理器模块。在过滤操作前，需要对它进行预处理以得到必要的信息。输入输出管理器模块解析操作，根据谓词获取要访问的元组的主键值。如果定位谓词基于主键，可以轻松完成任务。但是，如果是基于二级索引，需要访问二级索引索引若要获取主键的值。预处理之后，输入输出管理器模块处理操作的方式取决于操作的类型。如果是数量限制型更新或数量补充型更新，则其<表名，主键，列号>将被提取，可能超过一个，用于与过滤表中的条目进行比较。如果他们是发现有交集，分两种情况：

1)对于数量限制型更新，可以确定它是一个无效的操作。输入输出管理器模块过滤操作并直接返回结果给客户。

2)对于数量补充型更新，输入输出管理器模块从过滤表中删除产生交集的条目并将操作分发给执行器。这是因为数量补充型更新可能会使之间失败过的，有相同约束属性的数量限制型更新不再是无效的。

在过滤表中添加新条目是执行器的责任。当一个工作线程发现数量限制型更新由于违反了约束属性上的限制而失败，它会将该操作的信息添加到过滤，为后续的过滤做准备。

合并流程如图3所示。第一步是筛选出可能有同质伙伴的操作，然后，对于每一个操作，将其关键信息缝合成一个字符串，称之为该操作的模式。具有相同模式的操作是同质的，因此它们将放在同一列表中进行合并。模式和列表之间的对应关系记录在模式操作映射表(PO-Map)中。如果一个操作不满足以下两个条件，那就一定没有与之同质的操作：

1)是一个更新操作；

2)定义一中的条件2。

对于这样的操作，不需要计算它的模式，只需给它分配一个唯一的字符串作为它的键，然后把它和它的键一起放入PO-Map中。符合以上两个条件的操作有合并的机会。决定操作属于哪一个同质列表的信息包括：操作访问的表，操作尝试修改的属性和相应的算术运算符，条件谓词中的关系运算符和属性，以及要访问的元组的主键值。根据这些信息，得到一个操作的模式。工作线程会将同质操作set后的表达式合并，如图三中将O1的“set a＝a+1”和O4的“set a＝a+3”合并为“set a＝a+4”.

在执行器模块中，每个工作线程负责数据分区并在本地维护一个PO-Map。到达分发器的操作是预先处理的，也就是说，已经知道要访问的元组。如果一个操作有多个目标元组，分发器将其拆分以确保分发到工作线程的操作不需要访问其他数据分区。每个目标元组对应一个子操作。拆分后，所有操作都是基于主键的单点查询。分发器可以很容易地计算出一个操作的模式。接着，根据主键值，找到对应的工作线程，并将操作放入该工作线程的本地PO-Map内模式对应的列表中。如果PO-Map中没有当前模式，分发器可以为它添加一个新条目。

工作线程一次从PO-Map中取出一个条目并检查列表中的操作数。如果有不止一个操作，可以将它们合并在一起。在执行操作之前需要数据锁。就像传统的写锁一样，合并操作请求的写锁不兼容其他写锁和读锁。但是，合并写入锁由多个事务共享，没有事务被允许重新获得锁，即使有些事务已经占有了锁。这是为了保证事务的可序列化性。另外，如果有列表中只有一个操作，锁定数据并直接执行。在此阶段，所有数据更新都是本地的。在事务提交后更新会被写入到存储中。当事务被执行，它请求的锁和更新被记录在上下文中。合并操作的更新只需要被记录在一个事务的上下文中。这种方法减少了事务操作内存的次数。但是，如果参与合并的事务中有一个发生回滚，则整个合并操作都将无济于事。为了保证事务的原子性，必须回滚所有与之合并的所有事务。所以，所有参与合并的操作的事务号被记录在同一个合并集合(MergeSet)中。只要合并集合中有一个事务回滚，所有其他的事务必须一起回滚。除此之外，在同一个并集合中的事务还必须同时提交，以避免造成集合中有的事务已经提交了，有的事务却要回滚，这样不可恢复的情况。

基本架构

本发明是一个数据管理原型系统，主要关注事务处理模块，不包括存在于完整的数据库系统中的一些功能，如查询优化器。因为现代的主存总是大到可以保存事务处理涉及的所有数据[16]，所以本发明实现为内存数据库。数据总是存储在内存中，不从磁盘加载数据。但为了持久性，构建了一个日志管理器写日志到磁盘。

由于基于乐观的并发控制协议在高竞争的负载下回滚频繁，本发明采用一种悲观协议，两阶段锁定(或2PL)[1]，用于并发控制模型。为了简单起见，实现了单版本2PL，足以证明本发明方法的有效性。

图1展示了本发明的整体架构和工作流程。数据根据主键分区划分为不相交的逻辑分区。每个分区都由不同的工作线程管理，并且每个工作线程都为其负责的数据维护一个本地锁表。

客户端发送的请求首先到达输入输出管理器模块(IOM)。输入输出管理器模块由一个过滤器和一个分发器组成。过滤器在对请求中的操作做一些预处理之后，确定操作是否是有效的。如果这是一个无效的操作，系统将直接向客户端返回“操作失败”。否则，将操作移交给分发器进行进一步的处理。分发器负责两件事。一件是基于要访问的数据将每个普通操作(即增删改查)分发给相应的工作线程。另一件是将事务操作(即事务开始、事务提交或事务中止)传递给事务执行器(TE)。

工作线程获取操作后，首先在本地锁表上锁定要访问的数据。无法获取锁的操作将置于等待队列中，并在释放锁后重新执行。值得一提的是，当线程执行的操作被挂起时，线程不会阻塞，而是直接执行下一个操作。如果操作成功锁定数据，则工作进程将首先从存储中读取所需的数据，然后在其事务上下文中记录更新的结果和使用的锁。本发明的执行策略保证工人可以合并所有已到达的同类操作并将它们一起执行。

事务管理器由两个模块组成：事务执行器和上下文管理器。事务执行器为不同的事务操作选择不同的执行方法。对于一个事务操作，它只需要创建或删除相应事务的上下文。对于事务提交操作，事务执行器通知日志管理器写入日志。日志持久化后，日志管理器向上下文管理器发送提交消息。然后上下文管理器逐个处理消息，将事务上下文中的更新写入存储器。此时，事务实际上已完成。最后，输入输出管理器模块向客户端答复事务已提交。

本发明架构的三个主要部分(即输入输出管理器模块、事务管理器和执行器)中的所有线程都是非阻塞的，减少了内核中上下文切换造成的资源浪费。

实验结论

实验环境

实验硬件配置：本系统部署在一个物理节点上，该节点含有2个CPU，型号为IntelXeon Silver 4110@2.1GHz CPU；内存为120GB；存储为4 TB，RAID-5，7200转的HDD磁盘。物理节点之间使用千兆以太网通信。

性能评测

实验一：加载高竞争的下订单的负载。将商品数量设置为十万个，观察过滤开关打开前后负载成功吞吐与失败吞吐随时间的变化。

时间(秒)	2	4	6	8	10	12
							每秒成功吞吐(开过滤)	14434	17726	13207	5726	0	0
每秒失败吞吐(开过滤)	0	0	0	42450	82883	82208
							每秒成功吞吐(关过滤)	14125	14984	14864	7472	0	0
每秒失败吞吐(关过滤)	0	0	0	18866	47989	46641

通过实验数据可知，当商品卖完后(即第8秒之后)，负载中请求都会失败，此时打开过滤开关会将系统的吞吐量提高近一倍。

实验二：加载高竞争的下订单负载。将商品数量设置的尽可能多。改变执行器中工作线程的个数，观察合并开关打开前后负载吞吐的变化情况。

工作线程数	1	2	3	4	5
						每秒吞吐(开合并)	22026.7	27932.9	31645.6	35714.2	36496.3
每秒吞吐(关合并)	18939.4	21459.2	22935.8	23809.5	25641.0

通过实验数据可知，在打开合并功能的情况下，系统的吞吐和可扩展性明显变好。

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

Claims (7)

1.一种针对高竞争电商业务的数据管理系统，其特征在于，包括以下模块：

输入输出管理模块：该模块包含过滤器和分发器；所述过滤器接受客户端发送的操作请求，先经过预处理，参照过滤表对无效操作进行过滤；所述分发器将试图对数据库进行增删改查的sql操作分发给执行器模块，将事务操作包括事务提交、事务回滚、事务开始，分发给事务管理模块；

执行器模块：所述执行器模块由若干个工作线程组成，所述工作线程的具体数量是用户可配置的；每个工作线程只负责自己的数据分区，并维护自己分区的数据锁表；所述执行器模块从存储层中读取数据，将操作的更改记入相应事务的上下文中；

事务管理模块：为事务创建、删除上下文，通知日志管理模块写日志，并将工作线程对记录在事务上下文中的更改写回到存储中；

日志管理模块：接收事务管理模块的写日志请求，将事务的日志写回磁盘。

2.如权利要求1所述的针对高竞争电商业务的数据管理系统，其特征在于，所述过滤器先将操作进行预处理，解析操作的结构，如果发现数量限制型更新，则去过滤表中检查是否具有相应表项，如果有则将该更新过滤掉；如果发现数量补充型更新，则也去过滤表中检查是否具有相应表项，如果有则将该过滤项去掉。

3.一种针对高竞争电商业务的事务处理方法，其特征在于，采用如权利要求1或2所述的系统，所述方法包括以下步骤：

步骤一：操作的解析、过滤和分发，对操作进行语法解析，根据数据库内部情况判断操作是否有执行成功的可能，将与已经失败过多次的操作过滤掉，将其余操作按照其请求的数据分发给相应的工作线程；

步骤二：执行增删改查操作，执行器为操作加锁，从存储中读数据，并将操作所作更改写到操作所属事务的上下文中，同时将相似的操作合并执行，合并执行的操作只加一把共享写锁；

步骤三：执行事务操作，事务管理模块为事务创建上下文、删除上下文，并代表请求提交的事务发送消息给日志管理器以记录日志；

步骤四：将日志记入磁盘，日志管理模块收到事务管理模块请求写日志的消息后，将缓存中的日志刷入磁盘，并返回日志提交的消息给事务管理模块。

4.根据权利要求3所述的针对高竞争电商业务的事务处理方法，其特征在于，在输入输出管理模块中增加一张过滤表，提前过滤掉注定失败的无效操作。

5.根据权利要求3所述的针对高竞争电商业务的事务处理方法，其特征在于，在执行器模块中对相似的操作进行识别并合并，将相似操作一起执行。

6.根据权利要求3所述的针对高竞争电商业务的事务处理方法，其特征在于，将数据和工作线程进行逻辑上的绑定，每个工作线程只负责自己分区的数据。

7.根据权利要求3所述的针对高竞争电商业务的事务处理方法，其特征在于，输入输出管理模块包含两个模块：过滤器和分发器，过滤器对操作进行预处理，并过滤掉无效操作，向客户端回复结果；分发器根据操作访问的数据，将操作发送给执行器中相应的工作线程。

Images