CN107015876A - 一种业务请求处理方法及装置 - Google Patents

Abstract

本申请公开了一种业务请求处理方法，用以解决现有技术中由于数据库故障导致与该数据库故障发生前所保存的业务数据相关的业务无法正常进行的问题。该业务请求处理方法包括：确定第一数据库中目标数据分片的状态；根据所述目标数据分片的状态，对业务请求进行处理，所述业务请求用于请求所述目标数据分片对其进行处理。本申请还公开了一种业务请求处理装置。

Description

一种业务请求处理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种业务请求处理方法及装置。

背景技术

随着计算机技术的发展，互联网极大地方便了人们的生活，互联网中进行的各种各样的业务，大多依赖于服务器提供的基础服务。服务器在接收到某个业务请求时，往往会响应于该业务请求，对主数据库执行数据库操作，但是由于服务器故障或者数据库故障等原因，导致服务器无法正常操作主数据库。

为了防止服务器无法操作主数据库而导致业务无法正常进行，可以通过故障切换(failover)功能，快速启用备用的服务器和备用数据库来接替工作，尽可能地减少对业务的影响。

在现有的故障切换技术中，主数据库出现任何故障时，都会弃用整个主数据库，然后启用备用数据库，由于备用数据库中并没有保存主数据库在故障前存储的业务数据，那么，与这些业务数据相关的业务，在启动备用数据库后将无法正常进行。

发明内容

本申请实施例提供一种业务请求处理方法，用以解决现有技术中由于数据库故障导致与该数据库故障发生前所保存的业务数据相关的业务无法正常进行的问题。

本申请实施例采用下述技术方案：

一种业务请求处理方法，包括：

确定第一数据库中目标数据分片的状态；

根据所述目标数据分片的状态，对业务请求进行处理，所述业务请求用于请求所述目标数据分片对其进行处理。

本申请实施例还提供一种业务请求处理装置，用以解决现有技术中由于数据库故障导致与该数据库故障发生前所保存的业务数据相关的业务无法正常进行的问题。

本申请实施例采用下述技术方案：

一种业务请求处理装置，包括：

确定单元，确定第一数据库中目标数据分片的状态；

请求处理单元，根据所述目标数据分片的状态，对业务请求进行处理，所述业务请求用于请求所述目标数据分片对其进行处理。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

通过确定第一数据库中目标数据分片的状态，然后根据确定的目标数据分片的状态，对业务请求进行处理，这里的业务请求为用于请求目标数据分片对其进行处理的请求。这样，当第一数据库中的部分数据分片处于故障状态时，可以用相应的故障处理方式处理该发生故障的数据分片，这样将不影响数据库中处于正常状态的数据分片的使用，避免了现有技术中由于数据库故障导致与该数据库故障发生前所保存的业务数据相关的业务无法正常进行的问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的一种业务请求处理方法的实现流程示意图；

图2为本申请实施例提供的LDC架构中的一种数据部署结构示意图；

图3a为本申请实施例提供的目标数据分片处于正常状态时，第一服务器和第二服务器之间的交互关系示意图；

图3b为本申请实施例提供的目标数据分片处于故障状态时，第一服务器和第二服务器之间的交互关系示意图；

图3c为本申请实施例提供的目标数据分片处于故障复原状态时，第一服务器和第二服务器之间的交互关系示意图；

图3d为本申请实施例提供的目标数据分片处于部分复原状态时，第一服务器和第二服务器之间的交互关系示意图；

图4为本申请实施例提供的一种业务请求处理方法的实现流程示意图；

图5为本申请实施例提供的一种业务请求处理装置的具体结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

本申请实施例中，可以根据数据库中各数据分片的状态，从数据分片的维度执行故障处理逻辑，来对针对各数据分片的业务请求进行处理，避免了现有技术中由于数据库故障导致与该数据库故障发生前所保存的业务数据相关的业务无法正常进行的问题。

为了便于理解本申请提供的方法，下面首先对现有的服务器业务请求处理方法进行简单说明，然后再详细介绍本申请提供的业务请求处理方法。

在逻辑数据中心(Logical Data Center，LDC)架构中，将数据按照一定的规则，部署到了不同的机房中。在LDC架构下，不同的机房往往位于不同的位置处，且不同的机房的位置距离较远，例如机房A在杭州，机房B可能会在深圳。

在正常情况下，各机房可以独立工作，各自通过自己的服务器对各自的数据库进行数据库操作，例如机房A的服务器a会处理自己接收到的业务请求，并根据该业务请求，对机房A的数据库α进行数据操作；机房B的服务器b会处理自己接收到的业务请求，并根据该业务请求，对机房B的数据库β进行数据操作。需要说明的是本申请实施例中所述服务器可以是基于单台计算设备搭建的服务器，也可以是基于多台计算设备搭建的服务器或服务器群。

为了便于后续描述，在本申请实施例中，将背景技术中所描述的主数据库称为第一数据库，将主数据库的备用数据库称为第二数据库。在数据库无故障时，对第一数据库执行数据操作的服务器称为第一服务器，在数据库故障时，对第二数据库执行数据操作的服务器称为第二服务器，即第二服务器可以是第一服务器的备用服务器。

在现有技术中，业务请求处理方法大多为数据库直切法，具体地，当服务器A对应的数据库α故障时，那么当数据库A的业务请求到达服务器A时，服务器会对该业务请求进行处理，并对数据库β进行与该业务请求相关的数据操作。而当故障复原时，服务器A又会直接根据接收到的业务请求，对数据库α进行数据操作。

然而，数据库直切法存在以下缺点：

1、如果服务器A和服务器B的地理位置距离较远时，那么在写数据库时耗时会非常严重；

2、由于数据库β中没有保存数据库α中的数据，因此在服务器A故障时，基于数据库α内的业务数据的业务，将会受到影响。

显然，该方法同样也存在背景技术中提到的问题，即在数据库故障时，会导致与该数据库故障发生前所保存的业务数据相关的业务无法正常进行的问题。

基于现有技术中由于数据库故障导致与该数据库故障发生前所保存的业务数据相关的业务无法正常进行的问题，本申请提供一种业务请求处理方法，以下结合附图，详细说明本申请实施例提供的技术方案。

本申请实施例提供的业务请求处理方法的执行主体可以是计算设备，例如服务器等等，此外该方法的执行主体还可以是实现该方法的软件本身。

为便于描述，下文以该方法的执行主体为实现该方法的服务器为例，对该方法的实施方式进行介绍。可以理解，该方法的执行主体为实现该方法的软件本身只是一种示例性的说明，并不应理解为对该方法的限定。

该方法的实现流程示意图如图1所示，包括下述步骤：

步骤S101：确定第一数据库中目标数据分片的状态；

数据分片，是数据库分区的一种，是按照某种数据划分维度，将数据库分成更小、更快、更容易管理的部分。例如，按照用户身份标识(Identity，ID)的最后两位进行划分，可以将数据分成100个数据分片。在LDC架构中，每个机房会承载一部分数据分片的数据，例如：机房A承载00-19的数据分片，机房B承载80-99的数据分片。

在现有技术中，当数据库中的某一部分故障时，比如某一个数据分片故障时，在进行故障切换时，将确认整个数据库为故障状态，然后使用备用数据库进行业务操作。这样，整个故障数据库中保存的业务数据都将无法使用。

在本申请实施例中，可以根据目标数据分片的状态，来对业务请求进行处理，那么可以预先将数据分片大致分为三种状态：正常状态、故障状态(failover)、故障复原状态(failback)。其中，所述正常状态，为与所述第一数据库对应的第一服务器能够根据业务请求对相应的数据分片进行正常操作的状态；所述故障状态，为所述第一服务器无法根据业务请求对相应的数据分片进行正常操作的状态；所述故障复原状态，为所述业务请求相应的数据分片的状态从故障状态切换至正常状态。当故障状态复原后，即为正常状态。

在数据库的日常使用中，导致数据分片的状态为故障状态的原因有很多，比如该数据分片硬件故障和/或软件故障，或者与该数据分片对应的服务器故障，或者该数据分片所在的网络故障，等等。

在实际应用中，可以通过分布式资源管理器(Distributed ResourceManagement，DRM)来推送每个数据分片的状态，进而服务器可以确定各数据分片的状态。具体地，当某个数据分片故障或者该数据分片对应的服务器故障时，则DRM会推送该数据分片的状态为故障状态；当该数据分片或者该数据分片对应的服务器故障恢复后，则DRM会推送该数据分片的状态为故障复原状态，此外，当需要回迁的数据的用户数量小于预定数量时，则DRM会推送数据分片为部分复原状态，当所有数据回迁完成后，推送数据分片状态为正常状态。

步骤S102：根据所述目标数据分片的状态，对业务请求进行处理，所述业务请求用于请求所述目标数据分片对其进行处理。

在确定目标数据分片的状态后，便可以在目标数据分片处于不同状态时，采用不同的处理方式，尽可能地减少目标数据分片故障时对业务的影响。为了便于理解本方案中对业务请求的处理方式，这里先以LDC架构为例，简单介绍下本申请的业务请求处理方法中，故障切换机制的基本工作原理。请参阅图2，为本例中的数据部署结构示意图，其中左侧为杭州机房中的数据分片Z1，右侧为深圳机房中的数据分片Z2。

在各数据分片状态均正常时，Z1的服务器会将属于自己分片的业务数据写入Z1中，Z2的服务器会将属于自己分片的业务数据写入Z2中，同时Z1中的业务数据会备份到Z1的备份数据库中。

在数据分片Z1出现故障时，属于数据分片Z1的业务流量会分配给深圳机房中的数据分片Z2。但是，Z1业务流量的业务数据，并不会写入到数据分片Z2中，原本属于数据分片Z1的数据，会通过Z2的服务器写入数据分片Z2的FO数据库中。对于数据分片Z1故障前的部分业务数据，可以从Z1的备份数据库中读取。

在数据分片Z1故障解决后，便可以将Z2的FO数据库中的数据恢复到Z1中。然后Z1和Z2即正常处理各自接收到的业务请求。

至此，便实现了一套最基本的故障转移机制，为了进一步减少数据库故障时对业务的影响，本申请对该故障转移机制做了进一步优化，下面，将详细描述本申请实施例中根据目标数据分片的状态，对业务请求进行处理的方式。

在目标数据分片处于正常状态时，对业务请求的处理方式如下：

在确定目标数据分片处于正常状态时，可以将对业务请求进行处理得到的业务数据存储至该目标数据分片中，并将业务数据备份到预设的第二数据库中。如图3a所示，为本申请实施例提供的第一服务器和第二服务器之间的交互关系示意图，这里的第二服务器可以是第一服务器的备用服务器，用于在第一服务器故障时，对原先分配给第一服务器的业务请求进行处理。同时第二服务器也可以处理分配给自己的业务请求，并将对业务请求进行处理得到的业务数据存储到第四数据库中。

在LDC架构中，可以在不同的机房之间对业务数据进行互相备份，比如，可以在深圳机房搭建杭州机房的备份数据库(第二数据库)，用来对杭州机房中第一数据库的业务数据进行备份。

在将业务数据备份到第二数据库中时，为了不影响第一服务器中业务的正常进行，可以将业务数据异步备份到第二数据库中。具体地，由于第一服务器在将业务数据进行保存后，最好是要将保存结果立刻返回，以便及时向用户反馈业务处理结果。但是，如果此时将业务数据同步保存到第二数据库中，会延长保存结果返回的时间，造成业务时间上的延迟。因此可以在等第一服务器将业务处理完毕后，再将该处理过程中的业务数据进行备份，即异步将业务数据进行备份。

具体备份的时机可以是在设定时间到达时，将业务数据备份至预设的第二数据库中。该设定时间可以是预设的某个时间点，也可以是在将业务数据保存到数据分片后，经过了预定时长时的时刻，比如可以是从将业务数据保存到目标数据分片时开始，经过了1分钟时。

为了防止在设定时间到达前没有备份的业务数据，在后续数据分片处于故障状态时，影响与没有备份的业务数据相关的业务。那么，可以在将业务数据保存到目标数据分片中时，将该业务数据的业务标识保存到预设的业务标识数据表中，该业务标识数据表的具体存储位置可以是第二数据库中的表，如图3a所示。这里所说的业务标识用于标识与业务数据对应的业务，例如，对于某笔交易而言，业务标识可以是该笔交易的订单号。

需要说明的是，当业务数据已经成功备份至第二数据库时，便可以将保存在业务标识数据表中的、业务数据对应的业务标识删除。这样便可以释放更多的存储空间。

基于在业务标识数据表中保存了异步备份的这段时间内，没有备份到第二数据库中的业务数据的业务标识，那么在数据分片为故障状态时，便可以根据业务标识数据表中的业务标识，确认该业务标识对应的业务已经发生过了。防止在设定时间到达前没有备份的业务数据，在后续数据分片处于故障状态时，影响与没有备份的业务数据相关的业务。

但是，在尝试将该业务数据的业务标识保存到业务标识数据表中后，如果保存失败，那么在数据分片为故障状态时，保存失败的业务数据对应的业务重复发生的话，可能会带来某些问题。例如，商家向用户发放了优惠券，买家在利用该优惠券买了某个商品后，该笔交易的业务数据没有被备份到第二数据库中，而且也没有记录到业务标识数据表中。这样，保存有该笔交易的数据分片发生故障时，买家便可以再次利用该优惠券进行购物，导致优惠券发行方或卖家的资产损失。

为了避免类似事件的发生，可以在当确定业务标识在业务标识数据表中存储失败时，确定在所述设定时间内所述业务标识对应的至少一个业务数据中包含的数据项的属性值之和，然后判断该属性值的和，是否超过了设定阈值。该设定阈值比如可以是可承受的资产损失的额度。如果超过了设定阈值，则触发该业务标识对应的业务请求处理失败，如果没有超过预设的阈值，则可以让该业务标识对应的业务成功。

本申请实施例中，当接收到的业务请求是与优惠券相关的业务时，可以在数据库故障时，实现对资产损失的控制。这里所说的优惠券比如可以是数据库中以数据形式保存的网上的红包、代金券等，优惠券可以用于网上购物、线下消费等各种场景。

在实际应用中，可以在业务请求到来时，在事务中注册事务同步器，事务同步器可以调用异地的服务，将当前业务请求的业务标识保存到业务标识数据表中。

在目标数据分片处于故障状态时，对业务请求的处理方式如下：

在确定目标数据分片处于故障状态时，当用于请求目标数据分片对其进行处理的请求到来时，对业务请求的处理流程示意图如图4所示，包括下述步骤：

步骤S201：将分配给目标数据分片的业务请求转发给第二服务器，指示第二服务器来处理该业务请求；

如图3b所示，为目标数据分片故障状态时，第一服务器和第二服务器之间的交互示意图。针对目标数据分片的业务请求，会转发至第二服务器，由第二服务器来处理。本申请实施例中，直接利用第二服务器来处理业务请求的方式，相对于现有技术中通过第一服务器远程操作第二数据库的方式，耗时较短，业务处理效率较高。

步骤S202：第二服务器判断该业务请求对应的数据库操作的操作类型；

具体判断操作类型的方式，可以是根据业务请求调用的数据库接口类型来判断。

步骤S203：若业务请求用于请求对数据执行更改操作，则查询业务标识数据表中是否存在该业务请求包含的业务标识；

步骤S204：如果存在该业务标识，表明该业务已经发生过了，只是业务数据还没有备份到第二数据库而已，则阻止该更改操作；

步骤S205：如果不存在该业务标识，则在第二数据库中对处理所述业务请求得到的业务数据进行幂等校验；

该幂等校验即判断该业务数据是否存在于第二数据库中。

步骤S206：若幂等校验成功，则阻止该数据库操作；

幂等校验成功，表明第二数据库中存在处理所述业务请求得到的业务数据，即该数据请求是历史的数据请求。

步骤S207：若幂等校验失败，则判断业务标识数据表中是否存在所述业务请求对应的业务标识；

幂等校验失败，表明第二数据库中不存在处理所述业务请求得到的业务数据，即该数据请求不是历史的数据请求。

步骤S208：如果用户标识数据表中不存在该用户标识，则在用户标识数据表中记录该业务请求的用户标识，并将处理所述业务请求得到的业务数据保存到第三数据库中；

这里的第三数据库，可以记录数据分片处于failover和failback期间的业务数据，也可称作FO数据库，用户标识数据表可以以用户的维度，记录在failover和failback期间的数据操作。

需要说明的是，这里所说的对数据执行更改操作，可以是对原有的业务数据进行更改，也可以是对业务数据进行写入。那么，如果该更改操作是对业务数据进行写入的操作，则直接对第三数据库执行该更改操作；如果该更改操作所要更改的数据存储于第三数据库中，则直接对第三数据库执行该更改操作；如果该更改操作所要更改的数据存储于第二数据库中，则将更改操作请求更改的数据搬迁到第三数据库中，然后在第三数据库中执行数据更改操作，防止在第二数据库中更改完数据后，与之前备份的数据混在同一数据库中，不方便将更改的业务数据进行回迁。

步骤S209：如果用户标识数据表中存在该用户标识，则无需在写入该用户标识，直接将该处理所述业务请求得到的业务数据保存到第三数据库中；

步骤S210：如果业务请求用于请求对数据执行查找操作，可以先查询业务标识数据表中是否存在该业务请求包含的业务标识；

步骤S211：如果用户标识数据表中不存在该用户标识，则表明在failover和failback期间没有该用户的业务数据写入，则只对第二数据库进行查找操作；

步骤S212：如果用户标识数据表中有该用户标识，则表明在failover和failback期间有该用户的业务数据写入，则对第二数据库和第三数据库执行查找操作。

在目标数据分片处于故障复原状态时，对业务请求的处理方式如下：

在确定目标数据分片处于故障复原状态(failback)时，表明此时第一服务器已经能够根据业务请求对目标数据分片进行数据操作，但是由于第三数据库中仍然有failover时保存的业务数据，那么，为了不影响与该部分业务数据相关的业务，第二服务器仍然可以根据业务请求对第三数据库进行数据操作。

这样，针对目标数据分片的业务请求有一部分会到达第一服务器，有一部分会到达第二服务器。如图3c所示，为目标数据分片故障复原状态时，第一服务器和第二服务器之间的交互示意图。具体地，当针对目标数据分片的业务请求到达第一服务器时，则查询用户标识数据表中，是否保存有该业务请求中携带的用户标识。如果没有，表明在failover和failback期间没有保存该用户标识对应的业务请求，则利用第一服务器对该业务请求进行处理，并针对目标数据分片执行数据操作；如果有，则将该业务请求转发至第二服务器，并指示第二服务器处理该业务请求。

当业务请求到达第二服务器时，判断该业务请求对应的数据库操作的操作类型。如果业务请求用于请求对数据执行查找操作，则查询用户标识数据表中，是否保存有该业务请求中携带的用户标识。如果包含，则对第二数据库和/或第三数据库执行查找操作，并将查找到的数据一并返回。如果没有业务请求携带的用户标识，则将业务请求转发至第一服务器，指示第一服务器处理该业务请求

如果到达第二服务器的该业务请求，用于请求对数据执行更改操作时，则查询业务标识数据表中是否存在该业务请求包含的业务标识。如果存在该业务标识，表明该业务已经发生过了，只是业务数据还没有备份到第二数据库而已，则阻止该更改操作；如果不存在该业务标识，则在第二数据库中对处理所述业务请求得到的业务数据进行幂等校验；

若幂等校验失败，表明该数据请求不是历史的数据请求，则判断用户标识数据表中是否存在所述业务请求携带的用户标识。如果不存在该用户标识，则将业务请求转发至第一服务器，并指示第一服务器处理该业务请求；如果存在该用户标识，则将处理所述业务请求得到的业务数据保存到第三数据库中。若幂等校验成功，表明该数据请求是历史的数据请求，则阻止该数据库操作。

在确定数据分片处于故障复原状态时，还可以根据用户标识数据表中的用户标识，按照用户维度将第三数据库中的业务数据迁移到目标数据分片中。具体地，可以分别将各用户标识对应的第三数据库中的业务数据，迁移到与各用户标识对应的数据分片中。并将已成功迁移的业务数据从第三数据库中删除，而且将已成功迁移的业务数据对应的用户标识，从用户标识数据表中删除。

在目标数据分片处于部分复原状态时，对业务请求的处理方式如下：

当用户标识数据表中的用户标识的数量小于预定数量时，此时数据分片处于部分复原状态，这意味着大部分用户的数据已经回迁完成。此时可以将第三数据库设置为禁止写入状态，避免第三数据库中还有数据写入，导致第三数据库中的数据一直回迁不完。

如图3d所示，为目标数据分片部分复原状态时，第一服务器和第二服务器之间的交互示意图。具体地，当针对目标数据分片的业务请求到达第一服务器时，查询用户标识数据表中，是否保存有该业务请求中携带的用户标识。如果没有，表明在failover和failback期间没有保存该用户标识对应的业务请求，或者该用户标识对应的业务请求已经回迁完成，则利用第一服务器对该业务请求进行处理；如果有，则将该业务请求转发至第二服务器，指示第二服务器处理该请求。

当业务请求到达第二服务器时，判断该业务请求对应的数据库操作的操作类型。如果业务请求用于请求对数据执行更改操作，则判断用户标识数据表中是否存在业务请求携带的用户标识。如果不存在该用户标识，则将业务请求转发至第一服务器，并指派第一服务器处理该业务请求；如果存在该用户标识，则阻止该数据库操作。

当所有数据回迁完成后，便可推送数据分片的状态为正常状态。

为了便于理解本方案目标数据分片处于不同状态时，第一服务器和第二服务器的主要工作状态，下面在表1中示出了目标数据分片处于不同状态时，第一服务器和第二服务器的主要工作状态。

目标数据分片状态	第一服务器	第二服务器
			正常状态	正常模式	正常模式
故障状态	目标数据分片不能读写	第三数据库读写
			故障复原状态	目标数据分片部分读写	第三数据库读写
部分复原状态	目标数据分片部分读写	第三数据库只读

表1

其中，当目标数据分片处于正常状态时，第一服务器和第二服务器均按照正常模式处理各自的业务请求，并将对业务请求处理得到的业务数据进行保存；

当目标数据分片处于故障状态时，第一服务器的目标数据分片故障，不能读写，此时由第二服务器处理业务请求，并在第三数据库进行业务数据的读写；

当目标数据分片处于故障复原状态时，由于目标数据分片已经恢复正常，但是部分数据还没有迁移回来，此时第一服务器处理部分业务请求，则目标数据分片部分读写，第二服务器也处理部分业务请求，第三数据库仍旧支持读写；

当目标数据分片处于部分复原状态时，由于目标数据分片已经恢复正常，但是部分数据还没有迁移回来，此时第一服务器的目标数据分片部分读写。同时为了防止第三数据库中持续有数据写入，导致数据一直迁移不完，则第三数据库只读。

本申请提供的业务请求处理方法，可以自动确定数据分片的状态，无需人工确定，效率较高，同时也防止人工推送的过程中容易造成数据丢失的问题。

通过确定第一数据库中目标数据分片的状态，然后根据确定的目标数据分片的状态，对业务请求进行处理，这里的业务请求为用于请求目标数据分片对其进行处理的请求。这样，当第一数据库中只有部分数据分片处于故障状态时，可以用相应的故障处理方式处理该部分数据分片，不会影响到数据库中的正常数据分片的使用，避免了现有技术中数据库出现任何故障时，会导致与故障数据库中的所有业务数据相关的业务无法正常进行的问题。

另外，基于数据分片维度的业务请求处理方法，也可以应用于日常故障模拟，这样，开发人员可以单独准备某个数据分片进行故障模拟，而不必对整个数据库进行故障模拟，防止故障模拟时对正常业务造成的影响。

另外，基于本申请的业务请求处理方法，也可以支持服务器集群断网这样的机房级故障。

需要说明的是，本申请实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。

以上为本申请实施例提供的业务请求处理方法，基于同样的思路，本申请实施例还提供相应的业务请求处理装置，如图5所示，具体包括：

确定单元301，确定第一数据库中目标数据分片的状态；

请求处理单元302，根据所述目标数据分片的状态，对业务请求进行处理，所述业务请求用于请求所述目标数据分片对其进行处理。

上述装置实施例的具体工作流程是，首先，确定单元301确定第一数据库中目标数据分片的状态，然后请求处理单元302，根据所述目标数据分片的状态，对业务请求进行处理。

本申请实施例中，业务请求处理装置的具体实施方式有很多种，在一种实施方式中，所述目标数据分片的状态，包括下述至少一种：正常状态、故障状态、故障复原状态，其中：

所述正常状态，为与所述第一数据库对应的第一服务器能够根据业务请求对相应的数据分片进行正常操作的状态；

所述故障状态，为所述第一服务器无法根据业务请求对相应的数据分片进行正常操作的状态；

所述故障复原状态，为所述业务请求相应的数据分片的状态从故障状态切换至正常状态。

在一种实施方式中，若所述目标数据分片处于正常状态，则请求处理单元302，将处理所述业务请求得到的业务数据存储至所述目标数据分片中，并将所述业务数据备份到预设的第二数据库中。

为了防止在数据库故障时，与尚未备份的业务数据相关的业务无法正常进行，在一种实施方式中，所述装置还包括业务标识保存单元203，在将所述业务数据备份到预设的第二数据库中之前，将所述业务数据的业务标识保存到业务标识数据表中；

为了防止同步备份影响对业务请求的处理速度，在一种实施方式中请求处理单元302，在设定时间到达时，将所述业务数据备份至预设的第二数据库中。

在一种实施方式中，所述装置还包括阈值单元204，在将所述业务数据的业务标识保存到业务标识数据表中时，当确定所述业务标识在所述业务标识数据表中存储失败时，确定在所述设定时间内所述业务标识对应的至少一个业务数据中包含的数据项的属性值之和；

在确定所述属性值之和大于设定阈值时，触发所述业务标识对应的业务请求处理失败。

在一种实施方式中，所述装置还包括业务标识删除单元205，在将所述业务数据备份至预设的第二数据库中之后，当所述业务数据成功备份至所述第二数据库时，将保存至所述业务标识数据表中的、所述业务数据对应的所述业务标识删除。

在一种实施方式中，请求处理单元302，将所述业务请求转发至第二服务器，指示所述第二服务器处理所述业务请求。

在一种实施方式中，若所述业务请求用于请求对数据执行更改操作，则当所述业务标识数据表中不存在所述业务请求对应的业务标识，且所述第二数据库对处理所述业务请求得到的业务数据的幂等校验通过，且预设的用户标识数据表中不存在所述业务请求中携带的用户标识时，请求处理单元302，将处理所述业务请求得到的业务数据保存到第三数据库中，并在预设的用户标识数据表中记录所述业务请求中携带的用户标识。

在一种实施方式中，若所述业务请求用于请求对数据执行查找操作，则请求处理单元302，对所述第二数据库和/或所述第三数据库执行查找操作。

在一种实施方式中，若所述数据分片处于故障复原状态，则请求处理单元302，根据所述目标数据分片的状态，对业务请求进行处理，具体包括：

当所述业务请求到达第一服务器时，若用户标识数据表中包含所述业务请求中携带的用户标识，则将所述业务请求转发至第二服务器，并指示第二服务器处理该业务请求；

若用户标识数据表中未包含所述业务请求中携带的用户标识，则利用所述第一服务器对所述业务请求相应的所述目标数据分片执行数据操作。

在一种实施方式中，若所述数据分片处于故障复原状态，则请求处理单元302，当所述业务请求到达第二服务器，且所述业务请求用于请求对数据执行查找操作时，若所述用户标识数据表中，保存有所述业务请求携带的用户标识，则对所述第二数据库和/或所述第三数据库执行查找类操作；

若所述用户标识数据表中，没有所述业务请求携带的用户标识，则将业务请求转发至第一服务器，指示所述第一服务器处理所述业务请求。

在一种实施方式中，若所述数据分片处于故障复原状态，则请求处理单元302，根据所述目标数据分片的状态，对业务请求进行处理，具体包括：

当所述业务请求到达第二服务器，且所述业务请求用于请求对数据执行更改操作时，若所述用户标识数据表中包含所述业务请求携带的用户标识；则对所述第三数据库执行数据更改操作；

若所述用户标识数据表中不包含所述业务请求携带的用户标识，则将业务请求转发至第一服务器，并指示第一服务器处理该业务请求。

在一种实施方式中，若所述数据分片处于故障复原状态，所述装置包括数据迁移单元206，根据所述用户标识数据表中的用户标识，分别将各用户标识对应的第三数据库中的业务数据，迁移到与各用户标识对应的数据分片中。

在一种实施方式中，所述装置还包括，用户标识删除单元207，将已成功迁移的业务数据对应的用户标识，从用户标识数据表中删除。

在一种实施方式中，所述装置还包括数据库操作阻止单元208，当所述用户标识数据表中的用户标识的数量小于预定数量时，当所述业务请求到达第二服务器，且所述业务请求用于请求对数据执行更改操作时，若所述用户标识数据表中包含所述业务请求携带的用户标识，则阻止该数据库操作；

若所述用户标识数据表中不包含所述业务请求携带的用户标识，则将业务请求转发至第一服务器，并指派第一服务器处理所述业务请求。

通过确定第一数据库中目标数据分片的状态，然后根据确定的目标数据分片的状态，对业务请求进行处理，这里的业务请求为用于请求目标数据分片对其进行处理的请求。这样，当第一数据库中只有部分数据分片处于故障状态时，可以用相应的故障处理方式处理该部分数据分片，不会影响到数据库中的正常数据分片的使用，避免了现有技术中数据库出现任何故障时，会导致与故障数据库中的所有业务数据相关的业务无法正常进行的问题。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

Claims (20)

1.一种业务请求处理方法，其特征在于，包括：

确定第一数据库中目标数据分片的状态；

根据所述目标数据分片的状态，对业务请求进行处理，所述业务请求用于请求所述目标数据分片对其进行处理。

2.如权利要求1所述方法，其特征在于，所述目标数据分片的状态，包括下述至少一种：正常状态、故障状态、故障复原状态，其中：

所述正常状态，为与所述第一数据库对应的第一服务器能够根据业务请求对相应的数据分片进行正常操作的状态；

所述故障状态，为所述第一服务器无法根据业务请求对相应的数据分片进行正常操作的状态；

所述故障复原状态，为所述业务请求相应的数据分片的状态从故障状态切换至正常状态。

3.如权利要求2所述方法，其特征在于，若所述目标数据分片处于正常状态，则根据所述目标数据分片的状态，对业务请求进行处理，具体包括：

将处理所述业务请求得到的业务数据存储至所述目标数据分片中，并将所述业务数据备份到预设的第二数据库中。

4.如权利要求3所述方法，其特征在于，在将所述业务数据备份到预设的第二数据库中之前，所述方法还包括：

将所述业务数据的业务标识保存到业务标识数据表中；

将所述业务数据备份到预设的第二数据库中，包括：

在设定时间到达时，将所述业务数据备份至预设的第二数据库中。

5.如权利要求4所述方法，其特征在于，在将所述业务数据的业务标识保存到业务标识数据表中时，所述方法还包括：

当确定所述业务标识在所述业务标识数据表中存储失败时，确定在所述设定时间内所述业务标识对应的至少一个业务数据中包含的数据项的属性值之和；

在确定所述属性值之和大于设定阈值时，触发所述业务标识对应的业务请求处理失败。

6.如权利要求4所述方法，其特征在于，在将所述业务数据备份至预设的第二数据库中之后，所述方法还包括：

当所述业务数据成功备份至所述第二数据库时，将保存至所述业务标识数据表中的、所述业务数据对应的所述业务标识删除。

7.如权利要求2所述方法，其特征在于，若所述目标数据分片处于故障状态，则根据所述目标数据分片的状态，对业务请求进行处理，具体包括：

将所述业务请求转发至第二服务器，指示所述第二服务器处理所述业务请求。

8.如权利要求7所述方法，其特征在于，指示所述第二服务器处理所述业务请求，具体包括：

若所述业务请求用于请求对数据执行更改操作，则当所述业务标识数据表中不存在所述业务请求对应的业务标识，且所述第二数据库不存在处理所述业务请求得到的业务数据，且预设的用户标识数据表中不存在所述业务请求中携带的用户标识时，将处理所述业务请求得到的业务数据保存到第三数据库中，并在预设的用户标识数据表中记录所述业务请求中携带的用户标识。

9.如权利要求8所述方法，其特征在于，指示所述第二服务器处理所述业务请求，具体包括：

若所述业务请求用于请求对数据执行查找操作，则对所述第二数据库和/或所述第三数据库执行查找操作。

10.如权利要求2或9所述方法，其特征在于，若所述目标数据分片处于故障复原状态，则根据所述目标数据分片的状态，对业务请求进行处理，具体包括：

当所述业务请求到达第一服务器时，若用户标识数据表中包含所述业务请求中携带的用户标识，则将所述业务请求转发至第二服务器，并指示第二服务器处理该业务请求；

若用户标识数据表中未包含所述业务请求中携带的用户标识，则利用所述第一服务器处理所述业务请求。

11.如权利要求2或9所述方法，其特征在于，若所述目标数据分片处于故障复原状态，则根据所述目标数据分片的状态，对业务请求进行处理，具体包括：

当所述业务请求到达第二服务器，且所述业务请求用于请求对数据执行查找操作时，若所述用户标识数据表中存在所述业务请求携带的用户标识，则对所述第二数据库和/或所述第三数据库执行查找操作；

若所述用户标识数据表中不存在所述业务请求携带的用户标识，则将业务请求转发至第一服务器，指示所述第一服务器处理所述业务请求。

12.如权利要求2或9所述方法，其特征在于，若所述目标数据分片处于故障复原状态，则根据所述目标数据分片的状态，对业务请求进行处理，具体包括：

当所述业务请求到达第二服务器，且所述业务请求用于请求对数据执行更改操作时，若所述用户标识数据表中存在所述业务请求携带的用户标识；则将处理所述业务请求得到的业务数据保存到第三数据库中；

若所述用户标识数据表中不存在所述业务请求携带的用户标识，则将业务请求转发至第一服务器，并指示第一服务器处理该业务请求。

13.如权利要求2、10、11和12任一项所述方法，其特征在于，若所述目标数据分片处于故障复原状态，所述方法还包括：

根据所述用户标识数据表中的用户标识，分别将各用户标识对应的第三数据库中的业务数据，迁移到与各用户标识对应的数据分片中。

14.如权利要求13所述方法，其特征在于，所述方法还包括：

当至少一个用户标识对应的第三数据库中的业务数据已完成迁移时，将已完成迁移的所述用户标识从用户标识数据表中删除。

15.如权利要求14所述方法，其特征在于，当所述用户标识数据表中的用户标识的数量小于预定数量时，所述方法还包括：

当所述业务请求到达第二服务器，且所述业务请求用于请求对数据执行更改操作时，若所述用户标识数据表中包含所述业务请求携带的用户标识，则阻止更改操作；

若所述用户标识数据表中不包含所述业务请求携带的用户标识，则将业务请求转发至第一服务器，并指示所述第一服务器处理所述业务请求。

16.一种业务请求处理装置，其特征在于，包括：

确定单元，确定第一数据库中目标数据分片的状态；

请求处理单元，根据所述目标数据分片的状态，对业务请求进行处理，所述业务请求用于请求所述目标数据分片对其进行处理。

17.如权利要求16所述装置，其特征在于，所述目标数据分片的状态，包括下述至少一种：正常状态、故障状态、故障复原状态，其中：

所述正常状态，为与所述第一数据库对应的第一服务器能够根据业务请求对相应的数据分片进行正常操作的状态；

所述故障状态，为所述第一服务器无法根据业务请求对相应的数据分片进行正常操作的状态；

所述故障复原状态，为所述业务请求相应的数据分片的状态从故障状态切换至正常状态。

18.如权利要求16所述装置，其特征在于，若所述目标数据分片处于正常状态，则请求处理单元，将处理所述业务请求得到的业务数据存储至所述目标数据分片中，并将所述业务数据备份到预设的第二数据库中。

19.如权利要求16所述装置，其特征在于，若所述目标数据分片处于故障状态，则请求处理单元，将所述业务请求转发至第二服务器，指示所述第二服务器处理所述业务请求。

20.如权利要求16所述装置，其特征在于，若所述目标数据分片处于故障复原状态，所述装置还包括：

迁移单元，根据所述用户标识数据表中的用户标识，分别将各用户标识对应的第三数据库中的业务数据，迁移到与各用户标识对应的数据分片中。