CN106354732B - 一种支持并发协同的离线数据版本冲突解决方法 - Google Patents

Abstract

本发明提供了一种支持并发协同的离线数据版本冲突解决方法，该方法包括：接收来对数据库进行编辑的编辑请求；根据应用层的冲突出现概率采取相应的冲突解决方法来判断所述编辑请求是否存在冲突，并在确定没有冲突后根据所述编辑请求对所述数据库进行处理。当冲突发生频率较低时，本发明采取基于混合冲突检测的方式，这种混合式冲突检测方式可以有效缩短冲突检测的时间。当冲突发生频率较高时，本发明采取基于冲突避免的方式，写数据的用户需要首先获取相关表的编辑标签，这既避免了冲突，还支持离线应用的其他用户并发操作软件的其他模块。

Description

一种支持并发协同的离线数据版本冲突解决方法

技术领域

本发明属于计算机技术的软件开发领域，具体涉及一种支持并发协同的离线数据版本冲突解决方法。

背景技术

随着信息技术的飞速发展，多人并发操作模式已经被越来越多的软件所支持。并发是指允许多用户对同一数据进行访问和更改，而冲突是并发操作时一种常见的数据不一致现象。采用串行方式可以避免冲突，但对于冲突发生频率低的应用，串行执行程序又牺牲了太多效率。因此如何解决并发所带来的版本冲突问题、效率问题，日益成为软件开发领域研究的热点课题。处理并发问题有两个层面：数据库层和应用层。

现有的商业数据库普遍支持基于事务的并发。事务是用户定义的一个数据库操作序列，这些操作要么全部都做，要么全部都不做，是一个不可分割的工作单元。当多个事务并发执行的时候，需要避免丢失修改、不可重复读、读脏数据等数据不一致和数据冲突问题。主流数据库通过设置隔离级别，可以解决事务并发中的冲突问题和效率问题。

对于应用层的并发控制，主要有冲突避免和冲突检测两种方案。冲突避免，也称为悲观冲突解决方案，它是在可能存在并发冲突的情况下，通过同一时间只允许一个用户进行编辑的方式规避冲突，常见的形式是给数据库表上锁。冲突检测，也称为乐观冲突解决方案，它是在已经发生了冲突的情况下，对冲突进行检测，并通知用户冲突的发生，通常使用时间戳技术实现。

发明内容

然而，数据库虽然支持事务的并发，但并不能解决事务之上应用层的并发问题。而且，给数据库表上锁的冲突避免方式适合在线模式的应用，即每次需要操作数据的时候才从数据库读取数据，但对于离线模式的应用，即软件先读取数据库，加载相关的内容，再在离线状态下更改数据，最后提交到数据库应用，给数据库表直接上锁，会导致同一时间只有一个用户可以使用软件，软件失去了并发性。对于传统冲突检测模式，当数据表的记录数非常多的时候，每次判断内存时间戳和数据库时间戳是否一致，牺牲了效率。

因此，本发明提供了一种灵活性更强，效率更高，适应离线并发应用的支持并发协同的离线数据版本冲突解决方法。

为了解决上述技术问题，本申请的实施例首先提供了一种支持并发协同的离线数据版本冲突解决方法，该方法包括：接收来对数据库进行编辑的编辑请求；根据应用层的冲突出现概率采取相应的冲突解决方法来判断所述编辑请求是否存在冲突，并在确定没有冲突后根据所述编辑请求对所述数据库进行处理。

优选地，在应用层的冲突出现概率低时，判断所述编辑请求是否存在集控式冲突，其中，所述集控式冲突是一种表粒度级别的冲突，若不存在所述集控式冲突，则根据所述编辑请求对所述数据库进行处理；若存在所述集控式冲突，则进一步判断所述编辑请求是否存在分散式冲突，其中，所述分散式冲突是一种记录粒度级别的冲突，若存在所述分散式冲突，则判断所述编辑请求存在冲突；若不存在所述分散式冲突，则根据所述编辑请求对所述数据库进行处理。

优选地，在判断所述编辑请求是否存在集控式冲突的步骤中，根据所述编辑请求确定对应的表在数据库的时间戳和数据库操作类型，所述数据库操作类型包括插入操作、更新操作和删除操作；根据所述数据库操作类型判断是否需要判断冲突；其中，若需要判断冲突，则判断表在数据库的时间戳与该表在内存中的时间戳是否一致，若不一致则判断存在集控式冲突。

优选地，在根据所述数据库操作类型判断是否需要判断冲突的步骤中，在两方编辑请求中，若其中一方编辑请求中的数据库操作类型为插入操作，则无需判断是否冲突；否则需要判断是否发生冲突。

优选地，在判断所述编辑请求是否存在分散式冲突的步骤中，根据所述编辑请求确定对应的记录在数据库的时间戳和在内存的时间戳；判断该记录在数据库的时间戳和在内存的时间戳是否一致，若不一致则判断存在分散式冲突。

优选地，在应用层的冲突出现概率高时，对所述编辑请求对应的数据库进行锁定，若锁定成功则根据所述编辑请求对所述数据库进行处理，否则判断所述编辑请求存在冲突。

优选地，若请求为数据库查询请求时，则判断缓存中是否存储有相应的数据库查询结果，如果有则获取所述数据库查询结果，否则通过查询相应的数据库来获取数据库查询结果，其中，将数据库历史的查询语句和查询结果相关联地存储在所述缓存中。

优选地，在判断缓存中是否存储有相应的数据库查询结果的步骤中，根据数据库历史的查询语句判断所述缓存中是否存在相应的数据库的表名，若存在则判断该表名是否被标记过期，若该表名未被标记过期则获取与之对应的数据库查询结果。

优选地，若该表名被标记过期，则将通过查询相应的数据库来获取的数据库查询结果发送至所述缓存中用来更新过期的数据库查询结果，并取消过期标记。

与现有技术相比，上述方案中的一个或多个实施例可以具有如下优点或有益效果。

本发明提出了一套应用层数据版本冲突的解决方法，当冲突出现概率较低时，采取基于混合冲突检测的方法，SQL请求首先进行集控式冲突检测，之后进行分散式冲突检测，当数据表记录数很多时，前者的检测效率明显优于后者，因此这种混合式冲突检测方式可以有效缩短冲突检测的时间；当冲突出现概率较高时，采取基于冲突避免的方式，写数据的用户需要首先获取相关表的编辑标签，这既避免了冲突，还支持离线应用的其他用户并发操作软件的其他模块。

此外，本发明还提供了一套缓存机制，避免不必要的数据库查询，提高查询请求处理效率。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明的技术方案而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构和/或流程来实现和获得。

附图说明

附图用来提供对本申请的技术方案或现有技术的进一步理解，并且构成说明书的一部分。其中，表达本申请实施例的附图与本申请的实施例一起用于解释本申请的技术方案，但并不构成对本申请技术方案的限制。

图1为本申请实施例的支持并发协同的离线数据版本冲突解决方法的流程示意图。

图2为本申请实施例的支持并发协同的离线数据版本冲突解决方法的另一流程示意图。

具体实施方式

以下将结合附图及实施例来详细说明本发明的实施方式，借此对本发明如何应用技术手段来解决技术问题，并达成相应技术效果的实现过程能充分理解并据以实施。本申请实施例以及实施例中的各个特征，在不相冲突前提下可以相互结合，所形成的技术方案均在本发明的保护范围之内。

另外，附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本发明提出了一种支持并发协同的数据版本冲突的解决方法，数据库服务器接收来自客户端的对数据库进行编辑的编辑请求，数据库服务器根据应用层的冲突出现概率采取相应的冲突解决方法来判断编辑请求是否存在冲突，并在确定没有冲突后根据编辑请求对所述数据库进行处理。具体来说，对于并发程度不高，冲突出现概率较低的应用层，比如中小企业内部使用的企业级应用使用基于冲突检测的数据版本冲突解决方法。对于并发程度高，冲突出现概率较高的应用层，比如海量用户的互联网应用使用基于冲突避免的数据版本冲突解决方法。并且，在这两个方案中都使用了缓冲服务器来提高查询效率。

本领域技术人员根据需要可以设定应用层冲突出现概率的高低，进而选择相应的方案，对于冲突出现概率的高低的判断，本发明对此不作限定。

图1为本申请实施例的支持并发协同的离线数据版本冲突解决方法的流程示意图，该实施例的冲突解决方法是基于冲突检测的数据版本冲突解决方法。概括来说，对于数据库的查询请求需要首先访问缓存服务器，减少数据库访问次数；对于数据库的编辑请求(例如删除和更新请求)，数据库服务器(后称“DB服务器”)需要进行混合式冲突判断。

如图1所示，客户端要进行数据库的查询时，首先发送数据库查询请求至缓存服务器中，缓存服务器判断其内部是否存储有相应的数据库查询结果(即，是否被击中)，如果有则直接返回给客户端该数据库查询结果，其中，该缓存服务器相关联地存储了数据库历史的查询语句和查询结果。具体地，根据数据库历史的查询语句判断缓存中是否存在相应的数据库的表名，若存在则判断该表名是否被标记过期，若该表名未被标记过期则获取与之对应的数据库查询结果。

另一方面，如果缓存没被击中则通过数据库服务器查询相应的数据库来获取数据库查询结果，也就是说，如果缓存服务器没有被击中，则客户端将数据库查询请求发送到DB服务器中，DB服务器根据数据库查询请求到数据库中执行SQL语句，最终返回查询结果给客户端。

对于例如删除数据库的请求和更新数据库的请求这种编辑请求，客户端直接将编辑请求发送到DB服务器中，DB服务器首先判断编辑请求是否存在后述的集控式冲突，如果不存在集控式冲突，则可以根据编辑请求对数据库进行处理，即在数据库中执行该编辑请求。相反地，如果存在集控式冲突，则DB服务器进一步这些编辑请求是否存在后述的分散式冲突，如果不存在分散式冲突，则根据编辑请求对数据库进行处理，如果存在分散式冲突，则通知客户端发生并发冲突，库表已经被其他用户修改。最后，客户端执行刷新内存的操作，并在操作后重新提交请求。

图2为本申请实施例的支持并发协同的离线数据版本冲突解决方法的另一流程示意图，该冲突解决方法是基于冲突避免的数据版本冲突解决方法。概括来说，对于数据库查询请求需要首先访问缓存服务器，减少数据库访问次数；对于删除和更新数据库请求，在发送请求前，需要首先向DB服务器发送加锁请求，加锁成功后才能继续操作。

如图2所示，对于数据库查询请求的处理与基于冲突检测的方法类似，这里不再赘述。

对于删除和更新数据库请求的编辑请求，在发送请求前，客户端需要首先向DB服务器发送加锁请求，DB服务器访问lock_table表，对编辑请求对应的数据库进行锁定，如果锁定失败则判断编辑请求存在冲突，通知客户端目前数据库正在被其他用户编辑。如果锁定成功，客户端可以开始发送删除和更新数据库的请求给DB服务器，并根据DB服务器的处理来获取操作结果。在完成所有的删除和更改操作后，客户端释放对相关数据库表的锁。

下面就上述实施例涉及的核心逻辑分别进行说明，主要包括数据缓存方案，混合型冲突检测方案和冲突避免方案。

(1)数据缓存方案用于提高并发应用的效率。

本实施例中设置的缓存服务器负责对数据库历史的查询语句及查询结果相关联地进行存储，由于它存储在内存中，因此相比直接进行数据库访问来说，使用缓存的时间效率更高。

缓存的物理结构是一个Map(以键值为存储单元的字典结构)。Map的存储单元是键值对，它是一种支持根据键快速定位值的数据结构。Map的底层实现根据语言不同而不同，c++一般采用树，java一般采用哈希。缓冲的Map定义如下：CacheMap<表名，DetailMap<SQL语句，查询结果>>，它是一个二级Map，给定SQL语句可以快速确定缓存中是否存在该SQL语句的查询结果。

当数据库发生改变后，需要对缓存进行更新，本发明设计了一种基于CacheMap的延时更新策略。延时更新策略并不在数据库发生改变时立刻更新缓存，而是当下一次的读请求到达时，才更新缓存，这样可以避免不必要的更新，降低缓存服务器的负荷。

延时策略的描述如下：数据库服务器接收到插入(Insert)、更新(Update)和删除(Delete)请求后，从SQL语句中提取表名，并在本地标记该表为过期，同时利用远程过程调用(RPC)通知缓存服务器该表过期，此时CacheMap并没有更新，数据库和缓存信息可能不一致。当以后选择(Select)该表的请求到来，缓存中由于该表已经被标记为过期，所以提示未击中，服务器执行选择(Select)请求后，检查到该表被标记为过期，将通过查询相应的数据库来获取的数据库查询结果发送到缓存服务器中用来更新缓存。同时取消该表在本地过期标记。缓存服务器收到数据库服务器传过来的查询结果后，根据表名和SQL语句更新自己的CacheMap，同时取消该表的过期标记。

(2)混合型冲突检测方案用于对应用层数据库并发操作所引发的冲突的检测，它由两部分组成：集控式冲突检测和分散式冲突检测。

集控式冲突检测是一种表粒度级别的冲突检测方法，它使用数据库中全局的版本表，来判断用户新提交的数据是否存在版本冲突。表粒度级别的冲突是指用户A和用户B同时对同一个表进行了更改，则提交的时候会显示表粒度冲突。当用户A和用户B更改的是同一个表的不同记录时，事实上是不存在冲突的，因此集控式版本只是粗粒度的冲突判断，如果集控式显示不存在冲突，则用户提交肯定不存在冲突，但当集控式显示存在冲突，需要进一步在分散式策略中进行冲突检测，如果不存在冲突，则用户依然可以提交成功。

集控式冲突检测具体通过如下方式进行：根据编辑请求确定对应的表在数据库的时间戳和数据库操作类型，所述数据库操作类型包括插入操作、更新操作和删除操作。然后，根据数据库操作类型判断是否需要判断冲突，其中，若需要判断冲突，则判断表在数据库的时间戳与该表在内存中的时间戳是否一致，若不一致则判断存在集控式冲突。

集控式冲突检测的算法描述如下：

1在数据库层中新增版本表version_table，如表1所示的集控式版本表version_table结构。

表1

2应用层，建立与数据库表version_table对应的结构体VersionTable，并在程序开始时，对VersionTable进行加载；

3每当执行SQL语句前，首先调用IsCentralizedCollision()函数，判断所涉及表的内存版本号是否和数据库中的最新时间戳一致，不一致则返回存在冲突；

4如果时间戳一致，说明不存在冲突，同时更新数据库版本表version_table的数据和内存结构体VersionTable的数据。

其中，IsCentralizedCollision()函数是判断是否存在集控式冲突的核心函数，它的输入包括表名T1和输入操作类型OP。函数首先读取数据库版本表version_table中表名T1所在行的时间戳和操作类型，之后根据操作类型九宫格判断是否需要判断冲突，如果需要判断冲突，进一步比较内存时间戳和数据库时间戳是否一致，如果不一致则返回存在冲突。

其中，操作类型九宫格，见表2，用于判断数据库操作是否需要判断冲突，因为并不是所有的数据库操作都会引起冲突，所以根据九宫格进行提前判断可以提高效率。概述而言，对于两方编辑请求，若其中一方编辑请求中的数据库操作类型为插入操作，则无需判断是否冲突，否则需要判断是否发生冲突。

然而，需要说明的是，在多人协同编辑，如果有两个及以上的用户更新或者删除，则可能存在冲突。

表2

考虑如下情况：

1用户A和用户B读取数据库后，A执行增加记录R的操作，由于B在A增加R之前已经将数据库读入内存，因此R对于B是不可见的。考虑此后B的操作，无论删除还是更新，都不会和记录R有关；对增加操作，当B增加一个和A一样的R时，导致主键的重复；如果增加的R不一样，则不存在冲突。根据主键进行约束即可。

2用户A和用户B读取数据库后，A执行更新记录R的操作，此时B能看到旧版本的R，因此不会执行添加操作。对于B的更新和删除操作，可能存在冲突。

3用户A和用户B读取数据库后，A执行删除记录R的操作，此时B能看到旧版本的R，因此不会执行添加操作。对于B的更新和删除操作，可能存在冲突。

把上面三种情况进行汇总，就得到了操作类型九宫格，如表2所示。

分散式冲突检测与表粒度级别的集控式冲突检测不同，它是一种记录粒度级别的冲突检测方法。分散式冲突检测对每一个表中记录添加时间戳等编码信息，用于并发时冲突的检测。当用户的SQL语句被检测为集控式冲突时，还要进一步进行分散式冲突检测，如果同样存在冲突，才是真正存在冲突。

分散式冲突检测具体通过如下方式进行：根据编辑请求确定对应的记录在数据库的时间戳和在内存的时间戳，判断该记录在数据库的时间戳和在内存的时间戳是否一致，若不一致则判断存在分散式冲突。

分散式冲突检测算法描述如下：

1数据库层，对所有实体表增加时间戳字段，如表3所示的分散式附带时间戳信息实体表结构。

表3

列名	数据类型	备注
			原实体表字段	原类型
timestamp	时间戳类型	递增时间戳

2对于实体表的每一个记录R，客户端内存中都存在一个结构体Struct R与之对应，Struct R中保存了加载内存时的时间戳信息。

3在集控式冲突检测结果为真时，调用IsDecentralizedCollision()函数，判断SQL语句中所涉及记录的内存时间戳是否和数据库中的时间戳一致，不一致则返回存在冲突。

4如果时间戳一致，说明不存在冲突，SQL语句操作成功。

其中，IsDecentralizedCollision()函数是判断是否存在分散式冲突的核心函数，它的输入包括SQL语句和内存时间戳。函数首先判断SQL语句的类型，对于Update和Delete语句进行时间戳where条件拼接。即把原来的SQL语句，如“update tableA set col1＝5，col2＝4where id＝5”，拼接成“update tableA set col1＝5，col2＝4where id＝5and timestamp＝0x00001222”(注：0x00001222为内存中记录的时间戳)。接下来执行拼接好的SQL语句，如果Update和Delete操作影响的记录数为0，那么说明内存和数据库的时间戳不匹配，返回存在冲突；如果Update和Delete操作影响的记录数大于0，说明执行成功，不存在冲突。最后，如果不存在冲突，还需要更新内存的时间戳信息，更新分为三步：第一步生成检索数据库新时间戳的SQL语句，需要对原SQL语句进行解析，提取表名，限制条件，并和select语句进行拼接，如原来的SQL语句“update tableA set col1＝5，col2＝4where id＝5”拼接成“select timestamp from tableA where id＝5“；第二步执行SQL语句，获取最新时间戳；第三步通过引用的方式，将最新时间戳写入内存结构体Struct R对应的字段。

(3)冲突避免方案

冲突避免方案用于预防应用层数据库并发操作所引发的冲突。冲突避免主要通过加锁的方式，确保当前数据库操作只允许一个用户有编辑权限，其他用户都是只读的。在并发操作频繁，冲突频率高的情况下，相比于冲突检测方案，使用冲突避免方案更具优势。

冲突避免算法描述如下：

1数据库层，新增lock_table表，lock_table表用于存储当前所有表的加锁状态，它包含表名字段和锁定该表的用户名字段，如表4所示；

表4

2尝试获取编辑标签，不同模块需要锁定不同的库表，对于某个特定模块，假定它需要锁定库表T和库表S，则程序首先访问lock_table表，如果表名为T和S记录的LockUserName列均为空，则将它们设置为当前用户名，获取编辑标签成功；如果T或S记录的LockUserName非空，则获取编辑标签失败。

3如果获取编辑标签成功，由于程序是离线模式，数据已经提前加入到内存中，因此还需要对内存数据进行刷新，确保当前内存与数据库数据一致后，再对内存数据进行编辑；

4将对相关表的修改，以SQL语句的形式，提交到数据库；

5释放编辑标签，将lock_table表中本用户锁定的表所对应的LockUserName字段置为空。

本发明提出了一套应用层数据版本冲突的解决方案，当冲突发生频率较低时，采取基于混合冲突检测的方式，SQL请求首先进行集控式冲突检测，之后进行分散式冲突检测，当数据表记录数很多时，前者的检测效率明显优于后者，因此这种混合式冲突检测方式可以有效缩短冲突检测的时间；当冲突发生频率较高时，采取基于冲突避免的方式，写数据的用户需要首先获取相关表的编辑标签，这既避免了冲突，还支持离线应用的其他用户并发操作软件的其他模块；此外，本发明还提供了一套缓存机制，避免不必要的数据库查询，提高查询请求处理效率。

示例

由于冲突检测方法和冲突避免方法是两种不同的离线数据版本冲突问题解决方案，前者适合冲突发生概率低的应用，后者适合冲突发生概率高的应用，因此，本发明使用两个示例进行说明。

在基于冲突检测的示例中，用户A、用户B和用户C并发操作同一张表T。下面展示一下冲突检测方案的流程。

(1)用户A启动软件客户端，需要读取表T的航班信息。

首先，客户端生成SQL语句“select*from T；”。之后，客户端将SQL语句和表名T发送到缓存服务器，缓存服务器首先判断表名T是否过期，如果过期直接返回缓存未击中；如果没有过期，则继续在cache_map中以表名T作为键，查找到cahce_table_map，再在cahce_table_map中以SQL语句作为键，查找缓存的查询结果值。如果缓存击中，则直接返回查询结果。当缓存未击中时，客户端向DB服务器发送请求，DB服务器向数据库提交SQL语句，获取查询结果，并将查询结果返回给用户A的客户端，同时，将查询结果发送给缓存服务器，缓存服务器接收到查询结果，存入CacheMap中。

(2)用户B启动软件客户端，同样需要读取表T的航班信息，获取结果的过程与上一步类似，在此不再赘述。

(3)用户C启动软件客户端，读取表T的航班信息。此时，用户A、用户B和用户C在客户端中的航班信息内容是一致的，但是属于三个不同的副本。数据库T和三个用户的副本数据如下表所示。

(4)用户A购买一张北京飞往上海的CA1002机票，内存中CA1002号航班的剩余票数变为18，此时数据库T与内存对照如下表所示。

用户A生成SQL语句“update T set剩余张数＝18where航班号＝‘CA1002’”，客户端将SQL语句和该记录的内存时间戳0x00000343发送到DB服务器，DB服务器首先进行集控式冲突检测，version_table中表T所对应行没有更改，因此不存在冲突，SQL语句可以成功执行，DB服务器通知客户端更新成功。

(5)接下来，用户B购买了一张北京飞往南昌的机票，此时数据库T与内存对照如下表所示。

用户B生成SQL语句“update T set剩余张数＝31where航班号＝‘CA2343’”，客户端将SQL语句和该记录的内存时间戳0x00000345发送到DB服务器，DB服务器首先进行集控式冲突检测，由于用户A刚刚修改了表T的数据，所以集控式冲突存在，DB服务器进一步进行分散式冲突检测。首先判断SQL语句是update类型，于是执行SQL语句拼接操作，生成SQL语句“update T set剩余张数＝31where航班号＝‘CA2343’and时间戳＝0x00000345”数据库执行该SQL语句成功。DB服务器通知客户端更新成功。

(6)接下来，用户C又购买了一张北京飞往上海的机票，此时数据库T与内存对照如下表所示。

虽然用户A已经购买了一张CA1002号航班的机票，但由于应用是离线方式，用户C的内存中CA1002号航班的机票数仍然显示的是19，因此用户C生成的SQL语句和用户A的是一样的。“update T set剩余张数＝18where航班号＝‘CA1002’”。客户端将SQL语句和该记录的内存时间戳0x00000343发送到DB服务器，DB服务器首先进行集控式冲突检测，由于用户B刚刚修改了表T的数据，所以集控式冲突存在，DB服务器进一步进行分散式冲突检测。首先判断SQL语句是update类型，于是执行SQL语句拼接操作，生成SQL语句“update T set剩余张数＝18where航班号＝‘CA1002’and时间戳＝0x00000343”。而此时数据库中CA1002航班的时间戳已经被A修改为0x00000346，该SQL语句的where条件不匹配，数据库执行失败。DB服务器通知客户端存在冲突，调用客户端的内存刷新函数。用户C此时内存中CA1002号航班的剩余票数已经修改为18，，重新购买一次机票，生成SQL语句“update T set剩余张数＝17where航班号＝‘CA1002’and时间戳＝0x00000346”，数据库执行该SQL语句成功。DB服务器通知客户端更新成功。

在步骤(6)中，如果用户C第一次更新数据库成功，那么数据库T中CA1002的剩余票数就会在实际卖出两张的情况下，只减少了一张，产生与实际数据的不一致。本发明设计的冲突解决方案很好的检测出用户提交中存在的冲突，确保用户在离线状态下每次提交动作时，所操作记录的内存状态与数据库中的状态是一致的，也就保证了数据库数据与真实数据的一致性。

在基于冲突避免的示例中，用户A和用户B操作表T，用户C操作表Y，下面展示一下冲突避免方案的流程。

(1)用户A启动软件客户端，需要读取表T和表Y的航班信息，此过程与基于冲突检测的步骤(1)类似，在此不再赘述。

(2)用户B启动软件客户端，同样读取表T和表Y的航班信息。

(3)用户B启动软件客户端，同样读取表T和表Y的航班信息。此时，用户A、用户B和用户C在客户端中的航班信息内容是一致的，但是属于三个不同的副本。

(4)用户A准备购买一张北京飞往上海的CA1002机票，首先用户A发送获取编辑标签的加锁请求到DB服务器，由于没有其他用户锁定了lock_table中包含表T的记录，所以用户A成功获取了编辑标签，同时锁定lock_table中包含表T的记录。获取编辑标签后，生成SQL语句“update T set剩余张数＝18where航班号＝‘CA1002’”，并成功执行。最后，DB服务器通知客户端更新成功。

(5)用户B准备购买一张北京飞往南昌的CA2343机票，首先用户B发送获取编辑标签的加锁请求到DB服务器，由于用户A锁定了lock_table中包含表T的记录，所以用户B获取编辑标签失败，需要等待用户A释放锁。

(6)用户C准备购买一张天津飞往南京的TU1002机票，首先用户C发送获取编辑标签的加锁请求到DB服务器，由于没有其他用户锁定了lock_table中包含表Y的记录，所以用户C成功获取了编辑标签，同时锁定lock_table中包含表Y的记录。获取编辑标签后，生成SQL语句“update Y set剩余张数＝21where航班号＝‘TU1002’”，并成功执行。最后，DB服务器通知客户端更新成功。

(7)用户A释放锁，lock_table中包含表T的记录被解锁。

(8)用户B重新尝试购买机票，此次获取编辑标签成功，执行SQL语句“update Tset剩余张数＝31where航班号＝‘CA2343’”成功。

本发明针对应用层的并发冲突，公开了一种支持并发协同的离线数据版本冲突解决方案。当冲突发生频率较低时，本发明采取基于混合冲突检测的方式，SQL请求首先进行集控式冲突检测，之后进行分散式冲突检测，当数据表记录数很多时，前者的检测效率明显优于后者，因此这种混合式冲突检测方式可以有效缩短冲突检测的时间。当冲突发生频率较高时，本发明采取基于冲突避免的方式，写数据的用户需要首先获取相关表的编辑标签，这既避免了冲突，还支持离线应用的其他用户并发操作软件的其他模块。此外，本发明还提供了一套缓存机制，避免不必要的数据库查询，提高查询请求处理效率。

本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

虽然本发明所揭露的实施方式如上，但所述的内容只是为了便于理解本发明而采用的实施方式，并非用以限定本发明。任何本发明所属技术领域内的技术人员，在不脱离本发明所揭露的精神和范围的前提下，可以在实施的形式上及细节上作任何的修改与变化，但本发明的专利保护范围，仍须以所附的权利要求书所界定的范围为准。

Claims (8)

1.一种支持并发协同的离线数据版本冲突解决方法，该方法包括：

接收来对数据库进行编辑的编辑请求；

根据应用层的冲突出现概率采取相应的冲突解决方法来判断所述编辑请求是否存在冲突，并在确定没有冲突后根据所述编辑请求对所述数据库进行处理；

其中，

在应用层的冲突出现概率低时，判断所述编辑请求是否存在集控式冲突，所述集控式冲突是一种表粒度级别的冲突，

若不存在所述集控式冲突，则根据所述编辑请求对所述数据库进行处理；

若存在所述集控式冲突，则进一步判断所述编辑请求是否存在分散式冲突，所述分散式冲突是一种记录粒度级别的冲突，

若存在所述分散式冲突，则判断所述编辑请求存在冲突；

若不存在所述分散式冲突，则根据所述编辑请求对所述数据库进行处理。

2.根据权利要求1所述的方法，其特征在于，在判断所述编辑请求是否存在集控式冲突的步骤中，

根据所述编辑请求确定对应的表在数据库的时间戳和数据库操作类型，所述数据库操作类型包括插入操作、更新操作和删除操作；

根据所述数据库操作类型判断是否需要判断冲突；

其中，若需要判断冲突，则判断表在数据库的时间戳与该表在内存中的时间戳是否一致，若不一致则判断存在集控式冲突。

3.根据权利要求2所述的方法，其特征在于，在根据所述数据库操作类型判断是否需要判断冲突的步骤中，

在两方编辑请求中，若其中一方编辑请求中的数据库操作类型为插入操作，则无需判断是否冲突；否则需要判断是否发生冲突。

4.根据权利要求1所述的方法，其特征在于，在判断所述编辑请求是否存在分散式冲突的步骤中，

根据所述编辑请求确定对应的记录在数据库的时间戳和在内存的时间戳；

判断该记录在数据库的时间戳和在内存的时间戳是否一致，若不一致则判断存在分散式冲突。

5.根据权利要求1所述的方法，其特征在于，

在应用层的冲突出现概率高时，对所述编辑请求对应的数据库进行锁定，若锁定成功则根据所述编辑请求对所述数据库进行处理，否则判断所述编辑请求存在冲突。

6.根据权利要求1～5中任一项所述的方法，其特征在于，

若请求为数据库查询请求时，则判断缓存中是否存储有相应的数据库查询结果，如果有则获取所述数据库查询结果，否则通过查询相应的数据库来获取数据库查询结果，

其中，将数据库历史的查询语句和查询结果相关联地存储在所述缓存中。

7.根据权利要求6所述的方法，其特征在于，在判断缓存中是否存储有相应的数据库查询结果的步骤中，

根据数据库历史的查询语句判断所述缓存中是否存在相应的数据库的表名，若存在则判断该表名是否被标记过期，若该表名未被标记过期则获取与之对应的数据库查询结果。

8.根据权利要求7所述的方法，其特征在于，

若该表名被标记过期，则将通过查询相应的数据库来获取的数据库查询结果发送至所述缓存中用来更新过期的数据库查询结果，并取消过期标记。