CN113489608A - 业务异常的处理方法和装置 - Google Patents

Abstract

本发明实施例提供了一种业务异常的处理方法和装置，该方法包括：获取用户的待处理业务请求；判断待处理业务请求所对应的目标业务是否出现异常；若目标业务出现异常，则从第一数据库中获取兜底数据，并将该兜底数据返回给用户；其中，兜底数据用于表征上一个访问该目标业务时所获取到的数据；若目标业务没有出现异常，则从第二数据库中获取待处理业务请求所对应的数据，并将该数据返回给用户。本方案能够提高用户的使用体验。

Description

业务异常的处理方法和装置

技术领域

本发明涉及互联网技术领域，特别涉及业务异常的处理方法和装置。

背景技术

随着互联网技术的不断发展壮大，用户对于软件功能的要求也越来越高，不仅仅只是局限于软件的功能上面，对于软件的外观、访问速度、返回结果等需求也越来越看重。然而，市场上的很多软件对于一些高并发、高可用的软件功能，发生故障或产生异常的情况非常频繁，而对于这类异常，要么导致该软件直接不可用，要么需要对异常情况进行处理。

目前，申请号为CN201810310861.8的专利公开了一种服务降级的方法、装置及设备，该方案中通过确定各种业务在执行过程中出现的异常业务所对应的全量异常值和当前业务对应的异常值，来确定是否对当前业务进行降级处理，以解决当前业务出现异常的问题。然而，该方案中是根据确定的所有异常业务对应的异常值和当前异常业务对应的异常值的大小关系决定是否进行异常处理的，如果异常值确定的不够精准，往往会导致无法对异常进行处理，使得用户的使用体验较差。

因此，需要提供一种业务异常的处理方案。

发明内容

本发明实施例提供了一种业务异常的处理方法和装置，能够提高用户的使用体验。

第一方面，本发明实施例提供了一种业务异常的处理方法，包括：

获取用户的待处理业务请求；

判断所述待处理业务请求所对应的目标业务是否出现异常；

若所述目标业务出现异常，则从第一数据库中获取兜底数据，并将该兜底数据返回给所述用户；其中，所述兜底数据用于表征上一个访问该目标业务时所获取到的数据；

若所述目标业务没有出现异常，则从第二数据库中获取所述待处理业务请求所对应的数据，并将该数据返回给所述用户。

在一种可能的实现方式中，当所述目标业务出现异常时，进一步包括：

S1：实时对所述目标业务进行监控；

S2：判断所述目标业务出现的异常情况是否被解决；

S3：若所述目标业务出现的异常情况被解决，则从所述第二数据库中获取所述待处理业务请求所对应的更新后的数据，并将该更新后的数据返回给所述用户；

S4：若所述目标业务出现的异常情况未被解决，则循环执行步骤S1至S3，并从第一数据库中获取兜底数据后，将该兜底数据返回给所述用户。

在一种可能的实现方式中，在从所述第二数据库中获取所述待处理业务请求所对应的更新后的数据，并将该更新后的数据返回给所述用户之后，进一步包括：

将所述更新后的数据保存到所述第一数据库中。

在一种可能的实现方式中，在从第一数据库中获取到兜底数据之后，且在将该兜底数据返回给所述用户之前，进一步包括：

判断所述兜底数据能否解决所述目标业务出现的异常；

若所述目标业务出现的异常未被解决，则将所述目标业务出现异常的异常信息推送给预先设定的服务器，以通知运维人员进行异常修护；

若所述目标业务出现的异常解决，则将所述兜底数据返回给所述用户。

在一种可能的实现方式中，所述将所述目标业务出现异常的异常信息推送给预先设定的服务器，包括：

确定所述异常发生的异常发生时间；

从预先设定的异常发生时间和异常等级的对应关系中，确定当前异常发生时间所对应的待推送异常等级；

根据所述待推送异常等级，向所述预先设定的服务器推送所述异常信息。

第二方面，本发明实施例提供了一种业务异常的处理装置，包括：业务请求获取模块、业务异常判断模块和执行模块；

所述业务请求获取模块，用于获取用户的待处理业务请求；

所述业务异常判断模块，用于判断所述业务请求获取模块获取到的所述待处理业务请求所对应的目标业务是否出现异常；

所述执行模块，用于若所述业务异常判断模块判断出所述目标业务出现异常，则从第一数据库中获取兜底数据，并将该兜底数据返回给所述用户；其中，所述兜底数据用于表征上一个访问该目标业务时所获取到的数据；若所述业务异常判断模块判断出所述目标业务没有出现异常，则从第二数据库中获取所述待处理业务请求所对应的数据，并将该数据返回给所述用户。

在一种可能的实现方式中，所述执行模块进一步用于在当所述目标业务出现异常时，配置成执行如下操作：

S1：实时对所述目标业务进行监控；

S2：判断所述目标业务出现的异常情况是否被解决；

S3：若所述目标业务出现的异常情况被解决，则从所述第二数据库中获取所述待处理业务请求所对应的更新后的数据，并将该更新后的数据返回给所述用户；

S4：若所述目标业务出现的异常情况未被解决，则循环执行步骤S1至S3，并从第一数据库中获取兜底数据后，将该兜底数据返回给所述用户。

在一种可能的实现方式中，所述执行模块进一步用于在从所述第二数据库中获取所述待处理业务请求所对应的更新后的数据，并将该更新后的数据返回给所述用户之后，配置成执行如下操作：

将所述更新后的数据保存到所述第一数据库中。

在一种可能的实现方式中，所述执行模块进一步用于在从第一数据库中获取到兜底数据之后，且在将该兜底数据返回给所述用户之前，配置成执行如下操作：

判断所述兜底数据能否解决所述目标业务出现的异常；

若所述目标业务出现的异常未被解决，则将所述目标业务出现异常的异常信息推送给预先设定的服务器，以通知运维人员进行异常修护；

若所述目标业务出现的异常解决，则将所述兜底数据返回给所述用户。

在一种可能的实现方式中，所述执行模块在将所述目标业务出现异常的异常信息推送给预先设定的服务器时，配置成执行如下操作：

确定所述异常发生的异常发生时间；

从预先设定的异常发生时间和异常等级的对应关系中，确定当前异常发生时间所对应的待推送异常等级；

根据所述待推送异常等级，向所述预先设定的服务器推送所述异常信息。

由上述技术方案可知，当获取到用户的待处理业务请求时，会对用户的业务请求速对应的目标业务是否出现异常进行判断，如果没有出现异常，则直接可以从数据库中获取待处理业务请求所对应的数据返回给用户；而当出现异常时，可以考虑从数据库中获取上一个访问该目标业务时所获取到的兜底数据返回给用户。如此，对于一些可以通过降级处理的业务请求发生异常时，能够通过本方案解决业务异常的问题，从而提高用户的使用体验。

附图说明

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

图1是本发明一个实施例提供的一种业务异常的处理方法的流程图；

图2是本发明一个实施例提供的一种业务异常的处理装置的示意图。

具体实施方式

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

如前，随着互联网的不断发展壮大，人民生活水平的不断提高，用户对于软件功能的要求也越来越高，不仅仅只是局限于软件的功能上面，对于软件的外观、访问速度、返回结果等需求也越来越看重。然而市场上的很多软件对于一些高并发、高可用的软件功能，发生故障、产生异常的情况非常频繁，而对于这类异常，要么直接不可用，要么向用户推出无法使用的提示，然后通过短信、邮件等方式通知运维人员。运维人员在收到异常通知后，通过手动查找异常并手动恢复异常，这样的异常处理方式首先对于用户来说，用户的体验效果是十分不友好的，用户对于软件的粘合度也会降低。因此，用户更加需要的是一个高质量的、友好的软件；其次对于企业来说，不能在用户心中建立起一个良好的品牌和口碑，这对于企业在用户、在行业中的地位都会带来很大的冲击。

因此，本方案考虑对于高可用而一致性要求不高的功能出现异常时，通过进行降级处理，获取兜底数据来对业务异常的情况进行处理，从而提升用户体验效果，提高用户对软件使用的满意度。下面对本发明提供的业务异常的处理方法和处理装置作进一步详细的说明。

如图1所示，本发明实施例提供了一种业务异常的处理方法，该方法可以包括如下步骤：

步骤101：获取用户的待处理业务请求；

步骤102：判断待处理业务请求所对应的目标业务是否出现异常；

步骤103：若目标业务出现异常，则从第一数据库中获取兜底数据，并将该兜底数据返回给用户；其中，兜底数据用于表征上一个访问该目标业务时所获取到的数据；

步骤104：若目标业务没有出现异常，则从第二数据库中获取待处理业务请求所对应的数据，并将该数据返回给用户。

在本发明实施例中，当获取到用户的待处理业务请求时，会对用户的业务请求速对应的目标业务是否出现异常进行判断，如果没有出现异常，则直接可以从数据库中获取待处理业务请求所对应的数据返回给用户；而当出现异常时，可以考虑从数据库中获取上一个访问该目标业务时所获取到的兜底数据返回给用户。如此，对于一些可以通过降级处理的业务请求发生异常时，能够通过本方案解决业务异常的问题，从而提高用户的使用体验。

本方案主要考虑针对具有一致性较低的功能的软件，如此分布式系统的各个节点不会发生频繁的数据同步更新，从而当用户从一个节点发出的业务请求出现异常时，即当前的待处理业务请求所对应的最新数据无法获取时，可以通过获取兜底数据来返回给用户，即将上一个访问该目标业务时获取的数据返回给用户，从而解决该业务异常的情况。

在一种可能的实现方式中，当目标业务出现异常时，还可以进一步包括如下步骤：

S1：实时对目标业务进行监控；

S2：判断目标业务出现的异常情况是否被解决；

S3：若目标业务出现的异常情况被解决，则从第二数据库中获取待处理业务请求所对应的更新后的数据，并将该更新后的数据返回给用户；

S4：若目标业务出现的异常情况未被解决，则循环执行步骤S1至S3，并从第一数据库中获取兜底数据后，将该兜底数据返回给用户。

在本发明实施例中，当目标业务出现异常时，可以考虑实时对目标业务进行监控，然后判断该目标业务出现的异常情况是否被解决，如果解决了，则可以从数据库中获取经过更新的最新数据，然后将该更新后的最新数据返回给用户。如果没有被解决，则从数据库中获取兜底数据并返回给用户，同时实时监控目标业务并判断异常情况是否被解决，以确定是否可以将最新更新的数据返回给用户。由此可见，本方案通过对目标业务进行实时监控，以保证在能满足用户的业务请求的前提下，能够将对应该业务请求的最新数据返回给用户，从而提升用户的使用体验。

在一种可能的实现方式中，在从第二数据库中获取待处理业务请求所对应的更新后的数据，并将该更新后的数据返回给用户之后，进一步包括：

将更新后的数据保存到第一数据库中。

在本发明实施例中，当从第二数据库中获取待处理业务请求所对应的更新后的数据，并将该更新后的数据返回给用户之后，考虑将该更新后的数据保存到第一数据库中，即将该更新后的数据同步用于存储兜底数据的数据库中，如此可以将该更新后的数据作为当前兜底数据，当下一次访问该业务遇到异常时，可以从第一数据库中获取该更新后的数据作为兜底数据返回给用户，以解决业务出现异常的问题。

在一种可能的实现方式中，在从第一数据库中获取到兜底数据之后，且在将该兜底数据返回给用户之前，进一步包括：

判断兜底数据能否解决目标业务出现的异常；

若目标业务出现的异常未被解决，则将目标业务出现异常的异常信息推送给预先设定的服务器，以通知运维人员进行异常修护；

若目标业务出现的异常解决，则将兜底数据返回给用户。

在本发明实施例中，当从存储有兜底数据的第一数据库中获取到兜底数据后，可以考虑通过该兜底数据能够解决该目标业务出现的异常，若能被解决，则可以将该兜底数据返回给用户以满足用户的业务访问请求；然而，如果不能被解决，则考虑将该目标业务出现异常的异常信息推送给预先设定的服务器，以通知运维人员进行异常修护。由此可见，本方案不仅能够通过降级处理，以及获取兜底数据来解决目标业务出现异常的问题，而且在当该目标业务异常的情况不能通过降级和获取兜底数据解决时，可以通过将异常信息推送给设定的服务器，以通知运维人员对异常进行修护。如此能够保证出现的异常能在最快的时间内被修复。

当目标业务出现异常时，该异常可能是通过降级处理以及获取兜底数据来解决的，也可能无法通过降级处理解决，比如硬盘空间不足、数据库损坏等情况，需要由运维人员来进行修复。因此可以考虑对该异常是否可以通过降级处理来解决进行判断，从而采取对应的措施，以实现业务异常的真正解决。

在将目标业务出现你异常的异常信息进行推送时，可以考虑对出现的异常进行分级，然后向服务器进行推送。具体地，在一种可能的实现方式中，该分级的方法可以包括：

确定异常发生的异常发生时间；

从预先设定的异常发生时间和异常等级的对应关系中，确定当前异常发生时间所对应的待推送异常等级；

根据待推送异常等级，向预先设定的服务器推送异常信息。

在本发明实施例中，可以首先考虑确定异常发生的时间，以及运维人员维修的时间，如此可以确定出异常持续的时间，通过将该异常持续的时间和异常等级的对应关系进行预先设定，如此可以确定出当前异常所对应的异常等级，从根据该异常等级采取相应的推送方式，获取推送相应的异常信息至服务器。

比如，通过异常持续时间将异常分为不同等级，10h以上为S级(如劣性病毒攻击导致服务器无法正常运行)，5-10h为A级(如数据库损坏，缓存穿透导致大量请求直接作用于数据库引发数据库崩溃异常)，1-5h为B级(如服务器磁盘空间不足引发的异常)，1h以内为C级(如数据库存储数据过多导致请求时间过长的异常)，不同等级的异常通过不同方式推送，将不同的异常信息推送至服务器，有助于后续的维护。

如图2所示，本发明实施例还提供了一种业务异常的处理装置，该装置可以包括：业务请求获取模块201、业务异常判断模块202和执行模块203；

业务请求获取模块201，用于获取用户的待处理业务请求；

业务异常判断模块202，用于判断业务请求获取模块201获取到的待处理业务请求所对应的目标业务是否出现异常；

执行模块203，用于若业务异常判断模块202判断出目标业务出现异常，则从第一数据库中获取兜底数据，并将该兜底数据返回给用户；其中，兜底数据用于表征上一个访问该目标业务时所获取到的数据；若业务异常判断模块202判断出目标业务没有出现异常，则从第二数据库中获取待处理业务请求所对应的数据，并将该数据返回给用户。

在一种可能的实现方式中，执行模块203进一步用于在当目标业务出现异常时，配置成执行如下操作：

S1：实时对目标业务进行监控；

S2：判断目标业务出现的异常情况是否被解决；

S3：若目标业务出现的异常情况被解决，则从第二数据库中获取待处理业务请求所对应的更新后的数据，并将该更新后的数据返回给用户；

S4：若目标业务出现的异常情况未被解决，则循环执行步骤S1至S3，并从第一数据库中获取兜底数据后，将该兜底数据返回给用户。

在一种可能的实现方式中，执行模块203进一步用于在从第二数据库中获取待处理业务请求所对应的更新后的数据，并将该更新后的数据返回给用户之后，配置成执行如下操作：

将更新后的数据保存到第一数据库中。

在一种可能的实现方式中，执行模块203进一步用于在从第一数据库中获取到兜底数据之后，且在将该兜底数据返回给用户之前，配置成执行如下操作：

判断兜底数据能否解决目标业务出现的异常；

若目标业务出现的异常未被解决，则将目标业务出现异常的异常信息推送给预先设定的服务器，以通知运维人员进行异常修护；

若目标业务出现的异常解决，则将兜底数据返回给用户。

在一种可能的实现方式中，执行模块203在将目标业务出现异常的异常信息推送给预先设定的服务器时，配置成执行如下操作：

确定异常发生的异常发生时间；

从预先设定的异常发生时间和异常等级的对应关系中，确定当前异常发生时间所对应的待推送异常等级；

根据待推送异常等级，向预先设定的服务器推送异常信息。

由于当软件功能出现异常时，直接向用户抛出异常，然后通过诸如短信、邮件等方式将异常信息发送至相应运维人员处理的方式是十分不友好，并且十分浪费资源的方式，对于一些高可用而低一致性的功能异常，如果直接向用户抛出，用户体验将非常不佳；该技术就是主要用于解决高可用而一致性要求不高的功能出现异常时进行降级处理，提升用户体验效果，提高用户对软件使用的满意度。

在一种可能的实现方式中，对于高可用而一致性要求不高的功能异常处理，本发明主要可以通过以下几个组件协同工作进行解决：

1、服务降级管理组件：对降级服务进行统一化管理，规定各组件执行的上下文条件，是一个集中化管理中心；

2、正常业务逻辑组件：执行正常业务逻辑功能，当正常请求进来时，未发生任何异常时所需要执行的功能模块；

3、开关阀门控制组件：用于控制业务降级兜底组件是否开启的模块，当正常业务逻辑组件执行过程中发生可降级处理的异常时，该组件开启，让业务进入降级模式；

4、健康检查监听组件：当用户请求时，如果发现业务出现异常情况，即开关阀门控制组件开启时，该模块将会执行，记录开关阀门开启的时间和次数，并将数据返回给后台管理人员，便于管理人员对于此业务的后续维护工作；

5、业务降级兜底组件：用户请求被自动降级时所执行的功能模块，执行此模块可让用户获取到上一次请求成功时获取到的数据，只适用于高可用而一致性低的业务，对于一致性需求高的业务，该组件无法满足用户需求；

6、异常处理报警组件：当业务出现系统异常(即业务降级无法处理的异常)时，该模块将会执行，帮助管理人员监控业务异常状态，并且将业务的异常信息推送给相关维护人员，能够让运维人员快速定位服务异常。

下面对于各个组件的功能进行详细介绍，并说明各个组件之间如何协同工作来对高可用、低一致性功能异常进行智能化处理：

服务降级管理组件主要是对下面的各个组件进行统一化管理，使得整个设计更加整洁美观；正常业务逻辑组件的功能是处理用户的请求；开关阀门控制组件是用于开启和关闭降级服务；健康检查监听组件是在降级服务开启的时候监听业务健康状况，当业务恢复健康之后继续执行正常业务逻辑功能；业务降级兜底组件的功能是在出现异常时向用户返回兜底数据，而不是直接抛出异常；异常处理报警组件是在程序发生无法智能处理的异常时向相关异常处理中心通过短信、邮件等方式发送异常信息。

首先需要定义一个管理组件，用于管理其他的服务降级处理组件。用户发送高可用且低一致性请求，当程序接收到用户请求之后运行业务逻辑组件，处理用户请求的业务逻辑，当程序处理过程中发生异常时，开关阀门组件开始工作，开启服务降级处理，执行兜底组件，将兜底数据返回到用户，同时健康监听组件也开始工作，实时监听业务逻辑组件的健康状况，当业务逻辑组件恢复正常的时候，关闭开关组件，继续执行业务逻辑组件，执行完毕后将新的数据返回给用户，同时异步将数据同步到兜底组件中，用于下一次降级处理；当然，如果遇到降级处理无法解决的异常，如硬盘空间不足、数据库损坏等情况，就需要通过报警组件向运维或开发人员等通过邮件、短信等方式推送异常信息，由专门的维护人员来进行异常修护，同时开启异常修护时间监听器，记录异常发生至异常修护的时间，通过时间将异常分为不同等级，10h以上为S级(如劣性病毒攻击导致服务器无法正常运行)，5-10h为A级(如数据库损坏，缓存穿透导致大量请求直接作用于数据库引发数据库崩溃异常)，1-5h为B级(如服务器磁盘空间不足引发的异常)，1h以内为C级(如数据库存储数据过多导致请求时间过长的异常)，不同等级的异常通过不同方式推送，有助于后续的维护。

本发明通过上述六个组件协同工作，通过服务降级处理，既能减少程序运维成本，又能提升用户对于软件的使用满意度，比起传统固有的直接向用户抛出异常信息的方式来说，面向用户体验更加友好，更加符合用户的使用需求，对于产品的维护来说，减轻了运维人员大量重复的工作量，也节约了大量的时间成本。

可以理解的是，本发明实施例示意的结构并不构成对业务异常的处理装置或各个组件的具体限定。在本发明的另一些实施例中，业务异常的处理装置中所提到的模块或组件可以包括比图示更多或者更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件、软件或者软件和硬件的组合来实现。

上述业务异常的处理装置中各模块或组件之间的信息交互、执行过程等内容与本发明业务异常的处理方法的实施例基于同一构思。

需要说明的是，在本文中，诸如第一和第二之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个······”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同因素。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储在计算机可读取的存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质中。

最后需要说明的是：以上所述仅为本发明的较佳实施例，仅用于说明本发明的技术方案，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (10)

1.业务异常的处理方法，其特征在于，包括：

获取用户的待处理业务请求；

判断所述待处理业务请求所对应的目标业务是否出现异常；

若所述目标业务出现异常，则从第一数据库中获取兜底数据，并将该兜底数据返回给所述用户；其中，所述兜底数据用于表征上一个访问该目标业务时所获取到的数据；

若所述目标业务没有出现异常，则从第二数据库中获取所述待处理业务请求所对应的数据，并将该数据返回给所述用户。

2.根据权利要求1所述的方法，其特征在于，当所述目标业务出现异常时，进一步包括：

S1：实时对所述目标业务进行监控；

S2：判断所述目标业务出现的异常情况是否被解决；

S3：若所述目标业务出现的异常情况被解决，则从所述第二数据库中获取所述待处理业务请求所对应的更新后的数据，并将该更新后的数据返回给所述用户；

S4：若所述目标业务出现的异常情况未被解决，则循环执行步骤S1至S3，并从第一数据库中获取兜底数据后，将该兜底数据返回给所述用户。

3.根据权利要求2所述的方法，其特征在于，在从所述第二数据库中获取所述待处理业务请求所对应的更新后的数据，并将该更新后的数据返回给所述用户之后，进一步包括：

将所述更新后的数据保存到所述第一数据库中。

4.根据权利要求1至3中任一所述的方法，其特征在于，在从第一数据库中获取到兜底数据之后，且在将该兜底数据返回给所述用户之前，进一步包括：

判断所述兜底数据能否解决所述目标业务出现的异常；

若所述目标业务出现的异常未被解决，则将所述目标业务出现异常的异常信息推送给预先设定的服务器，以通知运维人员进行异常修护；

若所述目标业务出现的异常解决，则将所述兜底数据返回给所述用户。

5.根据权利要求4所述的方法，其特征在于，所述将所述目标业务出现异常的异常信息推送给预先设定的服务器，包括：

确定所述异常发生的异常发生时间；

从预先设定的异常发生时间和异常等级的对应关系中，确定当前异常发生时间所对应的待推送异常等级；

根据所述待推送异常等级，向所述预先设定的服务器推送所述异常信息。

6.业务异常的处理装置，其特征在于，包括：业务请求获取模块、业务异常判断模块和执行模块；

所述业务请求获取模块，用于获取用户的待处理业务请求；

所述业务异常判断模块，用于判断所述业务请求获取模块获取到的所述待处理业务请求所对应的目标业务是否出现异常；

所述执行模块，用于若所述业务异常判断模块判断出所述目标业务出现异常，则从第一数据库中获取兜底数据，并将该兜底数据返回给所述用户；其中，所述兜底数据用于表征上一个访问该目标业务时所获取到的数据；若所述业务异常判断模块判断出所述目标业务没有出现异常，则从第二数据库中获取所述待处理业务请求所对应的数据，并将该数据返回给所述用户。

7.根据权利要求6所述的装置，其特征在于，所述执行模块进一步用于在当所述目标业务出现异常时，配置成执行如下操作：

S1：实时对所述目标业务进行监控；

S2：判断所述目标业务出现的异常情况是否被解决；

S3：若所述目标业务出现的异常情况被解决，则从所述第二数据库中获取所述待处理业务请求所对应的更新后的数据，并将该更新后的数据返回给所述用户；

S4：若所述目标业务出现的异常情况未被解决，则循环执行步骤S1至S3，并从第一数据库中获取兜底数据后，将该兜底数据返回给所述用户。

8.根据权利要求7所述的装置，其特征在于，所述执行模块进一步用于在从所述第二数据库中获取所述待处理业务请求所对应的更新后的数据，并将该更新后的数据返回给所述用户之后，配置成执行如下操作：

将所述更新后的数据保存到所述第一数据库中。

9.根据权利要求6至8中任一所述的装置，其特征在于，所述执行模块进一步用于在从第一数据库中获取到兜底数据之后，且在将该兜底数据返回给所述用户之前，配置成执行如下操作：

判断所述兜底数据能否解决所述目标业务出现的异常；

若所述目标业务出现的异常未被解决，则将所述目标业务出现异常的异常信息推送给预先设定的服务器，以通知运维人员进行异常修护；

若所述目标业务出现的异常解决，则将所述兜底数据返回给所述用户。

10.根据权利要求9所述的装置，其特征在于，所述执行模块在将所述目标业务出现异常的异常信息推送给预先设定的服务器时，配置成执行如下操作：

确定所述异常发生的异常发生时间；

从预先设定的异常发生时间和异常等级的对应关系中，确定当前异常发生时间所对应的待推送异常等级；

根据所述待推送异常等级，向所述预先设定的服务器推送所述异常信息。

Images