一种应用处理的方法和装置与流程

本申请涉及互联网技术领域，尤其涉及一种应用处理的方法和装置。

背景技术：

目前，第一服务器在接收到来自客户端的应用请求后，如果需要调用第二服务器提供的服务，则第一服务器向第二服务器发送应用请求。第二服务器在接收到应用请求后，向第一服务器发送应用响应，该应用响应中携带应用请求对应的相关数据。第一服务器在接收到来自第二服务器的应用响应后，向客户端返回应用响应。至此，第一服务器向客户端提供了其请求的服务。

但是，在上述过程中，如果第二服务器发生异常或者死机等故障，第二服务器将无法处理来自第一服务器的应用请求，也无法向第一服务器发送应用响应，导致第一服务器无法及时向客户端返回应用响应，导致用户体验的降低。而且，如果有大量的客户端向第一服务器发送应用请求，则这些应用请求就会积压到第一服务器，占用第一服务器的大量处理资源，最后会导致第一服务器出现异常或者死机等故障，无法继续为客户端提供服务。

技术实现要素：

本申请提供一种应用处理的方法和装置，以在第二服务器发生异常或者死机等故障时，及时向客户端返回应用响应，避免用户体验的降低。

本申请提供一种应用处理的方法，所述方法包括以下步骤：

第一服务器在接收到来自客户端的第一应用请求时，如果需要第二服务器处理所述第一应用请求，则判断所述第二服务器是否发生故障；

如果是，则所述第一服务器获取模拟数据，并利用所述模拟数据生成第一应用响应，并将所述第一应用响应发送给所述客户端。

在所述第一服务器判断所述第二服务器是否发生故障之后，所述方法还包括：如果否，则所述第一服务器向第二服务器发送第二应用请求，如果在预设时间内收到第二服务器返回的第二应用响应，则利用所述第二应用响应携带的数据生成第三应用响应，并将所述第三应用响应发送给所述客户端。

在所述第一服务器向第二服务器发送第二应用请求之后，所述方法还包括：如果在所述预设时间内未收到所述第二服务器返回的第二应用响应，则所述第一服务器获取模拟数据，并利用所述模拟数据生成第四应用响应；

所述第一服务器将所述第四应用响应发送给所述客户端。

所述方法还包括：

如果在所述预设时间内未收到所述第二服务器返回的第二应用响应，则所述第一服务器更新故障累计次数，并判断更新后的故障累计次数是否大于预设阈值；如果是，则所述第一服务器确定所述第二服务器发生故障。

所述方法还包括：

当所述第二服务器发生故障时，所述第一服务器周期性向第二服务器发送心跳请求报文；如果在预设时间内收到第二服务器返回的心跳响应报文，则确定所述第二服务器恢复正常，并停止向第二服务器发送心跳请求报文。

所述第一服务器在确定所述第二服务器发生故障之后，将所述第二服务器对应的管控标志位由第一标识修改为第二标识；

所述第一服务器在确定所述第二服务器恢复正常之后，将所述第二服务器对应的管控标志位由第二标识修改为第一标识；

所述第一服务器判断所述第二服务器是否发生故障的过程，具体包括：所述第一服务器检查所述第二服务器对应的管控标志位；如果所述管控标志位为第一标识，则确定所述第二服务器没有发生故障；如果所述管控标志位为第二标识，则确定所述第二服务器发生故障。

本申请提供一种应用处理的装置，所述应用处理的装置应用在第一服务 器上，且所述应用处理的装置具体包括：

接收模块，用于接收来自客户端的第一应用请求；

判断模块，用于当需要第二服务器处理所述第一应用请求时，则判断所述第二服务器是否发生故障；

处理模块，用于当判断结果为是时，则获取模拟数据，并利用所述模拟数据生成第一应用响应；

发送模块，用于将所述第一应用响应发送给所述客户端。

所述发送模块，还用于在所述判断模块判断所述第二服务器是否发生故障之后，当判断结果为否时，则向第二服务器发送第二应用请求；

所述处理模块，还用于在预设时间内收到第二服务器返回的第二应用响应时，则利用所述第二应用响应携带的数据生成第三应用响应；

所述发送模块，还用于将所述第三应用响应发送给所述客户端。

所述处理模块，还用于在所述发送模块向第二服务器发送第二应用请求之后，如果在所述预设时间内未收到所述第二服务器返回的第二应用响应，则获取模拟数据，并利用所述模拟数据生成第四应用响应；

所述发送模块，还用于将所述第四应用响应发送给所述客户端。

所述判断模块，还用于在所述预设时间内未收到所述第二服务器返回的第二应用响应时，则更新故障累计次数，并判断更新后的故障累计次数是否大于预设阈值；如果是，则确定所述第二服务器发生故障。

所述发送模块，还用于当第二服务器发生故障时，周期性向第二服务器发送心跳请求报文；如果在预设时间内收到第二服务器返回的心跳响应报文，则确定所述第二服务器恢复正常，并停止向第二服务器发送心跳请求报文。

所述处理模块，还用于在确定第二服务器发生故障之后，将所述第二服务器对应的管控标志位由第一标识修改为第二标识；在确定第二服务器恢复正常之后，将所述第二服务器对应的管控标志位由第二标识修改为第一标识；

所述判断模块，具体用于在判断所述第二服务器是否发生故障的过程中，检查所述第二服务器对应的管控标志位；如果所述管控标志位为第一标识， 则确定所述第二服务器没有发生故障；如果所述管控标志位为第二标识，则确定所述第二服务器发生故障。

基于上述技术方案，本申请实施例中，当第二服务器发生异常或者死机等故障时，第一服务器可以利用模拟数据生成应用响应，并将应用响应发送给客户端，从而按照预先设置的模拟数据暂时为客户端提供服务，及时向客户端返回应用响应，避免用户体验的降低。如果有大量客户端向第一服务器发送应用请求，第一服务器也可以及时向客户端返回应用响应，避免大量应用请求积压到第一服务器，保证第一服务器的正常使用，并提高稳定性。

附图说明

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

图1是本申请一种实施方式中的应用处理的系统的结构图；

图2是本申请一种实施方式中的应用处理的方法的流程图；

图3是本申请另一种实施方式中的应用处理的方法的流程图；

图4是本申请一种实施方式中的第一服务器的硬件结构图；

图5是本申请一种实施方式中的应用处理的装置的结构图。

具体实施方式

在本申请使用的术语仅仅是出于描述特定实施例的目的，而非限制本申请。本申请和权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其它含义。还应当理解，本文中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区 分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，此外，所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

如图1所示，为本申请一种实施方式中的应用处理的系统的结构图，各客户端可以是终端设备(如手机、平板电脑、个人计算机等)上使用的应用app。第一服务器可以是用于为客户端提供服务的服务器，如客户端是微信客户端时，则第一服务器可以是提供微信服务的服务器，客户端是支付宝客户端时，则第一服务器可以是提供支付宝服务的服务器。第二服务器可以是提供扩展服务的服务器，第一服务器提供的服务和第二服务器提供的服务之间具有依赖关系，例如，当客户端使用附近商户功能时，则第二服务器可以是一个地理位置服务器，用于利用经纬度查询该客户端附近的商户。

针对现有技术中存在的问题，本申请实施例中提出一种应用处理的方法，该方法可以应用在图1所示的系统架构中，该系统架构中包括客户端、第一服务器和第二服务器。如图2所示，该应用处理的方法可以包括以下步骤：

步骤201，第一服务器在接收到来自客户端的第一应用请求时，如果需要第二服务器处理第一应用请求，则判断该第二服务器是否发生故障。

如果是，则执行步骤202；如果否，则执行步骤203。

例如，当客户端使用附近商户功能时，客户端会向第一服务器发送携带本客户端的经纬度信息的第一应用请求。第一服务器在接收到来自客户端的第一应用请求时，获知客户端使用附近商户功能，且需要第二服务器(如地理位置服务器)处理附近商户功能，即由第二服务器处理第一应用请求。

本申请实施例中，第一服务器判断第二服务器是否发生故障的过程，具体可以包括但不限于如下方式：第一服务器检查第二服务器对应的管控标志位；如果该管控标志位为第一标识(如0)，则确定第二服务器没有发生故障；如果该管控标志位为第二标识(如1)，则确定第二服务器发生故障。

其中，在第一服务器上预先配置有管控标志位，管控标志位的初始值为第一标识，表示第二服务器没有发生故障。在后续过程中，管控标志位可能 被修改为第二标识，表示第二服务器发生故障，具体的修改在后续说明。

其中，该管控标志位类似于一种状态开关，包括第一标识和第二标识，该第一标识代表该状态开关被关闭，该第二标识代表该状态开关被打开。

步骤202，第一服务器获取模拟数据(即预先配置的模拟数据)，并利用该模拟数据生成第一应用响应，并将该第一应用响应发送给客户端。

其中，在第一服务器上会预先配置模拟数据，这些模拟数据可以根据实际需要进行选择。例如，针对附近商户功能，可以在第一服务器上预先配置商户a、商户b、商户c等模拟数据。这样，当客户端使用附近商户功能时，第一服务器在接收到第一应用请求之后，可以利用该模拟数据，直接生成包含商户a、商户b、商户c等模拟数据的第一应用响应，并将该第一应用响应发送给客户端，而不再将第一应用请求发送给第二服务器。

步骤203，第一服务器向第二服务器发送第二应用请求，如果在预设时间内收到第二服务器返回的第二应用响应，则第一服务器利用该第二应用响应携带的数据生成第三应用响应，并将该第三应用响应发送给客户端。

其中，当客户端使用附近商户功能时，第一服务器在接收到第一应用请求之后，可以利用该第一应用请求生成第二应用请求。第一应用请求和第二应用请求的区别在于：第一应用请求是客户端与第一服务器之间交互的应用请求，第二应用请求是第一服务器与第二服务器之间交互的应用请求。但是，第一应用请求和第二应用请求中可以携带相同的内容，如第一应用请求和第二应用请求中均携带客户端的经纬度信息。第一服务器可以从第一应用请求中获取客户端的经纬度信息，并将客户端的经纬度信息添加到第二应用请求。

第二服务器在接收到第二应用请求之后，如果第二服务器未发生故障，则可以利用客户端的经纬度信息查询该客户端附近的商户，如商户c、商户d和商户e等，并将查询到的商户添加到第二应用响应，并将第二应用响应发送给第一服务器。而且，由于第二服务器未发生故障，因此，第一服务器可以在预设时间内收到第二应用响应。第一服务器在接收到第二应用响应之后，可以利用该第二应用响应生成第三应用响应。第二应用响应和第三应用 响应的区别在于：第二应用响应是第一服务器与第二服务器之间交互的应用响应，第三应用响应是客户端与第一服务器之间交互的应用响应。但是，第二应用响应和第三应用响应中可以携带相同的内容，如第二应用响应和第三应用响应中均携带商户c、商户d和商户e等数据。第一服务器可以从第二应用响应中获取商户c、商户d和商户e等数据，并将商户c、商户d和商户e等数据添加到第三应用响应，并将第三应用响应发送给客户端。

本申请实施例中，在第一服务器向第二服务器发送第二应用请求之后，如果第二服务器发生故障，则第一服务器在预设时间内将无法收到第二服务器返回的第二应用响应。基于此，如果第一服务器在预设时间内未收到第二服务器返回的第二应用响应，则第一服务器获取模拟数据，并利用该模拟数据生成第四应用响应。之后，第一服务器将第四应用响应发送给客户端。

其中，第一服务器上会预先配置模拟数据，这些模拟数据可以根据实际需要进行选择。例如，可以在第一服务器上预先配置商户a、商户b、商户c等模拟数据。这样，当第一服务器在预设时间内未收到第二服务器返回的第二应用响应时，可以利用该模拟数据，直接生成包含商户a、商户b、商户c等模拟数据的第四应用响应，并将第四应用响应发送给客户端。

本申请实施例中，如果第一服务器在预设时间内未收到第二服务器返回的第二应用响应，则第一服务器更新故障累计次数，例如，将当前故障累计次数+1，得到更新后的故障累计次数。之后，第一服务器判断更新后的故障累计次数是否大于预设阈值(如3)。如果是，则第一服务器确定第二服务器发生故障，并将第二服务器对应的管控标志位由第一标识(如0)修改为第二标识(如1)。如果否，则第一服务器确定第二服务器还未发生故障。

其中，如果第一服务器在预设时间内未收到第二服务器返回的第二应用响应，则第一服务器并不是直接确定第二服务器发生故障，而是更新故障累计次数，只有当故障累计次数大于预设阈值时，才认为第二服务器发生故障。这样，可以避免在第二服务器未发生故障时，由于未能及时处理第二应用请求，所导致的错误判断，继而提高第二服务器发生故障的判断准确率。

本申请实施例中，当第二服务器发生故障时，第一服务器还可以周期性向第二服务器发送心跳请求报文。如果第一服务器在预设时间内未收到第二服务器返回的心跳响应报文，则确定第二服务器没有恢复正常，等待下次继续发送心跳请求报文。如果第一服务器在预设时间内收到第二服务器返回的心跳响应报文，则确定第二服务器恢复正常，停止向第二服务器发送心跳请求报文，并将第二服务器对应的管控标志位由第二标识修改为第一标识。

在上述过程中，预设时间可以根据实际经验任意设置，如预设时间可以稍微大于第一服务器与第二服务器之间的报文传输时间。

基于上述技术方案，本申请实施例中，当第二服务器发生异常或者死机等故障时，第一服务器可以利用模拟数据生成应用响应，并将应用响应发送给客户端，从而按照预先设置的模拟数据暂时为客户端提供服务，及时向客户端返回应用响应，避免用户体验的降低。如果有大量客户端向第一服务器发送应用请求，第一服务器也可以及时向客户端返回应用响应，避免大量应用请求积压到第一服务器，保证第一服务器的正常使用，并提高稳定性。

以下结合一具体应用场景，对本申请实施例的技术方案进行详细说明。

在本应用场景下，如图3所示，该应用处理的方法可以包括以下步骤：

步骤301，第一服务器接收来自客户端的第一应用请求。

其中，该第一应用请求是指需要由第二服务器处理第一应用请求。

例如，当客户端使用附近商户功能时，客户端会向第一服务器发送携带本客户端的经纬度信息的第一应用请求。第一服务器在接收到来自客户端的第一应用请求时，获知客户端使用附近商户功能，且需要第二服务器(如地理位置服务器)处理附近商户功能，即由第二服务器处理第一应用请求。

步骤302，第一服务器判断第二服务器对应的管控标志位是否为第一标识(如0)。如果该管控标志位为第一标识，则确定第二服务器没有发生故障，执行步骤304；如果该管控标志位不为第一标识，如该管控标志位为第二标识(如1)，则确定第二服务器发生故障，执行步骤303。

其中，在第一服务器上预先配置有管控标志位，管控标志位的初始值为 第一标识，表示第二服务器没有发生故障。在后续过程中，管控标志位可能被修改为第二标识，表示第二服务器发生故障，具体的修改在后续说明。

其中，该管控标志位类似于一种状态开关，包括第一标识和第二标识，该第一标识代表该状态开关被关闭，该第二标识代表该状态开关被打开。

步骤303，第一服务器获取模拟数据(即预先配置的模拟数据)，并利用该模拟数据生成第一应用响应，并将该第一应用响应发送给客户端。

其中，在第一服务器上会预先配置模拟数据，这些模拟数据可以根据实际需要进行选择。例如，针对附近商户功能，可以在第一服务器上预先配置商户a、商户b、商户c等模拟数据。这样，当客户端使用附近商户功能时，第一服务器在接收到第一应用请求之后，可以利用该模拟数据，直接生成包含商户a、商户b、商户c等模拟数据的第一应用响应，并将该第一应用响应发送给客户端，而不再将第一应用请求发送给第二服务器。

步骤304，第一服务器向第二服务器发送第二应用请求，并判断在预设时间(可以根据实际经验值进行设置)内是否收到第二服务器返回的第二应用响应。如果是，则执行步骤305；如果否，则执行步骤306。

其中，当客户端使用附近商户功能时，第一服务器在接收到第一应用请求之后，可以利用该第一应用请求生成第二应用请求。第一应用请求和第二应用请求的区别在于：第一应用请求是客户端与第一服务器之间交互的应用请求，第二应用请求是第一服务器与第二服务器之间交互的应用请求。但是，第一应用请求和第二应用请求中可以携带相同的内容，如第一应用请求和第二应用请求中均携带客户端的经纬度信息。第一服务器可以从第一应用请求中获取客户端的经纬度信息，并将客户端的经纬度信息添加到第二应用请求。

步骤305，第一服务器在收到第二应用响应后，利用该第二应用响应携带的数据生成第三应用响应，并将该第三应用响应发送给客户端。

第二服务器在接收到第二应用请求之后，如果第二服务器未发生故障，则可以利用客户端的经纬度信息查询该客户端附近的商户，如商户c、商户d和商户e等，并将查询到的商户添加到第二应用响应，并将第二应用响应 发送给第一服务器。而且，由于第二服务器未发生故障，因此，第一服务器可以在预设时间内收到第二应用响应。第一服务器在接收到第二应用响应之后，可以利用该第二应用响应生成第三应用响应。第二应用响应和第三应用响应的区别在于：第二应用响应是第一服务器与第二服务器之间交互的应用响应，第三应用响应是客户端与第一服务器之间交互的应用响应。但是，第二应用响应和第三应用响应中可以携带相同的内容，如第二应用响应和第三应用响应中均携带商户c、商户d和商户e等数据。第一服务器可以从第二应用响应中获取商户c、商户d和商户e等数据，并将商户c、商户d和商户e等数据添加到第三应用响应，并将第三应用响应发送给客户端。

步骤306，第一服务器更新故障累计次数(如将当前故障累计次数+1)，并判断更新后的故障累计次数是否大于预设阈值(可以根据实际经验值进行设置，如3)。如果是，则执行步骤307；如果否，则执行步骤308。

其中，如果第一服务器在预设时间内未收到第二服务器返回的第二应用响应，则第一服务器并不是直接确定第二服务器发生故障，而是更新故障累计次数，只有当故障累计次数大于预设阈值时，才认为第二服务器发生故障。这样，可以避免在第二服务器未发生故障时，由于未能及时处理第二应用请求，所导致的错误判断，继而提高第二服务器发生故障的判断准确率。

步骤307，第一服务器获取模拟数据，并利用该模拟数据生成第四应用响应，并将该第四应用响应发送给客户端。

步骤308，第一服务器将第二服务器对应的管控标志位由第一标识(如0)修改为第二标识(如1)，并获取模拟数据，并利用该模拟数据生成第四应用响应，并将该第四应用响应发送给客户端。

针对步骤307和步骤308，在第一服务器向第二服务器发送第二应用请求之后，如果第二服务器发生故障，则第一服务器在预设时间内将无法收到第二服务器返回的第二应用响应。基于此，第一服务器获取模拟数据，并利用该模拟数据生成第四应用响应，并将该第四应用响应发送给客户端。

其中，第一服务器上会预先配置模拟数据，这些模拟数据可以根据实际 需要进行选择。例如，可以在第一服务器上预先配置商户a、商户b、商户c等模拟数据。这样，当第一服务器在预设时间内未收到第二服务器返回的第二应用响应时，可以利用该模拟数据，直接生成包含商户a、商户b、商户c等模拟数据的第四应用响应，并将第四应用响应发送给客户端。

本申请实施例中，在将第二服务器对应的管控标志位由第一标识(如0)修改为第二标识(如1)之后，说明第二服务器已经发生故障，后续执行步骤302时被转到步骤303进行处理。而且，在第二服务器发生故障时，还可以启动异步线程，并通过异步线程执行以下步骤(在图3中未体现)：

步骤309，第一服务器周期性向第二服务器发送心跳请求报文，并判断第一服务器在预设时间内是否收到第二服务器返回的心跳响应报文。如果否，则确定第二服务器没有恢复正常，等待下次继续发送心跳请求报文，返回执行步骤309；如果是，则确定第二服务器恢复正常，执行步骤310。

步骤310，第一服务器停止向第二服务器发送心跳请求报文，将第二服务器对应的管控标志位由第二标识修改为第一标识，并清除故障累计次数。

其中，清除故障累计次数是指将清除故障累计次数的数值清0。

其中，在将第二服务器对应的管控标志位由第二标识修改为第一标识之后，说明第二服务器已经故障恢复，后续执行步骤302时被转到步骤304。

本申请实施例中，只要两个服务器(第一服务器和第二服务器)提供的服务之间存在依赖关系，就可以采用上述技术方案进行处理。例如，第一服务器调用第二服务器提供的rpc(remoteprocedurecallprotocol，远程过程调用协议)服务，第一服务器调用第二服务器提供的webservice服务等。

基于上述技术方案，本申请实施例中，当第二服务器发生异常或者死机等故障时，第一服务器可以利用模拟数据生成应用响应，并将应用响应发送给客户端，从而按照预先设置的模拟数据暂时为客户端提供服务，及时向客户端返回应用响应，避免用户体验的降低。如果有大量客户端向第一服务器发送应用请求，第一服务器也可以及时向客户端返回应用响应，避免大量应用请求积压到第一服务器，保证第一服务器的正常使用，并提高稳定性。

基于与上述方法同样的申请构思，本申请实施例中还提供了一种应用处理的装置，该应用处理的装置可以应用在第一服务器上。其中，该应用处理的装置可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在的第一服务器的处理器，读取非易失性存储器中对应的计算机程序指令形成的。从硬件层面而言，如图4所示，为本申请提出的应用处理的装置所在的第一服务器的一种硬件结构图，除了图4所示的处理器、非易失性存储器外，第一服务器还可以包括其他硬件，如负责处理报文的转发芯片、网络接口、内存等；从硬件结构上来讲，该第一服务器还可能是分布式设备，可能包括多个接口卡，以便在硬件层面进行报文处理的扩展。

如图5所示，为本申请提出的应用处理的装置的结构图，所述应用处理的装置应用在第一服务器上，且所述应用处理的装置具体包括：

接收模块11，用于接收来自客户端的第一应用请求；

判断模块12，用于当需要第二服务器处理所述第一应用请求时，则判断所述第二服务器是否发生故障；

处理模块13，用于当判断结果为是时，则获取模拟数据，并利用所述模拟数据生成第一应用响应；

发送模块14，用于将所述第一应用响应发送给所述客户端。

所述发送模块14，还用于在所述判断模块判断所述第二服务器是否发生故障之后，当判断结果为否时，则向第二服务器发送第二应用请求；

所述处理模块13，还用于在预设时间内收到第二服务器返回的第二应用响应时，则利用所述第二应用响应携带的数据生成第三应用响应；

所述发送模块14，还用于将所述第三应用响应发送给所述客户端。

所述处理模块13，还用于在所述发送模块向第二服务器发送第二应用请求之后，如果在所述预设时间内未收到所述第二服务器返回的第二应用响应，则获取模拟数据，并利用所述模拟数据生成第四应用响应；

所述发送模块14，还用于将所述第四应用响应发送给所述客户端。

所述判断模块12，还用于在所述预设时间内未收到所述第二服务器返回的第二应用响应时，则更新故障累计次数，并判断更新后的故障累计次数是否大于预设阈值；如果是，则确定所述第二服务器发生故障。

所述发送模块14，还用于当第二服务器发生故障时，周期性向第二服务器发送心跳请求报文；如果在预设时间内收到第二服务器返回的心跳响应报文，则确定第二服务器恢复正常，并停止向第二服务器发送心跳请求报文。

所述处理模块13，还用于在确定第二服务器发生故障之后，将第二服务器对应的管控标志位由第一标识修改为第二标识；在确定第二服务器恢复正常之后，将所述第二服务器对应的管控标志位由第二标识修改为第一标识；

所述判断模块14，具体用于在判断所述第二服务器是否发生故障的过程中，检查所述第二服务器对应的管控标志位；如果所述管控标志位为第一标识，则确定所述第二服务器没有发生故障；如果所述管控标志位为第二标识，则确定所述第二服务器发生故障。

基于上述技术方案，本申请实施例中，当第二服务器发生异常或者死机等故障时，第一服务器可以利用模拟数据生成应用响应，并将应用响应发送给客户端，从而按照预先设置的模拟数据暂时为客户端提供服务，及时向客户端返回应用响应，避免用户体验的降低。如果有大量客户端向第一服务器发送应用请求，第一服务器也可以及时向客户端返回应用响应，避免大量应用请求积压到第一服务器，保证第一服务器的正常使用，并提高稳定性。

其中，本申请装置的各个模块可以集成于一体，也可以分离部署。上述模块可以合并为一个模块，也可以进一步拆分成多个子模块。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实 施例所述的方法。本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本申请所必须的。

本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可进一步拆分成多个子模块。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

以上公开的仅为本申请的几个具体实施例，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。