CN104065636A - 数据处理方法和系统 - Google Patents

Abstract

本申请公开了一种数据处理方法和系统，其中，该方法包括：确定客户端待处理的数据项的锁的状态为未锁定，其中，锁的状态保存在服务端上；请求将数据项对应的锁的状态更改为锁定；在数据项对应的锁的状态被更改为锁定之后，对数据项中的数据进行处理；在处理数据成功之后，请求将数据项对应的锁的状态更改为未锁定。通过本申请，解决了相关技术中采用二阶段提交协议进行数据处理导致的效率低的问题，提高了数据处理的效率。

Description

数据处理方法和系统

技术领域

本申请涉及数据处理领域，具体而言，涉及数据处理方法和系统。

背景技术

随着后台系统访问量的不断增加，数据存储系统中的数据处理技术越来越重要。

在相关技术中，对于数据处理有一种方法是采用二阶段提交协议，即对关键数据进行更改之前先进行准备阶段，查询每个节点的状态，然后根据准备节点的状态，进入提交阶段，来对数据进行更改。

本申请的发明人在研究和实践过程中发现，相关技术至少存在下列技术问题：相关技术每次做数据更改都需要经过准备阶段和提交阶段的网络操作，同步的效率和性能不高；由于在对多个无关的数据进行更改时，需要分别经过多个二阶段提交过程，无法并行处理，即并行性差；必须要有一个节点用来准备和提交，容易产生瓶颈，并且系统不易扩展，这些问题中的至少之一导致了相关技术中的数据同步处理效率低。

针对相关技术中的采用二阶段提交协议进行数据处理导致的效率低的问题，目前尚未提出有效的解决办法。

发明内容

本申请提供了一种数据处理方法和系统，以解决相关技术中采用二阶段提交协议进行数据处理导致的效率低的问题。

根据本申请的一个方面，提供了一种数据处理系统，该系统包括客户端和服务端，其中：所述服务端与所述客户端相连，包括：保存模块，用于保存所述客户端待处理的数据项对应的锁的状态；更改模块，用于更改所述锁的状态为锁定或未锁定；所述客户端包括：确定模块，用于确定所述待处理的数据项对应的锁的状态为未锁定；第一请求模块，用于请求将所述数据项对应的锁的状态更改为锁定；处理模块，用于在所述数据项对应的锁的状态被更改为锁定之后，对所述数据项中的数据进行处理；第二请求模块，用于在处理所述数据成功之后，请求将所述数据项对应的锁的状态更改为未锁定。

根据本申请的另一个方面，还提供了一种数据处理方法，该方法包括：确定客户端待处理的数据项的锁的状态为未锁定，其中，所述锁的状态保存在服务端上；请求将所述数据项对应的锁的状态更改为锁定；在所述数据项对应的锁的状态被更改为锁定之后，对所述数据项中的数据进行处理；在处理所述数据成功之后，请求将所述数据项对应的锁的状态更改为未锁定。

通过本申请，采用了确定客户端待处理的数据项的锁的状态为未锁定，其中，该锁的状态保存在服务端上；请求将该数据项对应的锁的状态更改为锁定；在该数据项对应的锁的状态被更改为锁定之后，对该数据项中的数据进行处理；在处理该数据成功之后，请求将该数据项对应的锁的状态更改为未锁定。解决了相关技术中采用二阶段提交协议进行数据处理导致的效率低的问题，提高了数据处理的效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。并且，对于本领域普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1是根据本申请实施例的数据处理系统的系统结构框图；

图2是根据本申请实施例的数据处理系统的优选系统结构框图；

图3是根据本申请实施例的数据处理方法的流程示意图；

图4是根据本申请优选实施例的数据处理系统的系统框图；

图5是根据本申请优选实施例的位图的示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

在以下描述中，除非另外指明，否则将参考由一个或多个计算机执行的动作和操作的符号表示来描述本申请的各实施例。其中，计算机可以包括个人计算机、服务器、移动终端等各种产品，在以下实施例中，使用了CPU、单片机、DSP等具有处理芯片的设备均可以称为计算机。由此，可以理解，有时被称为计算机执行的这类动作和操作包括计算机的处理单元对以结构化形式表示数据的电信号的操纵。这一操纵转换了数据或在计算机的存储器系统中的位置上维护它，这以本领域的技术人员都理解的方式重配置或改变了计算机的操作。维护数据的数据结构是具有数据的格式所定义的特定属性的存储器的物理位置。然而，尽管在上述上下文中描述本申请，但它并不意味着限制性的，如本领域的技术人员所理解的，后文所描述的动作和操作的各方面也可用硬件来实现。

转向附图，其中相同的参考标号指代相同的元素，本申请的原理被示为在合适的计算环境中实现。以下描述基于所述的本申请的实施例，并且不应认为是关于此处未明确描述的替换实施例而限制本申请。

优选地，本申请实施例可以提供一个其上存储有本申请实施例的机器可读媒体。需要说明的是，任一适合存储设计关于本申请的指令的媒体都在本申请的范围以内。例如，这样的媒体可以采用磁性媒体、光学媒体或半导体媒体的形式。

本实施例提供了一种数据处理系统，图1是根据本申请实施例的数据处理系统的系统结构框图，如图1所示，该系统包括客户端10和服务端12，如图1所示，在该图1中，客户端10可以是多个，服务端12可以是一个或者一组服务器，也可以是一种服务，该服务可以由任何设备提供，例如，可以由服务器提供，或者也可以由多个客户端10中的一个或多个来提供这种服务。

客户端可以是个人电脑（PC），也可以是需要对数据进行处理的任何一个终端，这里的终端是相对于服务端而言的，需要从服务端获取到锁服务的任何一个设备或者该设备上的软件或者一个功能模块均可以理解为是本实施例中的客户端10。

客户端与服务端之间的连接可以是有线连接，也可以是无线连接。可以预料到的，客户端与服务端的任何物理的连接方式都不影响实施例的实现。客户端和服务端可能在同一网络，或者在不同的网络，为了实现客户端和服务端之间的连接可能还需要其他的中间设备，附图中示出的是客户端和服务端之间的连接关系，其余并未在附图中示出。

在以下实施例中，数据项所对应的可以是一个数据项目的名称，该数据项可以有不同的值或者内容，这些值或者内容在本实施例中称为是该数据项中存储的数据。下面通过一个例子来说明数据项和数据项中的数据的关系，该例子不应当理解为对数据项的限定。例如：对应于一个相同用户的用户名信息。在数据存储系统中，该数据项的名称是用户名信息，对于不同的用户该数据项的名称是一样的，均是用户名信息，但是，对于不同的用户该数据项的值可以是不同的。例如，用户1的用户名信息这一数据项的值是“Tom”，而用户2的用户名信息这一数据项的值是“Jerry”。

在本实施例中一个或多个客户端10均可以对数据存储系统中同一数据项中的数据进行处理（例如，修改、更新、写入等处理）。

如图1所示，服务端12可以与一个或多个客户端10相连，该服务端12可以包括：保存模块122和更改模块124，其中，保存模块122用于保存客户端10待处理的数据项对应的锁的状态；更改模块124耦合至保存模块122，用于更改锁的状态为锁定或未锁定；

客户端10包括：确定模块102、第一请求模块104、处理模块106和第二请求模块108，其中，确定模块102用于确定客户端10待处理的数据项对应的锁的状态为未锁定；第一请求模块104耦合至确定模块102，用于请求服务端12将该数据项对应的锁的状态更改为锁定；处理模块106耦合至第一请求模块104，用于在该数据项对应的锁的状态被更改为锁定之后，对该数据项中的数据进行处理；第二请求模块108耦合至处理模块106，用于在处理数据成功之后，请求服务端12将该数据项对应的锁的状态更改为未锁定。

本实施例中所涉及到的模块、单元可以通过软件的方式实现，也可以通过硬件的方式来实现。本实施例中所描述的模块、单元也可以设置在处理器中，例如，可以描述为：一种处理器包括确定模块102、第一请求模块104、处理模块106和第二请求模块108。其中，这些模块的名称在某些情况下并不构成对该模块本身的限定，例如，确定模块还可以被描述为“用于确定客户端10待处理的数据项的锁的状态为未锁定的模块”。

通过上述系统，采用了客户端10根据服务端12中保存的锁的状态对确定该客户端10是否能够对该数据项对应的数据进行处理的方式。由于对于每一个数据项，在每个客户端10对其进行处理时都需要获得锁之后才能进行处理，并且，该锁的状态均由服务端12提供，因此客户端10在要对这个数据项中的数据进行更改的情况下，只需要判断客户端10对于该数据项对应的锁的状态，就能确定能否对该数据项进行处理。对于多个客户端10，当存在一项数据项中的数据可能被多个客户端10修改的时候，每个客户端10在对该数据项中的处理进行处理之前，均可以读取服务端上的该客户端对应的该数据项的锁的状态，如果该锁的状态为未锁定，可以进行数据的处理。这相比于相关技术中的二阶段提交协议而言，只需要通过获取锁的状态就可以对数据进行处理，提供了处理的效率。

在本实施例中，对于客户端10而言，锁服务的提供是由服务端12来提供的，该锁服务可以是与数据存储系统分离存在的，这样就可以实现锁服务与数据存储之间的分离，为多个数据项的并行数据处理提供了基础。

客户端10和服务端12之间的通信可以采用通信方式来实现，例如，可以采用socket等技术来实现，也可以采用不同的协议来读取服务端上的锁状态，但并紧紧限于此。

在上述实施例中，客户端10作为数据存储系统的数据操作者出现，在另外一个优选的实施方式，多个客户端10可以作为一个集群的数据存储系统（即，分布式存储系统）出现，此时，多个客户端10中的每个客户端10均用于保存数据，当需要对数据进行更新时，需要更新每个客户端10上的数据。在本优选实施方式，服务端的锁服务可以表示每个客户端10上保存的相同数据项所对应锁状态。相同数据项可以指对应于一个相同实例的数据项，例如：对应于一个相同用户的用户名信息。在分布式存储系统中的每一个存储数据的客户端10可以都存储对应于一个相同用户的用户名信息，而且在一般情况下，该用户名信息应该是相同的。在其中的一个客户端10接受外部指令需要变更的情况下，分布式存储系统中用于存储的其他客户端10中如果也存在该相同用户的用户名信息，则需要进行同步变更。该优选实施例可以用于上述同步变更的过程。下面对这种应用场景下的一个例子进行说明。例如，当该数据项对应于各个客户端10的锁的状态都为未锁定的情况下，将该数据项对应的锁的状态更改为锁定之后，再对该数据项中的数据进行处理，从而保证了数据的正确处理；当数据项对应于各个客户端10的锁的状态中存在锁定状态的锁，则说明此时至少有一个客户端10上的该数据项处于无法正确读写的状态，此时如果对数据进行处理，则可能无法保证所有客户端10的该数据的均被正确处理。此时，可以对其他的处于未锁定的客户端上的数据进行处理，后续等待处于锁定状态的客户端10的状态变为未锁定时，再对该客户端10的数据进行处理；或者，也可以对等待所有的客户端的状态均变为未锁定时，一起进行数据的处理。

通过这样的方式，在进行数据处理的时候，可以不需要像二阶段提交那样，选择一个主客户端然后再等待其他的每一个客户端10的提交确认，而只需要根据不同的数据项的处理需求，选择从服务端获取锁的方式来进行处理即可，从而解决了相关技术中数据同步处理的效率低的问题，提高了数据同步处理的效率。

在上述的实施例及优选实施方式中，数据项可以是一个或多个，客户端10也可以是一个或多个，此时，服务端12上保存的锁的状态可以包括：多个客户端10分别对应的同一数据项的锁的状态，例如，可以保存一个数据项分别对应的10个客户端10的锁的状态；或者，服务端12上保存的所的状态也可以包括：多个数据项分别对应的锁的状态，例如，数据项1至数据项10分别对应的一个客户端10的锁的状态。当然也可以这两者都包括，例如，10个数据项分别对应的10个客户端10的锁的状态。这些不同的多个数据项之间可以存在耦合关系，例如相同类型，也可以不存在任何耦合关系，即是无关的数据项。即不同的多个数据项是否存耦合关系在本申请的实施例的处理过程中并没有差异。这是因为，将不同的多个数据项对应的锁的状态保存在服务端12上之后，如果客户端10发起对多个不同的数据项进行处理，则可以通过判断服务端12上保存的对应于这些不同的多个数据项的锁的状态来确定是否对这些数据项进行处理。可能出现的情况是，多个客户端的数据项1对应的锁的状态都是未锁定，而多个客户端的数据项2对应的锁的状态中存在锁定的状态，对于数据项1和数据2的处理可以分别进行。

在本申请实施例的一些优选实施方式中，需要对不同的多个数据项进行处理时，可以依次发起并处理其中每一个数据项中的数据，在另一些优选实施方式中，也可以同时发起并处理处理这多个数据项中的数据。这两种优选实施方式都是可以被构想并在本申请实施例中的系统中实现的。通过在服务端12上保存多个数据项对应的锁的状态，可以实现同时发起并处理这多个数据项，从而使系统具有并行处理的能力，并且对于并行处理中的每一个线程或者进程等都可以是独立的，不会相互干扰，具有良好的处理性能，进一步提高了系统处理效率，并且提升了系统的稳定性。

在本申请的一些优选实施方式中，每个客户端10的所有待处理的数据项对应的锁的状态都保存在这个客户端10中，并映射到服务端12中进行保存，即对于每个客户端10中的每个数据项而言，其是否被占用都被表示在这个客户端10中保存的锁的状态中，这些锁的状态通过映射的方式实时映射到服务端12中，使得服务端12中保存的锁的状态与客户端10中保存的锁的状态对应且同步。在另一些优选实施方式中，还有一种方式也是可以被构想的：每一个客户端10同时也是服务端12，即在每一个客户端10中都完整保存了其他的客户端10中的数据项对应的锁的状态。

锁的状态可以采用相关技术中各种公知的方式进行存储，例如列表、栈堆等形式。

作为一个比较优的实施例，锁的状态可以以位图的方式保存在服务端12。位图是由位（例如比特位）集合而成的一种具有索引的数据结构，其中，位图中的每一位用于表示多个存储数据的客户端10中每个客户端10对应的数据项对应的锁的状态。位图中的每个位在二进制系统中存在两种状态，一般用“0”和“1”表示，而在本申请实施例中锁的状态也具有最基本的两种状态“锁定”和“未锁定”，因此，可以用位的两种状态分别表示本申请实施例中锁的两种基本状态，而用位图的位的索引号表示对应的客户端10。由于二进制系统中一个位仅占用一个比特，能表示一个锁的状态，因此，占用的存储资源比较少，例如四个字节就可以用来表示三十二个锁的状态。同时，由于位图的数据结构简单，可以通过索引查询的方式定位一个锁，通过读取位的值直接确定锁的状态，而不需要通过其他的计算，占用的系统资源也很少。通过上述的描述可知使用位图的方式保存锁的状态节约了存储空间，提高了处理效率。

在本申请实施例的一些优选实施方式中，可以构想的一种方式是共享位图中的同一个位来表示多个锁的状态，这多个锁的状态可以是同一个客户端10中多个数据项对应的锁的状态，也可以是多个客户端10中一个数据项对应的锁的状态。在另一些优选的实施方式中，共享位图中同一个位的多个锁的状态对应的多个数据项是存在耦合关系的数据项，例如，在相关技术中，在处理一个数据的时候，记录或更新这个数据被处理的时间是常用的操作。在这种情况下，在表示这个数据和数据被处理的时间分别对应的锁的状态时，共享位图中的同一个位。采用这种优选实施方式，不仅可以进一步节约存储资源，而且位图的规模也可以变小，也提高了位图处理的效率。

优选地，在数据项的数量为多个的情况下，锁的状态以位图的方式保存在服务端12包括：锁的状态以多个位图的方式保存在服务端12，其中，每个位图用于表示多个客户端10的同一个数据项对应的锁的状态，或用于表示多个客户端10中一个客户端10中的多个数据项对应的锁的状态。在这种优选实施方式中，提出了两种位图的结构：根据数据项划分或根据客户端10划分。在系统中可以根据需要采用合适的位图的结构。位图的不同结构表现在索引方式的区别上。例如，采用根据相同数据项划分的方式，不同客户端10上的数据项对应的锁在位图中存储位置的索引是相邻的，在对一个数据项进行处理时，仅需要根据一个位图中的位的信息进行处理，因此相对于根据客户端10划分的位图而言，其索引速度更快，效率更高。需要说明的是上述的“多个位图”仅是为了便于描述进行的概念上的划分。在一些优选实施例中，多个位图仅仅是一个位图中的多个部分。

需要说明的是，由于采用了本申请实施例中锁的状态保存方法，在客户端10的结构发生变化的情况下，锁的状态的存储结构是可以不发生改变的，因此具有一定的兼容性；此外，在系统中的客户端10的数量改变或者待处理的数据项的数量改变的情况下，只需要对存储的锁的状态的数据结构进行相应调整就能适应新的系统，因此，其系统的适应性较强，且升级维护很灵活和容易。

优选地，可能存在多个客户端10请求更改锁的状态的情况，为了避免死锁等情况出现，第一请求模块104用于根据预先确定的顺序请求将该数据项对应的锁的状态更改为锁定；此时，第二请求模块108用于根据与该顺序相反的顺序请求将该数据项对应的锁的状态更改为未锁定。优选地，服务端12在接受这些请求时，如果来自多个客户端10的请求对一个相同的数据项进行处理，则可以按照一定的次序，例如请求接收的次序对来自多个客户端10的请求进行响应，以将对应的锁的状态更改为锁定或未锁定。其中，在服务端12将锁的状态更改为锁定和更改为未锁定的顺序也可以是相反的。在客户端10请求服务端12对即将处理的数据项进行处理之前，需要请求服务端12对即将处理的数据项对应的锁的状态更改为锁定，以防止其他客户端10再次请求这个数据项进行处理而导致处理失败。然而，以下这种情况是很有可能发生的：两个客户端10都请求对同一个数据项进行处理时，两个客户端10都要将这个数据项对应的锁的状态分别由未锁定状态更改为锁定状态；如果两个客户端10对于这一个数据项对应的锁的上锁请求没有按照相同的先后次序对锁的状态进行更改，则可能会产生竞争现象。在上述优选方式中，采用请求按照相同的先后次序将同一数据项对应的锁的状态更改为锁定的方式避免了竞争和死锁现象的发生，提高了系统的稳定性和可靠性。并且，按照由低位至高位或者由高位至低位将锁的状态更改为锁定或未锁定的方式，在防止竞争和死锁现象时并不是必需的，甚至对相邻的位的锁的状态进行更改也不是必需的。只要是按照相同的起点和一定的次序对锁的状态进行更改即可。

在本申请的一些优选实施方式中，将同一个数据项对应于多个客户端10的锁的状态更改为锁定和更改为未锁定的顺序是相反的，例如，在更改为未锁定时按照由低位向高位依次更改，在更改为锁定时则按照由高位向低位依次更改。从而避免了由于各个客户端10请求更改锁状态和服务端12更改锁状态的时延不一致的情况下导致的死锁现象，提高了系统的稳定性和可靠性。

优选地，保存模块122还用于将锁的状态保存在服务端12的内存或共享内存中。在多个客户端10确定或更改锁的状态时，可以通过同时访问服务端12共享的逻辑内存的方式，从而使得多个客户端10中的每一个客户端10都能够通过共享内存同时对锁的状态进行查询和请求服务端12对锁的状态更改，提高了锁状态的查询和更改的效率。

在上述的实施例及其优选的实施方式中，采用客户端10请求更改锁状态，然后由服务端进行更改的方式。这是由于客户端10在服务端上的操作需要被服务端许可，因此，可以认为是服务端在更改锁的状态。作为另一种实现方式，客户端10也可以直接发送命令，该命令用于修改锁的状态，该命令也可以理解为是一种请求。

图2是根据本申请实施例的数据处理系统的优选系统结构框图，如图2所示，优选地，服务端12还包括：判断模块22耦合至更改模块124用于根据时间和当前时间，判断锁的锁定状态是否超过预定时长；以及，更改模块124还用于在将锁的状态更改为锁定的情况下，记录锁的位置和锁的状态更改的时间；更改模块124还用于在判断结果为是的情况下，根据记录的锁的位置，将锁的状态更改为未锁定。

在上述的一些优选实施方式中描述了一种死锁现象和优选的解决方式。而产生死锁现象的原因是有多种的，例如，在一般情况下，客户端10中数据项对应的锁的状态是根据这个客户端10的请求进行更改的，然而在某些情况下，例如状态更改请求由于网络问题丢失了或者在客户端10尚未将锁的状态由锁定更改为未锁定之前离线了，则即使客户端10已经没有占用这个数据项了，在服务端12上保存的对应的锁的状态仍然是锁定状态，导致了其他客户端10无法再对这个数据项进行处理。在这种情况下，也会出现死锁现象。在上述优选实施方式中，在服务端12中应用了超时主动将锁定的锁的状态更改为未锁定的方式，从而防止了死锁现象的发生，提高了系统的稳定性和可靠性。

在本申请的一些优选实施方式中，上述的预定时长是可以根据需要进行设置的，例如可以根据对一个数据项处理的总时间进行确定。对于一个数据项而言，对其对应的锁的状态进行的处理以及对该数据项中的数据的处理所需要的时间往往是毫秒的级别上的，在这种情况下，整个过程在秒的级别上是能够完成的。在一些优选实施方式中，预定时长被设置为3秒钟。优选的，上述优选实施方式采用Java开发工具包（JavaDeveloper′s Kit，简称为JDK）来实现，例如状态更改时间，锁的位置信息等，具体实现本领域技术人员可以根据上述实施例中的技术构思来进行，在此不再赘述。

方法实施例

本实施例提供了一种数据处理方法，该方法可以应用于上述数据处理系统中，图3是根据本申请实施例的数据处理方法的流程示意图，如图3所示，该方法包括如下步骤：

步骤S302，确定客户端待处理的数据项的锁的状态为未锁定，其中，锁的状态保存在服务端上；

步骤S304，请求将该数据项对应的锁的状态更改为锁定；

步骤S306，在该数据项对应的锁的状态被更改为锁定之后，对该数据项中的数据进行处理；

步骤S308，在处理该数据成功之后，请求将该数据项对应的锁的状态更改为未锁定。

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

通过上述步骤，通过上述系统，采用了客户端根据服务端中保存的锁的状态对确定该客户端是否能够对该数据项对应的数据进行处理的方式。由于对于每一个数据项，在每个客户端对其进行处理时都需要获得锁之后才能进行处理，并且，该锁的状态均由服务端提供，因此客户端在要对这个数据项中的数据进行更改的情况下，只需要判断客户端对于该数据项对应的锁的状态，就能确定能否对该数据项进行处理。对于多个客户端，当存在一项数据项中的数据可能被多个客户端修改的时候，每个客户端在对该数据项中的处理进行处理之前，均可以读取服务端上的该客户端对应的该数据项的锁的状态，如果该锁的状态为未锁定，可以进行数据的处理。这相比于相关技术中的二阶段提交协议而言，只需要通过获取锁的状态就可以对数据进行处理，提供了处理的效率。

在该方法实施例中涉及的对应的功能实现也能结合对上述系统中各个模块和单元的功能描述进行结合描述和说明，在此不再赘述。

优选地，锁的状态可以包括：多个客户端分别对应的数据项的锁的状态；和/或，多个数据项分别对应的锁的状态。

优选地，锁的状态可以以位图的方式保存在服务端，其中，位图中的每一位用于表示多个客户端中每个客户端对应的数据项对应的锁的状态。

优选地，在数据项的数量为多个的情况下，锁的状态以位图的方式保存在服务端包括：锁的状态以多个位图的方式保存在服务端，其中，每个位图用于表示多个客户端的同一个数据项对应的锁的状态，或用于表示多个客户端中一个客户端中的多个数据项对应的锁的状态。

优选地，在该多个客户端请求将该锁的状态更改为锁定的情况下，可以根据预先确定的顺序请求将该数据项对应的锁的状态更改为锁定；此时，可以根据与该顺序相反的顺序请求将该数据项对应的锁的状态更改为未锁定。

优选地，锁的状态保存在服务端的内存或共享内存中。

优选地，该方法还包括：在将锁的状态更改为锁定的情况下，服务端记录锁的位置和锁的状态更改为锁定的时间；服务端根据所的状态更改为锁定的时间和当前时间，判断锁的锁定状态是否超过预定时长；在判断结果为是的情况下，根据记录的锁的位置，将锁的状态更改为未锁定。

优选地，解锁一般由客户端向服务端发起，由服务端执行。例如，每一个锁对应一个存储位置，在客户端处理完数据项之后，将请求需要解锁的锁的位置信息发送给服务端，服务端则根据该位置信息将对应的锁的状态更改为未锁定，从而完成了锁的解锁操作。

优选地，本申请还可以提供一个用于执行上述实施例的计算机程序以及保存上述计算机程序的载体，即本申请上述实施例可以通过一个合适的计算体系结构来进行符合自然规律的运行过程。另外，尽管在上述上下文中描述本申请，但上述用于实现执行步骤的计算机程序并不意味着是限制性的，所描述的动作和操作的各方面也可用硬件来实现。

本申请的原理可以使用其它通用或专用计算或通信环境或配置来操作。适用于本申请的众所周知的计算系统、环境和配置的示例包括但不限于，个人计算机、服务器，多处理器系统、基于微处理的系统、小型机、大型计算机、智能设备、终端（包括移动终端）、以及包括任一上述系统或设备的分布式计算环境。

下面将结合优选的实施例对其实现过程进行详细描述。

本优选实施例应用于分布式系统中，采用Java（一种由SUN公司推出的应用程序开发语言）、RPC（Remote Procedure Call，远程过程调用，当一个程序向位于网络中其他计算机的程序请求服务时使用的协议，此时请求服务的程序不需要了解对方网络的详细内容）、BitMap（位图，又称为点阵图，是一种按位表示状态的数据结构）、Hash（哈希，一种快速检索的算法）等技术实现用户操作的串行化，保证用户关键数据的正确读写，并解决了相关技术并行性差、处理效率低的问题。

图4是根据本申请优选实施例的数据处理系统的系统框图，如图4所示，该系统包括锁服务端42、客户端44（相当于上述客户端10）和数据存储集群46。其中，锁服务端42相当于上述的服务端12，用于存储各个客户端对应于各个关键数据（即上述待处理的相同数据项）的锁的状态，以提供锁服务；数据存储集群46是分布式系统中存储数据的存储服务器的集群。

需要说明的是，图4是图1的一种简单变形形式。其中，在图4中还示出了用于存储数据项的数据存储集群46。需要说明的是，客户端44也可以是数据存储集群46中的一个存储服务器。

在图4中还示出了本优选实施例的数据处理系统的工作交互过程，这些过程均可以采用RPC方式进行，包括如下步骤：

步骤S402，请求锁。每次对关键数据进行读写操作之前请求锁操作，如果该锁未被上锁，则返回客户端44成功，可以进行后续操作，否则，返回客户端44失败。

步骤S404，关键数据读写。在获取锁之后（此时锁服务端42中相应的锁被上锁），即可对关键数据进行读写操作。因为存储部分与本申请关系不大，因此在此不再赘述。

步骤S406，解锁。客户端44在完成关键数据的读写操作之后，需要对之前请求的锁进行解锁操作，以备下次关键数据读写操作时继续使用。

为了提高锁服务的可用性，锁服务采用BitMap实现，按位表示每个用户（即上述客户端44）的锁服务状态，例如，在本优选实施例中定义“0”表示未上锁，“1”表示上锁。图5是根据本申请优选实施例的位图的示意图，如图5所示，图中一共有25个锁位，可以表示25个用户对关键数据的上锁状态，图中索引为0（即第一行左起第一个位置）和2（即第一行左起第三个位置）的锁为上锁状态，其余索引位均为未上锁状态。图中每1个锁位占用1位，则25个用户只需要占用25位；由于4个字节可以提供32位，因此，图5中所示的位图仅需4个字节即可满足需要。

需要说明的是，如果要表示多个关键数据的锁状态的话，可以采用多个锁位来表示用户对不同关键数据的上锁状态。并且，为了防止死锁，上锁可以由锁位低位向高位进行依次上锁，解锁需要由高位向低位进行解锁。

优选地，上述位图的位图空间申请，采用共享内存的方式实现。通过该方式实现多个客户端同时访问和更改位图中的锁的状态。

优选地，对位图中的位的设置操作如下：

步骤1，计算锁位（即锁在位图中的位）对应的字节索引，记为pos；

步骤2，计算锁位对应的字节内索引，记为inpos；

步骤3，判断是对该锁进行上锁还是解锁操作，如果是上锁，可以通过掩码或1操作将锁位置为1，否则可以通过掩码与0操作将锁位置为0，置位后的字节记为newbyte；

步骤4，将newbyte替换pos位置的字节。

优选地，检测位图中的位是否上锁的操作如下：

步骤1，计算锁位对应的字节索引，记为pos；

步骤2，计算锁位对应的字节内索引，记为inpos；

步骤3，通过掩码与1操作获取指定字节位是否为1，如果是则确定为上锁状态，否则确定为解锁状态。

为了防止死锁，锁服务端42上本身采用了死锁检测机制，来释放长时间占用却未解除的锁。这里采用Java开发工具包（Java Developer′s Kit，简称为JDK）中的ConcurrentHashMap<int,int>（以下用Map来表示）来记录用户的锁状态，该Map可以提供并发的检索和更新操作。

优选地，采用上述的Map进行上锁、解锁和进行死锁检测的方式如下：

步骤S1，当用户上锁操作时，将用户的上锁位置（记为index）和上锁时间（记为locktime）计入Map中，调用在Map中保存信息的功能：Map.put（index,locktime），这样就完成了上锁时间和上锁位置的记录。该过程由客户端发起RPC，由服务端完成。

步骤S2，当用户解锁操作时，将用户的解锁位置index传入Map中，并从Map中将上锁信息移除，例如调用Map.remove(index)移除上锁信息。该过程由客户端发起RPC，由服务端完成。

步骤S3，为了防止死锁，在本优选实施例中规定了一个锁超时时间，例如将锁超时时间设置为3秒，则锁服务端42每隔3秒会检测Map，将超时的锁移除。该过程由服务端发起，也由服务端完成。

客户端在进行关键数据更新操作（记为UpdateKeyData函数）前，需要先做加锁操作（记为Lock），这里会有3种情况：

情况11，加锁成功，可继续进行关键数据更新，并且无论数据是否更新成功，要完成解锁操作；

情况12，加锁失败被占用，不能继续关键数据更新，客户端可以稍后重试；

情况13，加锁失败调用异常（可能是网络异常、硬件故障等导致），后续操作同情况二，例如，稍后重试。

当完成关键数据更新后，需要进行解锁操作，这里可能会出现两种情况：

情况21，解锁成功，程序即可继续执行；

情况22，解锁失败，异常情形同加锁操作情况13中的描述，这里将会采用服务端实现的步骤S3操作来完成解锁操作。

优选地，客户端实现的操作如下：

步骤1，预先设置用于表示是否成功上锁的变量isSucLock，并设置为不成功；

步骤2，与锁服务通讯设置指定锁为上锁状态，并将结果设置到变量isSucLock中；

步骤3，如果上锁成功，则更新关键数据，否则返回不成功；

步骤4，如果成功上锁，与服务器通讯做一次解锁操作。

在本优选实施例中还提供了一种将字符串转换为int（即整型变量）的方法。由于在某些系统，用户的身份标识号码（IDentity，简称为ID）并非int类型，而可能是常见的是字符串类型，这里将提供两种将字符串转换为int的优选方法，包括：调用String.hashCode()函数进行转换；或者根据实际的ID情况，对hashCode进行重写。

上述实施例及优选实施方式可以应用到用户积分处理中，以下对此进行说明。需要说明的是，用户积分处理仅仅是一个优选的应用场景，并不限于此。

在某些网络服务中，例如，在QQ中，对于不同的QQ用户可以进行评级，这些评级可以是对用户的行为进行累计积分，并根据累计的积分划分用户等级，以给不同层次的用户提供差异化的服务。这些积分可以储存在服务器上，根据用户的行为以及一定的策略可以计算和累计积分。由于在一些策略中，积分还可以对应于“多个用户”，因此，需要一种可靠的积分处理方法用于多个用户对服务器上的积分进行处理。需要说明的是，上述的“多个用户”可以指多个用户账号，也可以指同一个用户账号可以使用的多个服务。

例如，用户积分的场景可以是这样的，A用户自身的行为可以增加A的积分+1，B用户的自身行为除了可以增加B的积分+1，也可以增加A的积分+1。

假设A用户积分是1，在某个时间点A发出动作，B也发出动作，正常情况下A的积分应该变成3。但是如果没有合理的加锁机制，会导致A的积分错误，例如，客户端A先获取积分1，然后+1，更新到数据存储为2，在A未更新时，此时B获取A的积分，然后+1，得到的结果仍然为2，而不是3

以腾讯公司的QQ（一款腾讯公司的即时通讯软件）等级为例，其等级计算也是基于一定的积分的策略，但其积分的单位是以“累计登录天数”计的，简称“天”。QQ等级的默认积分策略是每一个自然天中保持登陆2小时以上，则增加QQ积分1天。此外，还设置了积分累计的其他策略，如下表所示：

表1

QQ加速类别	加速时间
		QQ电脑管家	额外加速1天
超级QQ	最高提速1.9倍
		QQ拼音输入法	0.1天加速

上表中的“加速”、“提速”均是指增加积分，其中的“最高提速1.9倍”是指相对于1天的“默认积分”提高1.9倍积分，即增加1.9天的积分。

假设某用户的QQ等级积分已经达到了20天。在正常情况下：一个用户在一次使用QQ服务的过程中，其QQ保持登陆满足了2小时，则可以增加1天的积分。与其QQ共享同一个用户账号的QQ电脑管家（一款集软件管理、平台优化等多种功能为一体的软件）也满足了额外加速1天的要求，则也可以增加1天的积分。因此，这个用户的QQ等级积分应该达到22天。

然而，如果不采用合理的加锁机制，这个用户的积分的累计可能出现错误，例如：QQ和QQ电脑管家同时满足了增加积分的要求，此时，QQ和QQ电脑管家都请求服务器对这个用户的QQ等级的积分进行增加。在一些情况下，服务器根据QQ的请求将存储的积分增加1天，即更改为21天；在服务器尚未处理完QQ的请求时，服务器同时也处理QQ电脑管家的增加1天积分的请求，即服务器也将积分更改为21天。这样处理完之后的这个用户的QQ等级的积分为21天，与实际应该达到的22天不相符，从而出现了积分计算的错误。

将上述的实施例和优选实施例应用在积分处理的场景中，可以解决上述问题。该实现过程可以包括如下步骤：

步骤1，将这个用户的QQ等级的积分与QQ、QQ电脑管家、超级QQ、QQ拼音输入法分别设置一个数据锁，为了便于描述，在本优选实施方式中分别称之为：“积分-QQ锁”，“积分-QQ电脑管家锁”，“积分-超级QQ锁”，“积分-QQ拼音输入法锁”；

步骤2，在QQ请求服务器更改QQ等级的积分的情况下，先确定“积分-QQ锁”，“积分-QQ电脑管家锁”，“积分-超级QQ锁”，“积分-QQ拼音输入法锁”的状态都为未锁定状态，此时表明QQ等级的积分尚未被用户（指QQ、QQ电脑管家、超级QQ、QQ拼音输入法）处理；

步骤3，QQ请求将“积分-QQ锁”的状态更改为锁定状态（或者将“积分-QQ锁”，“积分-QQ电脑管家锁”，“积分-超级QQ锁”，“积分-QQ拼音输入法锁”中的一个或多个更改为锁定状态）；由于每一个用户请求更改QQ等级积分时都需要根据步骤2判断各个锁的状态是否都为未锁定状态，因此，只要判断到这些数据锁中存在锁定的，就可以判断到有用户正在对QQ等级的积分进行处理，此时可以不请求服务器对QQ等级的积分进行处理，从而避免了产生积分累计错误。

步骤4，在相应的锁的状态被更改为锁定状态之后，QQ就可以请求服务器对这个用户的QQ等级的积分进行处理；

步骤5，在处理积分成功之后，为了让其他用户能够继续对积分进行处理，还需要将请求更改为锁定的锁的状态再更改为未锁定状态。

通过上述的步骤，有效地防止了多个用户对同一个QQ等级的积分数据进行处理时可能产生冲突和错误的问题，提高QQ等级计算的可靠性。

需要说明的是，上述优选实施例仅作为本申请示例性的描述和说明，并不应理解为对本申请的限定，例如，上述处理的数据除了积分之外，还可以是可以多个用户共享处理的文件，多个用户共享编辑的文本等，本领域技术人员容易想到对于分布式存储的、可供多个用户访问和编辑的数据都能应用本申请实施例所示例的数据处理方法，实现可靠的数据处理，并提高数据处理的效率。

综上所述，通过本申请的上述实施例、优选实施例或优选实施方式，提供了一种高效的分布式锁的实现方式，通过该方式实现的分布式锁的加解锁与存储无耦合关系；同时，在其中的一些优选实施方式中采用了位图的表示方式，能够最大化的节约锁占用的存储空间。采用上述方式实现的分布式锁方案容易扩展，可以根据实际情况和系统的变动情况对所服务进行灵活的扩容。

上述优选的实施方式是可以结合使用的。另外，如本申请所使用的，术语“模块”或“单元”可以指在布线装置上执行的软件对象或例程。此处所描述的不同模块和单元可被实现为在布线装置上执行（例如，作为单独的线程）的对象或进程，同时，上述布线装置使用硬件或软件和硬件的组合的实现也是可能并被构想的。

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

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (14)

1.一种数据处理系统，其特征在于，包括客户端和服务端，其中：

所述服务端与所述客户端相连，包括：

保存模块，用于保存所述客户端待处理的数据项对应的锁的状态；

更改模块，用于更改所述锁的状态为锁定或未锁定；

所述客户端包括：

确定模块，用于确定所述待处理的数据项对应的锁的状态为未锁定；

第一请求模块，用于请求将所述数据项对应的锁的状态更改为锁定；

处理模块，用于在所述数据项对应的锁的状态被更改为锁定之后，对所述数据项中的数据进行处理；

第二请求模块，用于在处理所述数据成功之后，请求将所述数据项对应的锁的状态更改为未锁定。

2.根据权利要求1所述的系统，其特征在于，

所述锁的状态包括：多个客户端分别对应的所述数据项的锁的状态；和/或，多个数据项分别对应的锁的状态。

3.根据权利要求2所述的系统，其特征在于，所述锁的状态以位图的方式保存在所述服务端，其中，所述位图中的每一位分别用于表示所述多个客户端中每个客户端对应的所述数据项的锁的状态。

4.根据权利要求3所述的系统，其特征在于，在所述相同数据项的数量为多个的情况下，所述锁的状态以所述位图的方式保存在所述服务端包括：所述锁的状态以多个所述位图的方式保存在所述服务端，其中，每个所述位图用于表示所述多个客户端的同一个数据项对应的锁的状态，或用于表示所述多个客户端中一个客户端中的多个数据项对应的锁的状态。

5.根据权利要求2至4中任一项所述的系统，其特征在于，在所述多个客户端请求将所述锁的状态更改为锁定的情况下，

所述第一请求模块用于根据预先确定的顺序请求将所述数据项对应的锁的状态更改为锁定；

所述第二请求模块用于根据与所述顺序相反的顺序请求将所述数据项对应的锁的状态更改为未锁定。

6.根据权利要求2至4中任一项所述的系统，其特征在于，所述保存模块还用于将所述锁的状态保存在所述服务端的内存或共享内存中。

7.根据权利要求2至4中任一项所述的系统，其特征在于，

所述更改模块还用于在将所述锁的状态更改为锁定的情况下，记录所述锁的位置和所述锁的状态更改为锁定的时间；

所述服务端还包括：判断模块，用于根据所述锁的状态更改为锁定的时间和当前时间，判断所述锁的锁定状态是否超过预定时长；以及，

所述更改模块还用于在判断结果为是的情况下，根据记录的所述锁的位置，将所述锁的状态更改为未锁定。

8.一种数据处理方法，其特征在于包括：

确定客户端待处理的数据项的锁的状态为未锁定，其中，所述锁的状态保存在服务端上；

请求将所述数据项对应的锁的状态更改为锁定；

在所述数据项对应的锁的状态被更改为锁定之后，对所述数据项中的数据进行处理；

在处理所述数据成功之后，请求将所述数据项对应的锁的状态更改为未锁定。

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

所述锁的状态包括：多个客户端分别对应的所述数据项的锁的状态；和/或，多个数据项分别对应的锁的状态。

10.根据权利要求9所述的方法，其特征在于，所述锁的状态以位图的方式保存在所述服务端，其中，所述位图中的每一位分别用于表示所述多个客户端中每个客户端对应的所述数据项的锁的状态。

11.根据权利要求10所述的方法，其特征在于，在所述数据项的数量为多个的情况下，所述锁的状态以所述位图的方式保存在所述服务端包括：所述锁的状态以多个所述位图的方式保存在所述服务端，其中，每个所述位图用于表示所述多个客户端的同一个数据项对应的锁的状态，或用于表示所述多个客户端中一个客户端中的多个数据项对应的锁的状态。

12.根据权利要求8至11中任一项所述的方法，其特征在于，在所述多个客户端请求将所述锁的状态更改为锁定的情况下，

请求将所述数据项对应的锁的状态更改为锁定包括：根据预先确定的顺序请求将所述数据项对应的锁的状态更改为锁定；

请求将所述数据项对应的锁的状态更改为未锁定包括：根据与所述顺序相反的顺序请求将所述数据项对应的锁的状态更改为未锁定。

13.根据权利要求8至11中任一项所述的方法，其特征在于，所述锁的状态保存在所述服务端的内存或共享内存中。

14.根据权利要求8至11中任一项所述的方法，其特征在于，所述方法还包括：

在将所述锁的状态更改为锁定的情况下，所述服务端记录所述锁的位置和所述锁的状态更改为锁定的时间；

所述服务端根据所述锁的状态更改为锁定的时间和当前时间，判断所述锁的锁定状态是否超过预定时长；

在判断结果为是的情况下，根据记录的所述锁的位置，将所述锁的状态更改为未锁定。