CN102541906B - 分布式业务处理方法及分布式系统 - Google Patents

Abstract

本申请公开了一种分布式系统及其业务处理方法，所述系统包括控制设备和至少一个业务处理设备，所述控制设备包括：接收单元，用于接收各业务处理设备的注册请求；分配单元，用于在所述接收单元接收到所述注册请求后为所述业务处理设备分配处理的数据范围；所述业务处理设备包括：注册单元，用于向所述控制设备发送注册请求，以注册本业务处理设备的信息，并在注册成功后从所述控制设备获取自己处理的数据范围信息；数据申领单元，用于根据所述注册单元获取的数据范围信息从业务数据库中申领业务数据；执行单元，用于处理所述数据申领单元申领的业务数据。本申请提供的技术方案，可以满足不同环境下业务数据处理的需求，不仅效率高，而且应用方便。

Description

分布式业务处理方法及分布式系统

技术领域

本申请涉及分布式系统技术领域，特别是涉及一种分布式业务处理方法及分布式系统。

背景技术

目前，很多系统都需要在后台进行大量的业务数据处理，在有很大数据量需要实时处理时，单台设备往往无法满足要求。比如，淘宝评价系统每天会由会员产生600多万评价数据，这些评价数据需要实时处理，如果不能尽快处理的话，会导致会员无法获得信用值。为此，通常会采用分布式系统提高系统对数据的实时处理能力。

分布式系统是独立设备的集合体，而这些设备的集合体在用户看来如同一台设备。在分布式操作系统支持下，互连的设备可以互相协调工作，共同完成一项任务。分布式系统具有以下特点：资源共享、多节点、并行性、开放性、分散控制等。

在现有技术中，采用分布式系统对业务数据进行实时处理的通常做法是：预先评估系统中单台设备的处理能力并通过硬编码的方式将需要处理的业务数据分担到系统中的多台设备上，以实现多台设备对业务数据的并行处理，同时保证各设备不会处理相同的业务数据。由于是硬编码的方式，所以在某台设备宕机或者增加新的设备的时候，都需要重新修改代码并发布程序。这种处理方式不仅需要人工介入，而且效率低，甚至会影响到系统中其他设备的正常工作。

发明内容

为解决上述技术问题，本申请实施例提供一种分布式系统及其业务处理方法，以提高对业务数据的处理效率，方便用户的使用。

本申请实施例提供如下技术方案：

一种分布式系统，包括控制设备和至少一个业务处理设备，所述控制设备包括：

接收单元，用于接收各业务处理设备的注册请求；

分配单元，用于在所述接收单元接收到所述注册请求后为所述业务处理设备分配处理的数据范围；

所述业务处理设备包括：

注册单元，用于向所述控制设备发送注册请求，以注册本业务处理设备的信息，并在注册成功后从所述控制设备获取自己处理的数据范围信息；

数据申领单元，用于根据所述注册单元获取的数据范围信息从业务数据库中申领业务数据；

执行单元，用于处理所述数据申领单元申领的业务数据。

优选地，所述控制设备还包括：

检查单元，用于在所述分配单元为所述业务处理设备分配处理的数据范围之前，检查所述业务数据库中是否存在未被申领的业务数据，如果是，则指示所述分配单元为所述业务处理设备分配处理的数据范围。

优选地，所述注册单元，具体用于按照第一预定周期向所述控制设备发送注册请求，并在从所述控制设备获取自己处理的数据范围信息后，停止向所述控制设备发送注册请求；

相应地，所述数据申领单元，还用于将业务数据库中自己已申领的业务数据标注上已申领标记、申请该业务数据的业务处理设备标识、以及申领时间，并在第一次从业务数据库中申领业务数据后，按照第二预定周期更新所述申领时间。

优选地，所述数据申领单元，还用于在更新所述申领时间失败后，通知所述注册单元按照第一预定周期向所述控制设备发送注册请求。

优选地，所述控制设备还包括：

设置单元，用于设置所述业务数据库中各数据范围的业务数据的申领保持时间；

数据维护单元，用于检查所述业务数据库中各数据范围的业务数据的申领保持时间，并在检查到所述申领保持时间过期后将所述申领保持时间对应的业务数据的已申领标记重置为未申领标记。

优选地，所述控制设备还包括：

统计单元，用于统计所述业务数据库中的业务数据量；

所述分配单元，还用于在所述业务数据量增长到需要增加新的业务处理设备时，停止为所述业务处理设备分配处理的数据范围，并在等待预定时间后，根据增加后业务处理设备的数量重新为所述业务处理设备分配处理的数据范围。

一种分布式系统业务处理方法，所述分布式系统包括控制设备和至少一个业务处理设备，所述方法包括：

业务处理设备向控制设备发送注册请求，以注册本业务处理设备的信息；

所述控制设备接收到所述业务处理设备的注册请求后，为所述业务处理设备分配处理的数据范围；

所述业务处理设备在注册成功后从所述控制设备获取自己处理的数据范围信息，根据所述数据范围信息从业务数据库中申领业务数据，并处理申领的业务数据。

优选地，所述方法还包括：

所述控制设备为所述业务处理设备分配处理的数据范围之前，检查所述业务数据库中是否存在未被申领的业务数据，如果是，则执行为所述业务处理设备分配处理的数据范围的步骤。

优选地，所述方法还包括

所述业务处理设备按照第一预定周期向所述控制设备发送注册请求，并在从所述控制设备获取自己处理的数据范围信息后，停止向所述控制设备注册本业务处理设备的信息；

所述业务处理设备将业务数据库中自己已申领的业务数据标注上已申领标记、申请该业务数据的业务处理设备标识、以及申领时间，并在第一次从业务数据库中申领业务数据后，按照第二预定周期更新所述申领时间。

优选地，所述方法还包括：

所述业务处理设备在更新所述申领时间失败后，按照第一预定周期向所述控制设备发送注册请求。

优选地，所述方法还包括：

所述控制设备设置所述业务数据库中各数据范围的业务数据的申领保持时间；

所述控制设备检查所述业务数据库中各数据范围的业务数据的申领保持时间，并在检查到所述申领保持时间过期后将所述申领保持时间对应的业务数据的已申领标记重置为未申领标记。

优选地，所述方法还包括：

所述控制设备统计所述业务数据库中的业务数据量，并在所述业务数据量增长到需要增加业务处理设备时，停止为所述业务处理设备分配处理的数据范围，并在等待预定时间后，根据增加后业务处理设备的数量重新为所述业务处理设备分配处理的数据范围。

本申请实施例提供的技术方案，针对需要周期地实时处理业务数据的业务场景，采用分布式系统，并且由分布式系统中的各业务处理设备通过注册过程从控制设备获取自己处理的数据范围，并根据该数据范围从业务数据库中申领相应的业务数据并处理。从而满足各种不同环境下业务数据处理的需求，提高了业务数据的处理效率，并方便了用户的使用。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是本申请实施例分布式系统的组网示意图；

图2是本申请实施例分布式系统的各设备的结构示意图；

图3是本申请实施例分布式系统中控制设备的另一种结构示意图；

图4是本申请实施例分布式系统中控制设备的另一种结构示意图；

图5是本申请实施例分布式系统中控制设备的另一种结构示意图；

图6是本申请实施例分布式系统中业务处理方法的流程图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

本申请实施例分布式系统及其业务处理方法，由控制设备统一管理并分配业务处理设备需要处理的数据范围，业务处理设备通过向控制设备注册本业务处理设备的信息来获得自己需要处理的数据范围，并根据该数据范围从业务数据库中申领业务数据，并对申领的业务数据进行处理。

如图1所示，是本申请实施例分布式系统的组网示意图。

该分布式系统包括控制设备和至少一个业务处理设备，其中，所述控制设备用于接收各业务处理设备的注册请求，并在接收到所述注册请求后为所述业务处理设备分配处理的数据范围。所述业务处理设备用于向所述控制设备发送注册请求，以注册本业务处理设备的信息，并在注册成功后从所述控制设备获取自己处理的数据范围信息；根据所述数据范围信息从业务数据库中申领业务数据，并处理所述业务数据。

需要说明的是，所述业务数据库中存放所述分布式系统需要处理的所有业务数据，所述业务数据库可以是位于一个或多个独立的数据库服务器中，也可以是在所述控制设备中。

如图2所示，是本申请实施例分布式系统的各设备的结构示意图。为了清楚起见，在图2中只示出了一个业务处理设备200，所述分布式系统中的各业务处理设备结构相同。

其中，所述控制设备100包括：

接收单元101，用于接收各业务处理设备的注册请求；

分配单元102，用于在所述接收单元101接收到所述注册请求后为所述业务处理设备分配处理的数据范围。

比如，所述分配单元102可以向所述业务处理设备返回一个响应消息，在该响应消息中携带所述数据范围的信息。

所述业务处理设备200包括：

注册单元201，用于向所述控制设备100发送注册请求，以注册本业务处理设备的信息，并在注册成功后从所述控制设备100获取自己处理的数据范围信息；

数据申领单元202，用于根据所述注册单元201获取的数据范围信息从业务数据库中申领业务数据；

执行单元203，用于处理所述申领单元202申领的业务数据。

在本申请实施例分布式系统，可以将业务处理设备需要处理的数据范围配置到数据库中，代替硬编码的方式，由控制设备统一管理并分配业务处理设备需要处理的数据范围，业务处理设备通过向控制设备注册本业务处理设备的信息来获得自己需要处理的数据范围，并根据该数据范围从业务数据库中申领业务数据，并对申领的业务数据进行处理，从而可以提高对业务数据的处理效率，方便用户的使用。

为了使所述控制设备能够为业务处理设备分配有效的数据范围，参照图3所示本申请实施例分布式系统中控制设备的另一种结构示意图。

在该实施例中，所述控制设备300除了包括：接收单元101和分配单元102之外，还进一步包括：检查单元103，用于在所述分配单元102为所述业务处理设备分配处理的数据范围之前，检查所述业务数据库中是否存在未被申领的业务数据，如果是，则指示所述分配单元102为所述业务处理设备分配处理的数据范围。

如果检查单元103检查到所述业务数据库中没有未被申领的业务数据，则可以直接向所述业务处理设备返回注册失败消息。当然，在具体应用时，本申请实施例并不仅限于这种方式，比如，检查单元103检查到所述业务数据库中没有未被申领的业务数据后，也可以通知分配单元102，由分配单元102向所述业务处理设备返回注册失败消息。

再比如，不论检查单元103检查到所述业务数据库中是否存在未被申令的业务数据，都由分配单元102向所述业务处理设备返回注册响应消息，检查单元103只需将检查结果通知分配单元102，如果检查结果是所述业务数据库中存在未被申令的业务数据，则分配单元102为所述业务处理设备分配处理的数据范围，并将所述数据范围的信息携带在所述注册响应消息中传送给所述业务处理设备；如果检查结果是所述业务数据库中没有未被申领的业务数据，则分配单元102向所述业务处理设备返回未携带数据范围的注册响应消息。相应地，所述业务处理设备中的注册单元根据接收到注册响应消息获得自己处理的数据范围信息。

继续参照图1，为了避免业务处理设备瞬时异常使得注册失败，从而影响其正常的运行，在本申请实施例中，所述注册单元201可以在未得到自己处理的数据范围信息之前，周期地向所述控制设备发送注册请求，为描述方便，将其称为第一预定周期，比如每隔5分钟向所述控制设备发送一次注册请求，向所述控制设备注册本业务处理设备的信息并申领数据范围信息，在从所述控制设备获取自己处理的数据范围信息后，停止向所述控制设备发送注册请求。

另外，为了保证各业务处理设备正确申领到自己处理的业务数据，并避免单个业务处理设备宕机后该业务处理设备处理的相应业务数据能够及时由所述分布式系统中其它业务处理设备来处理，在本申请实施例中，所述数据申领单元202还可进一步用于将业务数据库中自己已申领的业务数据标注上已申领标记、申请该业务数据的业务处理设备标识、以及申领时间，并在第一次从业务数据库中申领业务数据后，按照第二预定周期，比如30分钟一次，更新所述申领时间。如果更新失败，比如网络故障或控制设备故障，则所述数据申领单元202停止更新所述申领时间，另外还可通知所述注册单元201开始周期地向所述控制设备发送注册请求。所述注册单元201收到通知后，按照第一预定周期，周期地向所述控制设备发送注册请求。这样一旦故障排除后，所述业务处理设备通过注册过程重新从所述控制设备获取新的数据范围，并根据该数据范围从业务数据库中申领到相应的业务数据，从而继续正常的业务处理工作。

相应地，参照图4所示本申请实施例分布式系统中控制设备的另一种结构示意图。

与图3所示实施例不同的是，在该实施例中，所述控制设备400还进一步包括：设置单元104和数据维护单元105。其中：

所述设置单元104，用于设置所述业务数据库中各数据范围的业务数据的申领保持时间，比如可以是1小时；

所述数据维护单元105，用于检查所述业务数据库中各数据范围的业务数据的申领保持时间，并在检查到所述申领保持时间过期后将所述申领保持时间对应的业务数据的已申领标记重置为未申领标记，以等待其他业务处理设备申领所述业务数据。

这样，在某个业务处理设备宕机后，该业务处理设备申领的数据范围的业务数据上标注的申领时间长时间得不到更新，在所述数据维护单元105检查到该数据范围的业务数据的申领时间距当前时间超过了该数据范围的业务数据的申领保持时间，则回收该数据范围的业务数据，以等待其他业务设备申领。具体地，所述数据维护单元105可以将该数据范围的业务数据上标注的已申领标记修改为未申领标记。当然，也可以直接将所述已申领标记删除。另外，该数据范围的业务数据上标注的其它信息也可以一起删除。

相应地，在宕机的业务处理设备恢复正常后，该业务处理设备的注册单元向控制设备发送注册请求，重新从所述控制设备获取自己处理的数据范围，并根据该数据范围从业务数据库中申领到相应的业务数据，从而继续正常的业务处理工作。

在业务数据量持续增长，导致所述分布式系统中当前业务处理设备的数量不足，需要增加新的业务处理设备的情况下，本申请实施例的分布式系统也可以实现动态调整，实现分布式环境下增加新的业务处理设备、自动调整配置参数等功能。当然，如果业务数据量减小到一定程度，也可以动态去除某个业务处理设备，其原理与增加新的业务处理设备相同。

相应地，参照图5所示本申请实施例分布式系统中控制设备的另一种结构示意图。

与图4所示实施例不同的是，在该实施例中，所述控制设备500还包括：

统计单元106，用于统计所述业务数据库中的业务数据量。

相应地，所述分配单元102还用于在所述业务数据量增长到需要增加新的业务处理设备时，停止为所述业务处理设备分配处理的数据范围，并在等待预定时间后，根据增加后业务处理设备的数量重新为所述业务处理设备分配处理的数据范围。

比如，未增加新的业务处理设备之前，分布式系统中业务处理设备的数量为4，总共需要分配的数据范围为1～16，允许4个业务处理设备注册，这样，为每个注册的业务处理设备分配的数据范围是4个，具体为哪4个可根据实际需要来确定，而且可以有多种方式将为其分配的业数据范围的信息发送给注册成功的业务处理设备，将在后面详细说明。

在业务数据量增加后，需要分配的数据范围为1～20，增加1个新的业务处理设备，即允许5个业务处理设备注册，这样，为每个业务处理设备分配处理的数据范围仍然是4个。

需要说明的是，上面所述的预定时间可以设置为与前面所述的各数据范围的业务数据的申领保持时间相同，比如1小时，这样可以更好地避免由于所述系统中业务处理设备数量的变更可能造成的数据重复处理，提高处理效率。

在具体实现时，所述统计单元106在统计到所述业务数据量增长到需要增加业务处理设备时，向所述分配单元102发送一个中断信号，所述分配单元102收到该中断信号后，停止为所述业务处理设备分配处理的数据范围。当然，本申领实施例并不仅限于这种实现方式。

另外，所述统计单元106可以直接统计所述业务数据库中的业务数据量，也可以统计各业务处理设备处理的业务数据量，再综合各业务处理设备的处理能力来确定是否需要增加新的业务处理设备，具体可根据实际应用需求来确定，在本申请实施例中不做限定。

需要说明的是，前面提到的第一预定周期、第二预定周期、以及申领保持时间等信息可根据具体应用需要来设定，在本申请实施例中不做限定。

可见，本申请实施例分布式系统，在某台业务处理设备宕机或者增加新的业务处理设备的时候，无需重新修改代码，即可实现业务数据范围的动态调整，使相应的业务数据由其它业务处理设备分担处理，这不仅提高了处理效率，而且不会影响到系统中其他设备的正常工作。

需要说明的是，以上所描述的系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

相应地，本申请实施例还提供了一种分布式系统业务处理方法，所述分布式系统包括控制设备和至少一个业务处理设备。

如图6所示，是本申请实施例分布式系统业务处理方法的流程图。

在该实施例中，所述方法包括以下基本步骤：

步骤601，业务处理设备向控制设备发送注册请求，以注册本业务处理设备的信息；

步骤602，所述控制设备接收到所述业务处理设备的注册请求后，为所述业务处理设备分配处理的数据范围；

步骤603，所述业务处理设备在注册成功后从所述控制设备获取自己处理的数据范围信息，根据所述数据范围信息从业务数据库中申领业务数据，并处理申领的业务数据。

为了使所述控制设备能够为业务处理设备分配有效的数据范围，在所述控制设备为所述业务处理设备分配处理的数据范围之前，还可以检查所述业务数据库中是否存在未被申领的业务数据，如果是，则执行步骤602，即为所述业务处理设备分配处理的数据范围。

当然，如果所述控制设备检查到所述业务数据库中没有未被申领的业务数据，则还可以向所述业务处理设备返回注册失败消息。

需要说明的是，在具体应用中，可以将所述分布系统中的业务处理设备的数量，以及每个业务处理设备处理的数据范围等信息配置在一个配置数据库中，比如，总共需要处理的数据范围为1～16，允许4个业务处理设备注册，这样，每个业务处理设备可以申领到的数据范围为4个。控制设备可以记录已分配的数据范围，并根据该记录即可知道所述业务数据库中是否还有未被申领的业务数据。

为了避免业务处理设备瞬时异常使得注册失败，从而影响其正常的运行，在本申请实施例中，所述方法还可进一步包括以下步骤：

所述业务处理设备按照第一预定周期向所述控制设备发送注册请求，并在从所述控制设备获取自己处理的数据范围信息后，停止向所述控制设备注册本业务处理设备的信息；

所述业务处理设备将业务数据库中自己已申领的业务数据标注上已申领标记、申请该业务数据的业务处理设备标识、以及申领时间，并在第一次从业务数据库中申领业务数据后，按照第二预定周期更新所述申领时间。

所述业务处理设备在更新所述申领时间失败后，可以按照第一预定周期向所述控制设备发送注册请求。

另外，为了保证各业务处理设备正确申领到自己处理的业务数据，并避免单个业务处理设备宕机后，该业务处理设备处理的相应业务数据能够及时由所述分布式系统中其它业务处理设备来处理，在本申请实施例中，所述控制设备还可以预先设置所述业务数据库中各数据范围的业务数据的申领保持时间。相应地，所述控制设备检查所述业务数据库中各数据范围的业务数据的申领保持时间，并在检查到所述申领保持时间过期后将所述申领保持时间对应的业务数据的已申领标记重置为未申领标记，以等待其他业务处理设备申领所述业务数据。

在业务数据量持续增长，导致所述分布式系统中当前业务处理设备的数量不足，需要增加新的业务处理设备的情况下，本申请实施例的分布式方法也可以实现动态调整，实现分布式环境下增加新的业务处理设备、自动调整配置参数等功能。相应地，所述方法还可进一步包括以下步骤：所述控制设备统计所述业务数据库中的业务数据量，并在所述业务数据量增长到需要增加业务处理设备时，停止为所述业务处理设备分配处理的数据范围，并在等待预定时间后，根据增加后业务处理设备的数量重新为所述业务处理设备分配处理的数据范围。

所述预定时间可以设置为与前面所述的各数据范围的业务数据的申领保持时间相同，比如1小时，这样可以更好地避免由于所述系统中业务处理设备数量的变更可能造成的数据重复处理，提高处理效率。

需要说明的是，上面提到的第一预定周期、第二预定周期、以及申领保持时间等信息可根据具体应用需要来设定，在本申请实施例中不做限定。

可见，本申请实施例分布式系统业务处理方法，在某台业务处理设备宕机或者增加新的业务处理设备的时候，无需重新修改代码，即可实现业务数据范围的动态调整，使相应的业务数据由其它业务处理设备分担处理，这不仅提高了处理效率，而且不会影响到系统中其他设备的正常工作。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

下面举例进一步详细说明应用本申请实施例分布式系统业务处理方法进行业务处理的过程。

比如，在淘宝评价系统中处理评价数据。

在评介系统中，将评价应用服务器作为业务处理设备，控制设备单独部署。

假设并行的评价应用服务器有4台，每个评价应用服务器并行处理线程为8。通过取模运算来分配各评价应用服务器需要处理的数据范围，配置取模因子为16。

在评价系统启动初始化的时候，评价应用服务器中的客户端主程序单元初始化注册单元，注册单元每隔5分钟向控制设备注册本机信息并申请数据范围，此时控制设备会到业务数据库中查询是否有未被申领的数据范围存在。

因为取模因子是16，所以总共可申领的数据范围为0～15，如果存在未被申领的数据范围，那么控制设备根据取模因子及并行的评价应用服务器数来计算当前每个评价应用服务器最多可以申请16/4＝4个数据范围。控制设备允许评价应用服务器注册成功，并将每个评价应用服务器可申领的四个数据范围的评价数据下发给该评价应用服务器。

评价应用服务器注册成功后，会初始化数据申领单元，并根据自己的并行处理线程数8来启动当前的数据处理线程池。数据申领单元根据得到的数据范围从业务数据库中申领相应的业务数据，并将这些业务数据标注上已申领标记、申领该业务数据的业务处理设备标识及申领时间。具体地，假设某一评价应用服务器申领的四个数据范围是0、1、2、3，则数据申领单元根据业务记录序列id对16进行取模，对于取模结果为0、1、2、3的业务记录则由该评价应用服务器处理，反之，则由其他评价应用服务器处理。该评价应用服务器申领到的业务数据将被发送给数据处理线程池，评价应用服务器的主程序单元分配相应的线程对这些业务数据进行处理。

在数据申领成功后，注册单元停止5分钟自动注册线程，启动30分钟自动更新线程，即每30分钟更新一次自己申领的数据上的标识信息。即只要评价应用服务器没有宕机，自动更新线程必须每过30分钟到控制设备来更新数据范围的申领时间，如果更新不成功，则自动停止评价应用服务器上的数据申领单元的数据申领，并重新启动5分钟自动注册线程，反之则继续处理。

假设各数据范围的业务数据的申领保持时间是1小时，如果评价应用服务器宕机了，其当前申领的数据范围内的业务数据可能存在没有被执行的。假设控制设备每过1小时扫描一次数据库中被申领数据范围的业务数据的申领时间是否已经超过1小时，如果已超过，则将这些业务数据上的已申领标识重新置为未申领标识，以等待评价应用服务器重新注册申领，或者由其他评价应用服务器来申领。

当数据增长量过大，需要重新调整取模因子及系统中评价应用服务器数量的时候，控制设备回收所有被分配的数据范围，比如将所有已被申领的业务数据上的标识重新置为未申领标识，并停止处理评价应用服务器自动注册，在等待1小时后，重新开启处理评价应用服务器自动注册功能。在重新开启该功能之前，假设需要增加1个评价应用服务器，即评价系统中的评价应用服务器总数应变为5，此时可以将取模因子从16调整为20，那么将会允许5个评价应用服务器注册成功，每个评价应用服务器可以处理的数据范围为20/5＝4。这样，通过控制设备对取模因子的调整，无需重新修改主程序代码，即可实现评价系统中对评价应用服务器分配数据量的调整，满足不同业务数据量处理的需求。

需要说明的是，上述注册单元的自动注册周期、数据申领单元的自动更新周期、以及申领保持时间等信息可根据具体应用需要来设定，在本申请实施例中不做限定。

在上述实施例中，优选通过取模运算得到评价应用服务器处理数据的范围。需要说明的是，在实际应用中，还可以采用其他方式来分配各评价应用服务器需要处理的数据范围，比如，在评价应用服务器注册成功后，控制设备从未分配的数据范围中任意选取一定范围的数据下发给该评价应用服务器，对此，本申请实施例不做限定。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。

本申请可用于众多通用或专用的计算系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序单元。一般地，程序单元包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序单元可以位于包括存储设备在内的本地和远程计算机存储介质中。

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种分布式系统，包括控制设备和至少一个业务处理设备，其特征在于： 

所述控制设备包括： 

接收单元，用于接收各业务处理设备的注册请求； 

分配单元，用于在所述接收单元接收到所述注册请求后为所述业务处理设备分配处理的数据范围； 

检查单元，用于在所述分配单元为所述业务处理设备分配处理的数据范围之前，检查业务数据库中是否存在未被申领的业务数据，如果是，则指示所述分配单元为所述业务处理设备分配处理的数据范围； 

所述业务处理设备包括： 

注册单元，用于向所述控制设备发送注册请求，以注册本业务处理设备的信息，并在注册成功后从所述控制设备获取自己处理的数据范围信息； 

数据申领单元，用于根据所述注册单元获取的数据范围信息从业务数据库中申领业务数据； 

执行单元，用于处理所述数据申领单元申领的业务数据。 

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

所述注册单元，具体用于按照第一预定周期向所述控制设备发送注册请求，并在从所述控制设备获取自己处理的数据范围信息后，停止向所述控制设备发送注册请求； 

所述数据申领单元，还用于将业务数据库中自己已申领的业务数据标注上已申领标记、申请该业务数据的业务处理设备标识、以及申领时间，并在第一次从业务数据库中申领业务数据后，按照第二预定周期更新所述申领时间。 

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

所述数据申领单元，还用于在更新所述申领时间失败后，通知所述注册单元按照第一预定周期向所述控制设备发送注册请求。 

4.根据权利要求3所述的系统，其特征在于，所述控制设备还包括： 

设置单元，用于设置所述业务数据库中各数据范围的业务数据的申领保持时间； 

数据维护单元，用于检查所述业务数据库中各数据范围的业务数据的申领保持时间，并在检查到所述申领保持时间过期后将所述申领保持时间对应的业务数据的已申领标记重置为未申领标记。 

5.根据权利要求1至4任一项所述的系统，其特征在于，所述控制设备还包括： 

统计单元，用于统计所述业务数据库中的业务数据量； 

所述分配单元，还用于在所述业务数据量增长到需要增加新的业务处理设备时，停止为所述业务处理设备分配处理的数据范围，并在等待预定时间后，根据增加后业务处理设备的数量重新为所述业务处理设备分配处理的数据范围。 

6.一种分布式系统业务处理方法，所述分布式系统包括控制设备和至少一个业务处理设备，其特征在于，所述方法包括： 

业务处理设备向控制设备发送注册请求，以注册本业务处理设备的信息； 

所述控制设备接收到所述业务处理设备的注册请求后，为所述业务处理设备分配处理的数据范围； 

其中，所述控制设备为所述业务处理设备分配处理的数据范围之前，还检查业务数据库中是否存在未被申领的业务数据，如果是，则执行为所述业务处理设备分配处理的数据范围的步骤； 

所述业务处理设备在注册成功后从所述控制设备获取自己处理的数据范围信息，根据所述数据范围信息从业务数据库中申领业务数据，并处理申领的业务数据。 

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

所述业务处理设备按照第一预定周期向所述控制设备发送注册请求，并在从所述控制设备获取自己处理的数据范围信息后，停止向所述控制设备注册本业务处理设备的信息； 

所述业务处理设备将业务数据库中自己已申领的业务数据标注上已申领标记、申请该业务数据的业务处理设备标识、以及申领时间，并在第一次从业务数据库中申领业务数据后，按照第二预定周期更新所述申领时间。 

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

所述业务处理设备在更新所述申领时间失败后，按照第一预定周期向所述控制设备发送注册请求。 

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

所述控制设备设置所述业务数据库中各数据范围的业务数据的申领保持时间； 

所述控制设备检查所述业务数据库中各数据范围的业务数据的申领保持时间，并在检查到所述申领保持时间过期后将所述申领保持时间对应的业务数据的已申领标记重置为未申领标记。 

10.根据权利要求6至9任一项所述的方法，其特征在于，所述方法还包括： 

所述控制设备统计所述业务数据库中的业务数据量，并在所述业务数据量增长到需要增加业务处理设备时，停止为所述业务处理设备分配处理的数据范围，并在等待预定时间后，根据增加后业务处理设备的数量重新为所述业务处理设备分配处理的数据范围。