CN105574020A - 一种数据库操作方法和装置 - Google Patents

Abstract

本申请实施例公开了一种数据库操作方法和装置。其中，第一数据库保存业务请求记录，第二数据库(包括一个主库和至少一个备库)保存业务数据；该方法包括：当主库不可用时，根据第一数据库中的业务请求记录统计在备库可信时间临界点之后提交的业务请求，将统计的业务请求对应的账号作为备库不可处理账号，以主库不可用的初始时间点为预设时间段的终止点，起始点即为备库可信时间临界点；判断当前业务请求对应的账号是否为备库不可处理账号；如果是，拒绝当前业务请求；如果否，接受当前业务请求，并根据当前业务请求对备库进行操作。通过本申请，可以缓解甚至避免在主库和备库进行切换时而出现的应用服务不可用的问题。

Description

一种数据库操作方法和装置

技术领域

本申请涉及数据库领域，特别是涉及一种数据库操作方法和装置。

背景技术

在互联网技术的应用场景中，应用服务不可用是非常敏感的问题。一方面，应用服务不可用会让用户体验急剧变差，甚至让用户产生一定的恐慌；另一方面，应用服务不可用也会给用户或者服务提供方带来经济损失，特别是一些对实时性有要求的业务，如，各类金融业务。

有很多因素都可能导致应用服务不可用，例如，数据库故障或数据库升级(包括软件升级和磁盘升级)等。为了避免因数据库故障或升级等因素而导致应用服务不可用，一般需要对数据库做备份处理。也就是说，在系统中，数据库除了包括有一个主库之外，还要包括有至少一个备库，在主库可用的情况下，应用服务器通过对主库进行操作来完成应用服务。而在主库不可用的情况下，其中一个备库被启动，应用服务器通过对备库进行操作来继续完成应用服务。

在实现本申请的过程中，本申请的发明人发现现有技术中至少存在如下问题：由于备库中的数据与主库中的数据不是同步的，而是存在一定的数据延迟时间，因此，在备库被启动之后，并不能立刻对备库进行操作，而需要先将备库中缺失的数据写入到备库中，使备库与主库中的数据达到完全一致，即，主库与备库之间需要进行切换，而该切换过程需要花费一定的时间。也就是说，从备库被启动开始到真正地被操作，应用服务器还需要等待一段时间，通常，这段时间为10～15分钟。而对于一些有实时性要求的业务来说，这段时间是无法接受的。

发明内容

为了解决上述技术问题，本申请实施例提供了一种数据库操作方法和装置，以缓解甚至避免在主库和备库进行切换时而出现的应用服务不可用的问题。

本申请实施例公开了如下技术方案：

一种数据库操作方法，第一数据库保存业务请求记录，第二数据库保存业务数据，所述第二数据库包括一个主库和至少一个备库；所述方法包括：

当主库不可用时，根据第一数据库中的业务请求记录统计在备库可信时间临界点之后提交的业务请求，将统计的业务请求所对应的账号作为备库不可处理账号，其中，以主库不可用的初始时间点为预设时间段的终止点，起始点即为所述备库可信时间临界点，所述预设时间段的时长大于或等于备库与主库之间的数据延迟时间；

判断当前业务请求所对应的账号是否为所述备库不可处理账号；

如果是，拒绝当前业务请求；

如果否，接受当前业务请求，并根据当前业务请求对备库进行操作。

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

在拒绝当前业务请求之前，判断当前业务请求针对的业务类型是否为预设业务类型；

拒绝当前业务请求为：

如果当前业务请求针对的业务类型不是预设业务类型，拒绝当前业务请求。

进一步优选的，所述方法还包括：

如果当前业务请求针对的业务类型是预设业务类型，接受当前业务请求，并根据当前业务请求对备库进行操作。

优选的，所述备库为只允许进行读取操作的数据库；

所述根据当前业务请求对备库进行操作为：

根据当前业务请求对备库进行读取操作。

进一步优选的，所述方法还包括：根据当前业务请求对第三数据库进行写入操作，其中，第三数据库为允许进行写入操作的数据库。

一种数据库操作装置，其特征在于，第一数据库保存业务请求记录，第二数据库保存业务数据，所述第二数据库包括一个主库和至少一个备库；所述装置包括：

统计单元，用于当主库不可用时，根据第一数据库中的业务请求记录统计备库可信时间临界点之后提交的业务请求，将统计的业务请求所对应的账号作为备库不可处理账号，其中，以主库不可用的初始时间点为预设时间段的终止点，起始点即为所述备库可信时间临界点，所述预设时间段的时长大于或等于备库与主库之间的数据延迟时间；

第一判断单元，用于判断当前业务请求所对应的账号是否为所述备库不可处理账号；

请求拒绝单元，用于如果当前业务请求所对应的账号是所述备库不可处理账号，拒绝当前业务请求。

第一操作单元，用于如果当前业务请求所对应的账号不是备库不可处理账号，接受当前业务请求，并根据当前业务请求对备库进行操作。

优选的，所述装置还包括：

第二判断单元，用于在所述拒绝请求单元拒绝当前的业务请求之前，判断当前业务请求针对的业务类型是否为预设业务类型；

所述请求拒绝单元用于，如果当前业务请求针对的业务类型不是预设业务类型，拒绝当前业务请求。

进一步优选的，所述第一操作单元还用于，如果当前业务请求针对的业务类型是预设业务类型，接受当前业务请求，并根据当前业务请求对备库进行操作。

优选的，所述备库为只允许进行读取操作的数据库；

所述第一操作单元用于，根据当前业务请求对备库进行读取操作。

进一步优选的，所述装置还包括：

第二操作单元，用于根据当前业务请求对第三数据库进行写入操作，其中，第三数据库为允许进行写入操作的数据库。

由上述实施例可以看出，与现有技术相比，本申请的优点在于：

当业务数据所在的第二数据库的主库不可用时，在主库和其备库的切换过程中，可以先确定备库不可处理账号，即，对于备库不可处理账号下的业务请求来说，备库中的数据是不可信的。而除备库不可处理账号之外的账号为备库可处理的账号，即，对于备库可处理账号下的业务请求来说，备库中的数据是可信的。因此，对于备库可处理账号下的业务请求，可以根据该业务请求直接对备库进行操作。这样就可以保证在主库和备库的切换过程中，应用服务仍然是可用的，并不会因此而中断，缓解甚至避免了在主库和备库进行切换时而出现的应用服务不可用的问题。

附图说明

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

图1示意性地示出了本发明的实施方式可以在其中实施的示例性应用场景；

图2为本申请提供的一种数据库操作方法的一个实施例的流程图；

图3为本申请中的估算备库可信时间临界点的原理示意图；

图4为本申请中第一数据库的内部结构示意图；

图5为本申请中第二数据库的内部结构示意图；

图6为本申请提供的一种数据库操作方法的另一个实施例的流程图；

图7为本申请提供的一种数据库操作装置的一个实施例的结构图；

图8为本申请提供的一种数据库操作装置的另一个实施例的结构图。

具体实施方式

由于备库与主库之间仅存在几秒钟的数据延迟，因此，可以确定的是，当主库因为各种原因而导致不可用时，备库中的绝大部分数据与主库中的数据是一致的，为了便于后面的描述，将这一部分数据称为可信数据，而只有小部分数据(即，备库需要与主库进行同步的数据)是与主库中的数据不一致的，为了便于后面的描述，将这一部分数据称为不可信数据。

如果在主库和备库进行切换的过程中，可以充分利用备库中的可信数据，使应用服务器可以通过对备库中的可信数据进行操作来完成应用服务，就可以缓解甚至避免由于主库和备库切换而导致的应用服务不可用的问题。

本申请实施例提供了一种数据库操作方法和装置。在本申请实施例中，根据备库与主库之间的数据延迟时间设置一个预设时间段，使该预设时间段的时长大于或等于备库与主库之间的数据延迟时间。当主库不可用时，以主库不可用的初始时间点为该预设时间段的终止点，起始点即为备库可信时间临界点，如果在该临界点之前，应用服务器因响应某些账号下的业务请求而对主库进行了操作，当主库不可用时，对于这些账号下的操作数据，备库很有可能已经完成了与主库之间的数据同步，如果在该临界点之后，应用服务器因响应某些账号下的业务请求而对主库进行了操作，当主库不可用时，对于这些账号的操作数据，备库很有可能还没来得及与主库进行数据同步。例如，账户A下有余额100元，在进行了一次提款金额为100元的提款操作后，在主库中，账户A的余额变为0元，而由于备库还没有来得与主库进行数据同步，因此，在备库中，账户A的余额仍然为100元。如果直接以备库中的100元作为账户A的可用余额，就会导致业务处理错误。

因此，本申请实施例先统计出从该临界点开始提交给应用服务器的业务请求，然后将这部分业务请求所对应的账号作为备库不可处理账号。可以理解的是，如果应用服务器因响应这部分账号下的业务请求而对主库进行了操作，当主库不可用时，对于这部分账号的操作数据，备库很有可能还没来得及与主库进行数据同步。也就是说，针对这部分账号的操作数据，备库很有可能存在数据不可信的问题。最后，当在主库和备库完成切换之前对备库进行操作时，需要确定每个业务请求所对应的账号是否为备库不可处理账号，如果是，就要拒绝该业务请求，如果否，就可以根据该业务请求对备库进行相应的操作。

在本申请实施例中，并不限定导致主库不可用的具体因素。也就是说，主库可以因为各种因素而导致不可用，例如，主库可以因故障而不可用，也可以因软件或磁盘升级而不可用。

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图对本申请实施例进行详细描述。

首先参考图1，图1示意性地示出了本发明的实施方式可以在其中实施的示例性应用场景。其中，以金融业务为例，客户端10向应用服务器20发送针对账号A的存款请求11，作为响应，应用服务器20先将存款请求11的相关记录作为记录31保存在第一数据库30中(在第一数据库30中保存有所有业务请求的记录)，然后再根据存款请求11执行相应的存款操作，并更新保存在第二数据库40的主库40A中的账号A的余额41(在主库40A中保存有所有被操作的业务数据)，最后向客户端10反馈存款成功响应12。

当应用服务器20检测到主库40A出现故障时，关闭主库40A，并启动备库40B，根据保存在第一数据库30中的业务请求的记录确定备库40B的不可处理账号。在主库40A与40B完成切换之前，如果客户端10向应用服务器20发送针对账号B的提款请求13，作为响应，应用服务器20先将存款请求13的记录作为记录32保存在第一数据库30中，然后再判断提款请求13对应的账号B是否为备库40B的不可处理账号，如果是，拒绝该提款请求12，并向客户端10反馈提款失败响应14，如果否，根据提款请求13执行响应的提款操作，并更新保存在备库40B中的账号B的余额42，向客户端10反馈提款成功响应15。

服务器20可以是Web服务器，也可以是其他类型的服务器，例如APP服务器。本领域技术人员可以理解，图1所示的示意图仅是本发明的实施方式可以在其中得以实现的一个示例。本发明实施方式的应用范围不受到该框架任何方面的限制。例如，应用服务器20从逻辑上可以进一步分为交易应用服务器和账务应用服务器。交易应用服务器主要负责接收客户端10的业务请求，按照业务规则正确解析业务请求后，驱动账务应用服务器根据业务请求执行相应的业务操作；账务应用服务器主要负责在交易应用服务器的驱动下根据业务请求执行相应的业务操作。再例如，第一数据库30可以包含一个主库和至少一个备库。

方法实施例

请参阅图2，其为本申请提供的一种数据库操作方法的一个实施例的流程图，其中，第一数据库保存业务请求记录，第二数据库保存业务数据，所述第二数据库包括一个主库和至少一个备库，该方法包括以下步骤：

步骤201：当主库不可用时，根据第一数据库中的业务请求记录统计在备库可信时间临界点之后提交的业务请求，将统计的业务请求所对应的账号作为备库不可处理账号，其中，以主库不可用的初始时间点为预设时间段的终止点，起始点即为所述备库可信时间临界点，所述预设时间段大于或等于备库与主库之间的数据延迟时间。

步骤202：判断当前业务请求对应的账号是否为所述备库不可处理账号，如果是，进入步骤203，否则，进入步骤204。

步骤203：拒绝当前业务请求，结束流程。

步骤204：接受当前业务请求，并根据当前业务请求对备库进行操作，结束流程。

其中，导致第二数据库的主库不可用的因素有很多，例如，对主库中的软件或磁盘进行升级，或者，主库出现故障。当对主库中的软件或磁盘进行升级而导致该主库不可用时，该主库不可用的初始时间点即为开始对主库中的软件或磁盘进行升级的时刻。当主库出现故障而导致该主库不可用时，该主库不可用的初始时间点为该主库实际出现故障的时间点。

通常，当主库上的故障检测工具在一个时间范围内(即，故障检测时长)没有得到该主库的正常响应时，就会认定该主库出现了故障，并将主库故障的信息上报给应用服务器。例如，如图3所示，如果故障检测时长为60s，并且，故障检测工具在09:11:30认定(即，检测出)主库出现了故障，则主库实际出现故障的时间点为09:10:30，即，主库不可用的初始时间点为09:10:30。

通过上述方式可以确定主库不可用的初始时间点。当然，如果导致主库不可用的因素为其它因素，同样可以根据其它方式确定主库不可用的初始时间点。

假设主库与备库之间的数据延迟时间为1s，预设时间段可以为大于或等于1s的任意值。可以理解的，预设时间段设置的越大，越能降低备库不可处理账号统计遗漏的可能性，进而对备库的处理也就越安全。例如，可以将预设时间段设置为20s，如果主库不可用的初始时间点为09:10:30，备库可信时间临界点为09:10:10。如图3所示。

在本申请实施例中，每产生一个业务请求，就将该业务请求的记录保存在第一数据库中。假设先后产生如下业务请求：

10:00:00：向账号A中存款100元。

10:00:02：账号B向账号C转账30元。

10:00:08：从D账户中提款10元。

上述业务请求在第一数据库中的记录如图4所示，当根据上述业务请求执行相应的业务操作后，保存在第二数据库的主库和备库中的业务数据如图5所示。

可以理解的，业务数据和业务请求记录必须分别保存在两个不同的数据库中，而不能保存在同一个数据库中。这样才可以保证当业务数据所在的数据库(即，第二数据库)的主库出现不可用状况时，业务请求记录所在的数据库(即，第一数据库)仍然是可用的，并且，保证利用第一数据库统计出第二数据库的备库不可处理账号是可信的。

当确定了备库可信时间临界点，根据图4所示的第一数据库就可以统计在备库可信时间临界点之后提交的业务请求以及对应的账号，统计出的账号即为备库不可处理账号，而除此之外的账号即为备库可处理的账号。

需要说明的是，第二数据库的备库可以是既能够支持读取操作又能够支持写入操作的数据库，也可以是只支持读取操作的只读数据库。

例如，当采用Oracle数据库时，可以通过ActiveDataGuard技术，可以使备库只提供查询服务，即，只支持读取操作，并且，备库与主库之间的数据延迟时间约1s。

在本申请的一个优选实施方式中，当第二数据库的备库为只允许进行读取操作的数据库时，则步骤204为：根据当前业务请求对保存在第二数据库的备库中的业务数据进行读取操作。

如果当前业务请求需要进行数据写入操作时，在本申请的另一个优选实施方式中，根据当前业务请求对第三数据库进行业务数据的写入操作，其中，第三数据库为允许进行写入操作的数据库。

另外，还需要说明的是，如果第二数据库只包括一个备库，当主库不可用是，一方面，该备库与主库进行切换，另一方面，在该备库与主库完成切换之前，还为了响应备库可处理的账号下的业务请求，从而保证应用服务在切换过程中仍然可用，还需要根据该业务请求对该备库中的业务数据进行操作。

如果第二数据库包括多个备库，例如，包括两个备库，其中一个备库(第一个备库)在主库不可用时与主库进行切换，其中另一个备库(第二个备库)用于分担主库的工作压力，处理一些时效性不高的业务请求。在本申请实施例中，当主库不可用时，由第一个备库与主库完成切换，并且，在第一个备库与主库完成切换之前，为了响应备库可处理的账号下的业务请求，根据该业务请求对第二个备库中的业务数据进行操作。

另外，在某些应用场景，如，金融业务，如果业务请求的业务类型为资金流入类业务，即使该业务请求是在备库可信时间临界点之后提交的，对于该业务请求来说，第二数据库的备库中的数据是不可信的，但是，考虑到接受该业务请求时并不会存在任何资金安全问题，因此，仍然可以接受这种业务类型的业务请求，这样可以进一步减少对业务的影响。

例如，A账号的原本余额为100元，在备库可信时间临界点之后又存入50元，即，在第二数据库的主库中A账号的总余额为150元，而当第二数据库的主不可用时，第二数据库的备库有可能没来得及对A账号的余额进行同步更新，也有可能已经对A账号的余额进行同步更新。因此，在第二数据库的备库中A账号的余饿可能为150元，也可能为100元。无论是上述哪种情况，直接使用第二数据库的备库中A账号的余额都不会产生资金安全上的风险，即，不会导致A账号透支。

当然，除了金融业务中的资金流入类的业务请求之外，在其它应用场景中也存在另一些业务请求，也不会引起任何安全问题。

因此，在本申请的另一个优选实施方式中，请参阅图6，其为本申请提供的一种数据库操作方法的另一个实施例的流程图，其中，第一数据库保存业务请求记录，第二数据库保存业务数据，所述第二数据库包括一个主库和至少一个备库，该方法包括以下步骤：

步骤601：当主库不可用时，根据第一数据库中的业务请求记录统计在备库可信时间临界点之后提交的业务请求，将统计的业务请求所对应的账号作为备库不可处理账号，其中，以主库不可用的初始时间点为预设时间段的终止点，起始点即为所述备库可信时间临界点，所述预设时间段的时长大于或等于备库与主库之间的数据延迟时间。

步骤602：判断当前业务请求所对应的账号是否为所述备库不可处理账号，如果是，进入步骤603，否则，进入步骤605。

步骤603：判断当前业务请求针对的业务类型是否为预设业务类型，如果否，进入步骤604。

步骤604：拒绝当前业务请求，结束流程。

步骤605：接受当前业务请求，并根据当前业务请求对备库进行操作，结束流程。

其中，对于备库不可处理账号下的业务请求，如果接受该业务请求并不会对该账号产生任何安全问题，该业务请求的业务类型即为预设业务类型。显然，在不用的应用领域，预设业务类型是不同。例如，在金融领域，预设业务类型为资金流入类业务，如，存款业务。

另外，当步骤603的判断结果为是时，接受当前业务请求，并根据当前业务请求对备库进行操作。

由上述实施例可以看出，与现有技术相比，本申请的优点在于：

当业务数据所在的第二数据库的主库不可用时，在主库和其备库的切换过程中，可以先确定备库不可处理账号，即，对于备库不可处理账号下的业务请求来说，备库中的数据是不可信的。而除备库不可处理账号之外的账号为备库可处理的账号，即，对于备库可处理账号下的业务请求来说，备库中的数据是可信的。因此，对于备库可处理账号下的业务请求，可以根据该业务请求直接对备库进行操作。这样就可以保证在主库和备库的切换过程中，应用服务仍然是可用的，并不会因此而中断，缓解甚至避免了在主库和备库进行切换时而出现的应用服务不可用的问题。

装置实施例

与上述一种数据库操作方法相对应，本申请实施例还提供了一种数据库操作装置。请参阅图7，其为本申请提供的一种数据库操作装置的一个实施例的结构图，其中，第一数据库保存业务请求记录，第二数据库保存业务数据，所述第二数据库包括一个主库和至少一个备库；该装置包括：统计单元701、第一判断单元702、请求拒绝单元703和第一操作单元704。下面结合该装置的工作原理进一步介绍其内部结构以及连接关系。

统计单元701，用于当主库不可用时，根据第一数据库中的业务请求记录统计备库可信时间临界点之后提交的业务请求，将统计的业务请求所对应的账号作为备库不可处理账号，其中，以主库不可用的初始时间点为预设时间段的终止点，起始点即为所述备库可信时间临界点，所述预设时间段的时长大于或等于备库与主库之间的数据延迟时间；

第一判断单元702，用于判断当前业务请求所对应的账号是否为所述备库不可处理账号；

请求拒绝单元703，用于如果当前业务请求所对应的账号是所述备库不可处理账号，拒绝当前业务请求。

第一操作单元704，用于如果当前业务请求所对应的账号不是备库不可处理账号，接受当前业务请求，并根据当前业务请求对备库进行操作。

在本申请的一个优选实施方式中，如图8所示，在图7所示的结构的基础上，该装置还包括：

第二判断单元705，用于在所述拒绝请求单元拒绝当前的业务请求之前，判断当前业务请求针对的业务类型是否为预设业务类型；

所述请求拒绝单元703用于，如果当前业务请求针对的业务类型不是预设业务类型，拒绝当前业务请求。

在本申请的另一个优选实施方式中，所述第一操作单元704还用于，如果当前业务请求针对的业务类型是预设业务类型，接受当前业务请求，并根据当前业务请求对备库进行操作。

在本申请的另一个优选实施方式中，所述备库为只允许进行读取操作的数据库；所述第一操作单元704用于，根据当前业务请求对备库进行读取操作。

在本申请的另一个优选实施方式中，该装置还包括：第二操作单元，用于根据当前业务请求对第三数据库进行写入操作，其中，第三数据库为允许进行写入操作的数据库。

由上述实施例可以看出，与现有技术相比，本申请的优点在于：

当业务数据所在的第二数据库的主库不可用时，在主库和其备库的切换过程中，可以先确定备库不可处理账号，即，对于备库不可处理账号下的业务请求来说，备库中的数据是不可信的。而除备库不可处理账号之外的账号为备库可处理的账号，即，对于备库可处理账号下的业务请求来说，备库中的数据是可信的。因此，对于备库可处理账号下的业务请求，可以根据该业务请求直接对备库进行操作。这样就可以保证在主库和备库的切换过程中，应用服务仍然是可用的，并不会因此而中断，缓解甚至避免了在主库和备库进行切换时而出现的应用服务不可用的问题。

所述领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述到的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，可以采用软件功能单元的形式实现。

需要说明的是，本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory，ROM)或随机存储记忆体(RandomAccessMemory，RAM)等。

以上对本申请所提供的一种数据库操作方法和装置进行了详细介绍，本文中应用了具体实施例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种数据库操作方法，其特征在于，第一数据库保存业务请求记录，第二数据库保存业务数据，所述第二数据库包括一个主库和至少一个备库；所述方法包括：

当主库不可用时，根据第一数据库中的业务请求记录统计在备库可信时间临界点之后提交的业务请求，将统计的业务请求所对应的账号作为备库不可处理账号，其中，以主库不可用的初始时间点为预设时间段的终止点，起始点即为所述备库可信时间临界点，所述预设时间段的时长大于或等于备库与主库之间的数据延迟时间；

判断当前业务请求所对应的账号是否为所述备库不可处理账号；

如果是，拒绝当前业务请求；

如果否，接受当前业务请求，并根据当前业务请求对备库进行操作。

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

在拒绝当前业务请求之前，判断当前业务请求针对的业务类型是否为预设业务类型；

拒绝当前业务请求为：

如果当前业务请求针对的业务类型不是预设业务类型，拒绝当前业务请求。

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

如果当前业务请求针对的业务类型是预设业务类型，接受当前业务请求，并根据当前业务请求对备库进行操作。

4.根据权利要求1至3中任意一项所述的方法，其特征在于，所述备库为只允许进行读取操作的数据库；

所述根据当前业务请求对备库进行操作为：

根据当前业务请求对备库进行读取操作。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：根据当前业务请求对第三数据库进行写入操作，其中，第三数据库为允许进行写入操作的数据库。

6.一种数据库操作装置，其特征在于，第一数据库保存业务请求记录，第二数据库保存业务数据，所述第二数据库包括一个主库和至少一个备库；所述装置包括：

统计单元，用于当主库不可用时，根据第一数据库中的业务请求记录统计备库可信时间临界点之后提交的业务请求，将统计的业务请求所对应的账号作为备库不可处理账号，其中，以主库不可用的初始时间点为预设时间段的终止点，起始点即为所述备库可信时间临界点，所述预设时间段的时长大于或等于备库与主库之间的数据延迟时间；

第一判断单元，用于判断当前业务请求所对应的账号是否为所述备库不可处理账号；

请求拒绝单元，用于如果当前业务请求所对应的账号是所述备库不可处理账号，拒绝当前业务请求。

第一操作单元，用于如果当前业务请求所对应的账号不是备库不可处理账号，接受当前业务请求，并根据当前业务请求对备库进行操作。

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

第二判断单元，用于在所述拒绝请求单元拒绝当前的业务请求之前，判断当前业务请求针对的业务类型是否为预设业务类型；

所述请求拒绝单元用于，如果当前业务请求针对的业务类型不是预设业务类型，拒绝当前业务请求。

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

所述第一操作单元还用于，如果当前业务请求针对的业务类型是预设业务类型，接受当前业务请求，并根据当前业务请求对备库进行操作。

9.根据权利要求6至8中任意一项所述的装置，其特征在于，所述备库为只允许进行读取操作的数据库；

所述第一操作单元用于，根据当前业务请求对备库进行读取操作。

10.根据权利要求9所述的装置，其特征在于，所述装置还包括：

第二操作单元，用于根据当前业务请求对第三数据库进行写入操作，其中，第三数据库为允许进行写入操作的数据库。