CN108959548A - 业务请求的处理方法及装置 - Google Patents

Abstract

本说明书实施例提供一种业务请求的处理方法和装置，根据该方法的一种实施方式，对应于第一数据库处于不可写状态的情况，执行第一模式；其中，在第一模式下：在接收到第一业务请求时，根据第一业务请求，检测第二数据库中是否存在与第一业务请求相关的第一业务数据，若存在，则从第二数据库获取第一业务数据，否则，从第一数据库获取第一业务数据，然后，根据第一业务请求处理获取的第一业务数据，并根据处理结果对第二数据库进行更新。该实施方式可以提高业务处理的有效性。

Description

业务请求的处理方法及装置

技术领域

本说明书一个或多个实施例涉及计算机技术领域，尤其涉及通过计算机进行业务请求的处理方法和装置。

背景技术

随着计算机技术的发展，数据处理和数据存储往往是分开的，例如，业务服务器进行各种业务处理，所需要的业务数据和处理结果数据往往保存在本地或远程的数据库中。在高可用系统中，如果数据库一段时间，例如数据更新过程中，不能提供对外服务，则会对业务系统造成巨大影响。

对于很多非高可用系统，往往采用主用数据库和备用数据库(如ab表)切换的方法。然而，这种方法仍然可能有一段时间(例如1分钟)数据库处于不可用状态，或者数据更新的实时性不强。对于高可用系统，需要提供一种改进的方法，在主用数据库锁表时，提高业务处理的有效性。

发明内容

本说明书一个或多个实施例描述了一种方法和装置，可以解决背景技术提到的部分或全部问题。

根据第一方面，提供了一种业务请求的处理方法，包括：对应于第一数据库处于不可写状态的情况，执行第一模式；在第一模式下：响应于接收到第一业务请求，根据所述第一业务请求，检测第二数据库中是否存在与所述第一业务请求相关的第一业务数据；若存在，则从所述第二数据库获取所述第一业务数据，否则，从所述第一数据库获取所述第一业务数据；根据所述第一业务请求处理获取的所述第一业务数据，并根据处理结果对所述第二数据库进行更新。

根据一方面的实施例，所述方法还包括：对应于所述第一数据库处于可写状态，且预定条件未被满足的情况，执行第二模式；在第二模式下：响应于接收到第二业务请求，从所述第二数据库查找与所述第二业务请求相关的第二业务数据；在从所述第二数据库查找到所述第二业务数据的情况下，从所述第二数据库获取所述第二业务数据，根据所述第二业务请求处理所述第二业务数据，并根据处理结果更新所述第一数据库；以及，删除所述第二数据库中的第二业务数据。

在一个可能的设计中，所述方法还包括：对应于所述第一数据库处于可写状态，且所述预定条件被满足的情况，执行第三模式；在所述第三模式下：响应于接收到第三业务请求，根据所述第三业务请求，从所述第一数据库获取与所述第三业务请求相关的第三业务数据；根据所述第三业务请求处理获取的所述第三业务数据，并根据处理结果对所述第一数据库进行更新。

进一步地，在一个实施例中，所述预定条件包括以下至少一项：所述第二数据库中的业务数据条数不超过设定条数；第二模式运行时间超过预设时间段。

在一个实施例中，所述方法还包括：获取所述第二数据库中第二数据的第二最后操作时间；获取所述第一数据库中与所述第二数据对应的第一数据的第一最后操作时间；在所述第二最后操作时间晚于所述第一最后操作时间的情况下，用所述第二数据更新所述第一数据，以及，对所述第二数据库中的所述第二数据进行删除。

另一方面，所述方法还包括：在所述第二最后操作时间早于所述第一最后操作时间的情况下，生成数据错误的提示信息。

在一个实施例中，所述第一数据库包括可读可写数据库和至少一个只读数据库，各个只读数据库与所述可读可写数据库的数据一致；所述从所述第一数据库获取所述第一业务数据包括：从所述至少一个只读数据库中获取所述业务数据。

进一步地，根据一种实施方式，所述第二数据库与所述可读可写数据库结构一致，所述第二数据库的初始状态为空。

根据第二方面，提供一种业务请求的处理装置，所述装置配置为：对应于第一数据库处于不可写状态的情况，执行第一模式；在第一模式下：检测单元，配置为响应于接收到第一业务请求，根据所述第一业务请求，检测第二数据库中是否存在与所述第一业务请求相关的第一业务数据；获取单元，配置为所述检测单元的检测结果若为存在，则从所述第二数据库获取所述第一业务数据，否则，从所述第一数据库获取所述第一业务数据；更新单元，配置为根据所述第一业务请求处理获取的所述第一业务数据，并根据处理结果对所述第二数据库进行更新。

根据第三方面，提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第一方面的方法。

根据第四方面，提供了一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第一方面的方法。

通过本说明书实施例提供的方法和装置，对应于第一数据库处于不可写状态的情况，执行第一模式；其中，在第一模式下：在接收到第一业务请求时，根据第一业务请求，检测第二数据库中是否存在与第一业务请求相关的第一业务数据，若存在，则从第二数据库获取第一业务数据，否则，从第一数据库获取第一业务数据，然后，根据第一业务请求处理获取的第一业务数据，并根据处理结果对第二数据库进行更新。由于在第一数据库处于不可写状态时，用第二数据库代替第一数据库存储数据，而对于第二数据库中没有存储的业务数据，依然从第一数据库获取对应业务数据并将处理结果更新到第二数据库，对于业务请求而言，没有任何影响，从而可以提高业务处理的有效性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1示出本说明书披露的一个实施例的实施场景示意图；

图2示出根据一个实施例的业务请求的第一模式的方法流程图；

图3示出根据一个实施例的业务请求的第二模式的方法流程图；

图4示出根据一个实施例的业务请求的第三模式的方法流程图；

图5示出第一数据库从不可写到恢复正常的一个具体流程示意图；

图6示出根据一个实施例的用于业务请求的处理装置的示意性框图。

具体实施方式

下面结合附图，对本说明书提供的方案进行描述。

图1为本说明书披露的一个实施例的实施场景示意图。如图所示，计算平台将数据存储在数据库中，数据库至少包括第一数据库和第二数据库。其中，第一数据库是常用数据库。即正常状态下，计算平台接收到客户端发来的业务请求时，从第一数据库获取业务数据，对业务数据进行处理后，一方面将处理结果反馈至客户端，另一方面，根据处理结果更新第一数据库。其中，计算平台可以是为客户端应用(例如支付宝等)提供支持的服务器(例如支付宝服务器等)，其可以是具有一定计算能力的处理设备，或者设备集群。

当第一数据库不可写时，例如需要锁表或故障的情况下，计算平台可以将数据库连接修改为与第二数据库连接，并执行第一模式。该第一模式具体为：响应于接收到客户端的业务请求，计算平台先去第二数据库查找与业务请求相对应的业务数据，如果第二数据库里面没有，再去第一数据库查找相关业务数据；然后，计算平台根据业务请求对业务数据进行处理，并且由于第一数据库不可写，计算平台可以根据处理结果更新第二数据库。这样，业务请求处理结果数据就由第二数据库存储下来。在一个实施例中，第二数据库代替第一数据库时的初始状态是空。这样，第二数据库存储的所有数据都是代替第一数据库存储的。

对某一条业务数据而言，在其第一次被需要时，从第一数据库读出，并将处理结果写入了第二数据库，如果再次接收到同一业务请求，可以从第二数据库读出前一次处理后的业务数据进行处理，处理结果仍然可以写入第二数据库。如此，对于第一数据库的不可写状态，不会影响业务请求的处理，从而可以提高业务处理的有效性。

根据一个实施方式，第一数据库由不可写状态改变成可写状态时，例如锁表结束或者故障消除的情况下，计算平台可以将数据库连接重新修改为与第一数据库连接。

此时，在一方面的实施例中，对应于第一数据库处于可写状态，且预定条件(如第二数据库为空)未被满足的情况，计算平台可以执行第二模式：响应于接收到的业务请求，从第二数据库查找与该业务请求相关的业务数据，如果从第二数据库查找到相应业务数据，根据该业务请求处理相应业务数据，并根据处理结果更新第一数据库中相应的业务数据，同时，删除第二数据库中的相应业务数据。

另外，如果从第二数据库中没有查找到相应业务数据，则可以和正常状态一样，从第一数据库查找相应业务数据，进行处理后更新到第一数据库。如此，在第一数据库恢复使用后，可以先处于第一数据库和第二数据库的兼容模式，优先查找第二数据库，以免造成数据遗漏或混乱，使业务处理结果更准确。

根据另一方面的实施例，对应于第一数据库处于可写状态，且预定条件(如第二数据库为空)被满足的情况，计算平台可以执行第三模式：响应于接收到业务请求，根据该业务请求从第一数据库获取与该业务请求相关的业务数据，根据该业务请求处理获取的该业务数据，并根据处理结果对第一数据库进行更新。此时，恢复正常使用第一数据库，无需再去第二数据库检测业务数据，提高业务处理效率。

下面描述上述场景的具体执行过程。

图2示出根据一个实施例的业务请求的方法中第一模式的流程图。该方法的执行主体可以是任何具有计算、处理能力的系统、设备、装置、平台或服务器，例如图1所示的计算平台等。如图2所示，在该第一模式下执行以下步骤：步骤21，响应于接收到第一业务请求，根据第一业务请求，检测第二数据库中是否存在与第一业务请求相关的第一业务数据；步骤22，若存在，则从第二数据库获取第一业务数据，否则，从第一数据库获取第一业务数据；步骤23，根据第一业务请求处理获取的第一业务数据，并根据处理结果对第二数据库进行更新。

首先，在步骤21，响应于接收到第一业务请求，根据第一业务请求，检测第二数据库中是否存在与第一业务请求相关的第一业务数据。可以理解，这里的“第一”并不表示顺序或类别，而是为了表示业务请求与业务数据的对应关系。

通常，业务可以是需要处理的事务。例如，支付平台的转账业务、购物平台的商品查询业务，等等。业务请求可以是从本地或远程(如客户端)发送的请求。该请求可以包括业务内容等信息，例如，当业务请求是转账请求时，业务请求可以包括转账金额、收款账号等信息。

业务数据，往往是和业务相关联的数据。例如，当业务请求是转账请求时，业务数据可以包括请求转账的账户、账户余额、转账限额等信息。一般地，业务数据可以存储在第一数据库中。当第一数据库不可写时，业务数据也可以存储在第二数据库中。其中，和一条业务请求相关的业务数据可以是一条，也可以是多条。例如，A用户请求向B用户转账500元时，相关业务数据可以包括多条：A用户账户的余额、B用户账户、B用户账户的余额，等等。

可以理解，由于第一数据库不可写，前一次的业务数据写入的是第二数据库还是第一数据库并不确定。而第二数据库是替代第一数据库进行数据记录的，因此，第二数据库是比第一数据库更新的数据，可以先去检测第二数据库中是不是有与第一业务请求相关的第一业务数据。

步骤22，若第二数据库中存在第一业务数据，则从第二数据库获取第一业务数据，否则，从第一数据库获取第一业务数据。可以理解，当第二数据库存在与第一业务请求相关的第一业务数据，则表明第一数据库不可写后，相关业务数据更新到了第二数据库，此时，可以从第二数据库获取第一业务数据。如果第二数据库中不存在与第一业务请求相关的第一业务数据，则表明第一数据库不可写后，相关业务数据未更新到第二数据库，此时，仍然需要从第一数据库获取第一业务数据。

根据一个可能的实施方式，第一数据库可以包括可读可写数据库和至少一个只读数据库。其中，可读可写数据库通常用来记录数据，各个只读数据库与可读可写数据库的数据保持一致。即在正常工作状态下，可以从只读数据库读取第一业务数据，根据第一业务请求处理第一业务数据后写入可读可写数据库。各个只读数据库可以每间隔预定时间段(如0.1秒)检测可读可写数据库的数据是否更新，如果更新，则随之更新。如此，可以保持各个只读数据库与可读可写数据库的实时一致。如此，第一数据库不可写，就是可读可写数据库出现问题不能提供服务的情况，例如，可读可写数据库锁库、断电等。

可以理解，可读可写数据库和至少一个只读数据库可以设在一个设备上，也可以设在不同设备中，说明书实施例对此不作限定。至少在设在不同设备的情况下，当至少一个只读数据库中的部分不可用(如断电)，可以从其他只读数据库读取数据，并根据处理结果更新可读可写数据库，对业务请求的处理不受影响；当至少一个只读数据库全部不可用，可以从可读可写数据库读取数据，并根据处理结果更新可读可写数据库，对业务请求的处理不受影响；当可读可写数据库不可写，则启用第二数据库执行第一模式的流程，此时，从第一数据库获取第一业务数据实际上是从至少一个只读数据库中的一个里面获取的。

在一个实施例中，第二数据库可以与可读可写数据库的结构完全一致，且第二数据库的初始状态为空。如此，可以保证第二数据库当前只为第一数据库记录数据，而不会记录其他无关数据(如其他数据库数据)。

步骤23，根据第一业务请求处理获取的第一业务数据，并根据处理结果对第二数据库进行更新。可以理解，业务请求往往涉及对业务数据的处理。根据业务处理的结果，可以更新数据库存储内容。

举例而言，假设第一业务请求是转账请求，如A用户请求向B用户转账500元，此时，相关业务数据至少可以包括A用户账户的余额、B用户账户、B用户账户的余额。从第一数据库获取这些数据后，进行处理，例如，先判断A用户账户的余额是否大于500元，若大于，则从A用户账户的余额中减去500元，并将B用户账户的余额加上500元。A用户账户余额、B用户账户、B用户账户余额，都可以被存储在第二数据库中。

值得说明的是，在步骤22，第二数据库中也可能仅包含一部分的第一业务数据，则可以从第二数据库获取该一部分的第一业务数据，并从第一数据库获取其余相关业务数据。仍以第一业务请求为转账请求为例进行说明。在第一数据库不可用后，A用户向B用户转账500元，进行相关处理后，至少A用户账户余额、B用户账户、B用户账户余额被存储在第二数据库中。当B用户要向C用户转账200元时，第一业务请求为B用户要向C用户转账200元的转账请求，相关业务数据至少可以包括B用户账户的余额、C用户账户、C用户账户的余额。首先检测第二数据库，发现存在B用户账户的余额，则可以从第二数据库获取B用户账户的余额；之后，去第一数据库获取C用户账户和C用户账户的余额。对所获取的业务数据进行处理后根据处理结果更新第二数据库。

根据处理结果对第二数据库进行更新时，可以将用到的所有业务数据都更新到第二数据库，也可以只更新结果发生改变的业务数据，例如上述转账示例中A、B、C用户账户的余额，说明书实施例对此不作限定。

回顾以上过程，对于第一数据库的不可写状态，针对客户端发来的业务请求，可以先从第二数据库查找相应业务数据，查找不到的情况下从第一数据库获取，根据业务请求处理业务数据后更新到第二数据库，以供后续使用，用第二数据库代替第一数据库记录数据，对客户端用户而言，不会影响业务请求的处理，从而可以提高业务处理的有效性。

进一步地，对应于第一数据库处于可写状态，且预定条件未被满足的情况，执行第二模式。请参考图3，示出根据一个实施例的业务请求的方法中第二模式的流程图。该第二模式是针对第一数据库从以上不可写状态改变到可写状态，恢复正常状态之前的一种兼容状态。上述预设条件可以是用来限定是否可以执行正常模式的条件。预设条件例如可以是以下至少一种：第二数据库中的业务数据条数不超过设定条数(如0条)；第二模式运行时间超过预设时间段(如30分钟)；等等。

该第二模式包括：步骤31，响应于接收到第二业务请求，从第二数据库查找与第二业务请求相关的第二业务数据；步骤32，在从第二数据库查找到第二业务数据的情况下，从第二数据库获取第二业务数据，根据第二业务请求处理第二业务数据，并根据处理结果更新第一数据库；以及，步骤33，删除第二数据库中的第二业务数据。

在步骤31中，响应于接收到第二业务请求，从第二数据库查找与第二业务请求相关的第二业务数据。和“第一”类似地，这里的“第二”并不表示顺序或类别，而是为了表示业务请求与业务数据的对应关系。

可以理解，由于第一数据库恢复到可写状态，很多较新的数据存储在第二数据库中，因此，当接收到第二业务请求时，可以先从第二数据库查找相关的第二业务数据。

步骤32，在从第二数据库查找到第二业务数据的情况下，从第二数据库获取第二业务数据，根据第二业务请求处理第二业务数据，并根据处理结果更新第一数据库。该步骤和步骤22、步骤23类似，在此不再赘述。

值得说明的是，第二数据库中也可能只包含第二业务数据的一部分，此时，可以从第二数据库获取部分第二业务数据，并从第一数据库获取其余第二业务数据，根据第二业务请求处理第二业务数据，并根据处理结果更新第一数据库。

在从第二数据库中没有查找到第二业务数据的情况下，从第一数据库获取第二业务数据，根据第二业务请求处理第二业务数据，并根据处理结果更新第一数据库。

步骤33，删除第二数据库中的第二业务数据。可以理解，当从第二数据库中读出第二业务数据时，该第二业务数据经过处理被更新到第一数据库，第一数据库中的相应数据已经是最新数据，第二数据库中的第二业务数据已经被使用和更新，无需继续代替第一数据库记录。相反地，如果再接收到相似的第二业务请求，如果还是先从第二数据库查找相关的第二业务数据，可能获取到第二数据库中的非最新数据，影响处理结果的准确性。因此，在该步骤中，还需要把第二数据库中的第二业务数据删除。

值得说明的是，第二模式中的步骤33可以在步骤32之后执行，也可以和步骤32同步执行，说明书实施例对步骤执行顺序不作限定。

在一些可能的设计中，在执行第二模式的同时，还可以通过以下步骤将第二数据库中的业务数据逐条迁移到第一数据库：获取第二数据库中第二数据的第二最后操作时间；获取第一数据库中与第二数据对应的第一数据的第一最后操作时间；在第二最后操作时间晚于第一最后操作时间的情况下，用第二数据更新第一数据，以及，对第二数据库中的第二数据进行删除。

其中，“第二”和“第一”不表示数据的顺序，而是为了区分第二数据库和第一数据库的数据。“第一数据”和“第二数据”分别可以代表相对应的同一条数据，例如，B用户的账户余额，等等。因为第二数据库中的数据是在第一数据库不可写状态下，针对相应的业务请求进行处理，根据处理结果更新到第二数据库的，所以第二数据库中的数据的记录时间通常晚于第一数据库中相应时间，而第二数据库中的第二数据还可能再次被更新。因此，当第二数据的最后操作时间晚于第一数据的最后操作时间时，将第二数据更新到第一数据库，替换第一数据。

尽管如此，也不能完全确定第二数据的最后操作时间一定晚于第一数据的最后操作时间，例如，当读出一条第二数据处理一个业务请求时，刚好该判断该第二数据是否要迁回第一数据库，在读取到第二数据的最后操作时间后，业务请求处理完成，第一数据库中的第一数据被更新，这时又获取了第一数据的最后操作时间，此时，第二数据的最后操作时间将会早于第一数据的最后操作时间。在一个实施例中，针对第二数据的最后操作时间早于第一数据的最后操作时间这样的情况，可以生成数据错误的提示信息。该提示信息可以是语音信息、文字信息等等。还可以将错误提示信息统计记录，以供人工核查。

在一个实施例中，对于第二数据库中记载的一些第二数据，如数据操作记录，第一数据库中可能没有相应的第一数据，例如对于C用户账户的一条操作记录，“接收B用户的200元转账”等，还可以将第二数据直接迁移到第一数据库。

如此，可以将第二数据库中的数据迁回到第一数据库。以加快恢复正常模式的速度。

通过第二模式，同时使用第一数据库和第二数据库，优先查找第二数据库，以免造成数据遗漏或混乱，使业务处理结果更准确。

另一方面，对应于第一数据库处于可写状态，且预定条件被满足的情况，执行第三模式。请参考图4，示出根据一个实施例的业务请求的方法中第三模式的流程图。该第三模式对应于从之前的一种兼容状态恢复正常状态。

如图4所示，该第三模式包括：步骤41，响应于接收到第三业务请求，根据第三业务请求，从第一数据库获取与第三业务请求相关的第三业务数据；步骤42，根据第三业务请求处理获取的第三业务数据，并根据处理结果对第一数据库进行更新。和“第一”、“第二”类似地，这里的“第三”并不表示顺序或类别，而是为了表示业务请求与业务数据的对应关系。

根据以上描述可知，第三模式和正常状态基本一致，在此不在赘述。

根据一个实施方式，在第三模式下，如果第二数据库中的业务数据条数大于0，还可以继续执行第二模式中将第二数据库中的业务数据逐条迁移到第一数据库的步骤，在此不再赘述。

如此，通过第三模式，恢复正常使用第一数据库，无需再去第二数据库检测业务数据，提高业务处理效率。

请参考图5，图5给出了第一数据库从不可写到恢复正常的一个具体流程示意。初始时，执行正常模式，即和第一数据库交互；接着，当第一数据库不可写时，执行第一模式，从第一数据库或第二数据库读取数据处理后更新第二数据库；然后，第一数据库从不可写状态恢复到可写状态，执行第二模式，从第一数据库或第二数据库读取数据处理后更新第一数据库；接着，当预设条件满足后，执行第三模式，和第一数据库交互，恢复正常模式。其中，在第二模式和/或第三模式下，还可以同时执行将第二数据库中的业务数据逐条迁移到第一数据库的步骤。

根据另一方面的实施例，还提供一种业务请求的处理装置。图6示出根据一个实施例的用于业务请求的处理装置的示意性框图。如图6所示，用于业务请求的处理装置600至少配置为：对应于第一数据库处于不可写状态的情况，执行第一模式。装置600包括：检测单元61、获取单元62和更新单元63。其中，在第一模式下：检测单元61，配置为响应于接收到第一业务请求，根据第一业务请求，检测第二数据库中是否存在与第一业务请求相关的第一业务数据；获取单元62，配置为检测单元61的检测结果若为存在，则从第二数据库获取第一业务数据，否则，从第一数据库获取第一业务数据；更新单元63，配置为根据第一业务请求处理获取的第一业务数据，并根据处理结果对第二数据库进行更新。

根据一个实施方式，装置600还配置为：对应于第一数据库处于可写状态，且预定条件未被满足的情况，执行第二模式。

其中，在第二模式下：检测单元61，配置为响应于接收到第二业务请求，从第二数据库查找与第二业务请求相关的第二业务数据；更新单元63，配置为在从第二数据库查找到第二业务数据的情况下，从第二数据库获取第二业务数据，根据第二业务请求处理第二业务数据，并根据处理结果更新第一数据库；以及，第一删除单元(未示出)，配置为删除第二数据库中的第二业务数据。

根据再一个实施方式，装置600还配置为：对应于第一数据库处于可写状态，且预定条件被满足的情况，执行第三模式。

在第三模式下：获取单元62，配置为响应于接收到第三业务请求，根据第三业务请求，从第一数据库获取与第三业务请求相关的第三业务数据；更新单元63，配置为根据第三业务请求处理获取的第三业务数据，并根据处理结果对第一数据库进行更新。

在一个可能的设计中，预定条件可以包括以下至少一项：第二数据库中的业务数据条数不超过设定条数；第二模式运行时间超过预设时间段。

根据一个实施例，装置600还包括：时间获取单元(未示出)，配置为获取第二数据库中第二数据的第二最后操作时间；以及，获取第一数据库中与第二数据对应的第一数据的第一最后操作时间；更新单元63，还可以配置为在第二最后操作时间晚于第一最后操作时间的情况下，用第二数据更新第一数据；以及，第二删除单元(未示出)，配置为对第二数据库中的第二数据进行删除。

在一个实施例中，装置600还包括：提示单元(未示出)，配置为在第二最后操作时间早于第一最后操作时间的情况下，生成数据错误的提示信息。

根据一方面的实施例，第一数据库可以包括可读可写数据库和至少一个只读数据库，各个只读数据库与可读可写数据库的数据一致；获取单元62进一步配置为：从至少一个只读数据库中获取第一业务数据。

进一步地，在一个实施例中，第二数据库与可读可写数据库结构一致，第二数据库的初始状态为空。

值得说明的是，装置600与图2所示的方法实施例相对应，装置600的一些实施方式与图3、图4的方法实施例相对应，因此，图2、图3、图4中的相应描述也适应于装置600的相应部分，在此不再赘述。

通过以上装置，对于第一数据库的不可写状态，用第二数据库代替第一数据库记录数据，对客户端用户而言，不会影响业务请求的处理，从而可以提高业务处理的有效性。

根据另一方面的实施例，还提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行结合图2所描述的方法。

根据再一方面的实施例，还提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现结合图2所述的方法。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。

Claims (18)

1.一种业务请求的处理方法，所述方法包括：

对应于第一数据库处于不可写状态的情况，执行第一模式；

在第一模式下：

响应于接收到第一业务请求，根据所述第一业务请求，检测第二数据库中是否存在与所述第一业务请求相关的第一业务数据；

若存在，则从所述第二数据库获取所述第一业务数据，否则，从所述第一数据库获取所述第一业务数据；

根据所述第一业务请求处理获取的所述第一业务数据，并根据处理结果对所述第二数据库进行更新。

2.根据权利要求1所述的方法，其中，所述方法还包括：

对应于所述第一数据库处于可写状态，且预定条件未被满足的情况，执行第二模式；

在第二模式下：

响应于接收到第二业务请求，从所述第二数据库查找与所述第二业务请求相关的第二业务数据；

在从所述第二数据库查找到所述第二业务数据的情况下，从所述第二数据库获取所述第二业务数据，根据所述第二业务请求处理所述第二业务数据，并根据处理结果更新所述第一数据库；以及

删除所述第二数据库中的第二业务数据。

3.根据权利要求2所述的方法，其中，所述方法还包括：

对应于所述第一数据库处于可写状态，且所述预定条件被满足的情况，执行第三模式；

在所述第三模式下：

响应于接收到第三业务请求，根据所述第三业务请求，从所述第一数据库获取与所述第三业务请求相关的第三业务数据；

根据所述第三业务请求处理获取的所述第三业务数据，并根据处理结果对所述第一数据库进行更新。

4.根据权利要求2或3所述的方法，其中，所述预定条件包括以下至少一项：

所述第二数据库中的业务数据条数不超过设定条数；

第二模式运行时间超过预设时间段。

5.根据权利要求2或3所述的方法，其中，所述方法还包括：

获取所述第二数据库中第二数据的第二最后操作时间；

获取所述第一数据库中与所述第二数据对应的第一数据的第一最后操作时间；

在所述第二最后操作时间晚于所述第一最后操作时间的情况下，用所述第二数据更新所述第一数据，以及

对所述第二数据库中的所述第二数据进行删除。

6.根据权利要求5所述的方法，其中，所述方法还包括：

在所述第二最后操作时间早于所述第一最后操作时间的情况下，生成数据错误的提示信息。

7.根据权利要求1所述的方法，其中，所述第一数据库包括可读可写数据库和至少一个只读数据库，各个只读数据库与所述可读可写数据库的数据一致；

所述从所述第一数据库获取所述第一业务数据包括：

从所述至少一个只读数据库中获取所述第一业务数据。

8.根据权利要求7所述的方法，其中，所述第二数据库与所述可读可写数据库结构一致，所述第二数据库的初始状态为空。

9.一种业务请求的处理装置，所述装置配置为：

对应于第一数据库处于不可写状态的情况，执行第一模式；

在第一模式下：

检测单元，配置为响应于接收到第一业务请求，根据所述第一业务请求，检测第二数据库中是否存在与所述第一业务请求相关的第一业务数据；

获取单元，配置为所述检测单元的检测结果若为存在，则从所述第二数据库获取所述第一业务数据，否则，从所述第一数据库获取所述第一业务数据；

更新单元，配置为根据所述第一业务请求处理获取的所述第一业务数据，并根据处理结果对所述第二数据库进行更新。

10.根据权利要求9所述的装置，其中，所述装置还配置为：

对应于所述第一数据库处于可写状态，且预定条件未被满足的情况，执行第二模式；

在第二模式下：

所述检测单元，配置为响应于接收到第二业务请求，从所述第二数据库查找与所述第二业务请求相关的第二业务数据；

所述更新单元，配置为在从所述第二数据库查找到所述第二业务数据的情况下，从所述第二数据库获取所述第二业务数据，根据所述第二业务请求处理所述第二业务数据，并根据处理结果更新所述第一数据库；以及

第一删除单元，配置为删除所述第二数据库中的第二业务数据。

11.根据权利要求10所述的装置，其中，所述装置还配置为：

对应于所述第一数据库处于可写状态，且所述预定条件被满足的情况，执行第三模式；

在所述第三模式下：

所述获取单元，配置为响应于接收到第三业务请求，根据所述第三业务请求，从所述第一数据库获取与所述第三业务请求相关的第三业务数据；

所述更新单元，配置为根据所述第三业务请求处理获取的所述第三业务数据，并根据处理结果对所述第一数据库进行更新。

12.根据权利要求10或11所述的装置，其中，所述预定条件包括以下至少一项：

所述第二数据库中的业务数据条数不超过设定条数；

第二模式运行时间超过预设时间段。

13.根据权利要求10或11所述的装置，其中，所述装置还包括：

时间获取单元，配置为获取所述第二数据库中第二数据的第二最后操作时间；以及，获取所述第一数据库中与所述第二数据对应的第一数据的第一最后操作时间；

所述更新单元，配置为在所述第二最后操作时间晚于所述第一最后操作时间的情况下，用所述第二数据更新所述第一数据；以及

第二删除单元，配置为对所述第二数据库中的所述第二数据进行删除。

14.根据权利要求13所述的装置，其中，所述装置还包括：

提示单元，配置为在所述第二最后操作时间早于所述第一最后操作时间的情况下，生成数据错误的提示信息。

15.根据权利要求9所述的装置，其中，所述第一数据库包括可读可写数据库和至少一个只读数据库，各个只读数据库与所述可读可写数据库的数据一致；

所述获取单元进一步配置为：

从所述至少一个只读数据库中获取所述第一业务数据。

16.根据权利要求15所述的装置，其中，所述第二数据库与所述可读可写数据库结构一致，所述第二数据库的初始状态为空。

17.一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行权利要求1-8中任一项所述的方法。

18.一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现权利要求1-8中任一项所述的方法。