故障确定方法、装置、设备及存储介质
技术领域
本申请涉及互联网通信技术领域，特别是涉及一种故障确定方法、装置、设备及存储介质。
背景技术
客户端-服务器(Client-Server，C/S)架构是互联网领域中一种非常常见的系统架构，由于客户端通常直接面向用户提供服务，因此，为了保证服务的鲁棒性，实际应用中，需要及时发现并排除客户端出现的故障。
相关技术中，客户端可以周期性地向服务器发送心跳请求，服务器可以周期性地接收客户端发送的心跳请求，并在接收到心跳请求后，向客户端返回心跳请求，一旦服务器没能成功接收到客户端发送的心跳请求，服务器就可以确定客户端出现了故障。
然而，相关技术中确定客户端是否出现故障的方法准确性较差。
发明内容
基于此，本申请实施例提供了一种故障确定方法、装置、设备及存储介质，可以提高确定客户端是否出现故障的准确性。
第一方面，提供了一种故障确定方法，该故障确定方法包括：
接收客户端发送的心跳请求；若连续n次未成功接收到该客户端发送的心跳请求，则确定该客户端处于异常状态，并对该客户端的异常状态进行记录，其中，n为大于1的正整数；根据记录的该客户端的异常状态次数，和/或，根据在记录的该客户端的异常状态时间之后该客户端的发送状态，确定该客户端是否出现故障。
第二方面，提供了一种故障确定装置，该故障确定装置包括：
接收模块，用于接收客户端发送的心跳请求；
记录模块，用于若连续n次未成功接收到该客户端发送的心跳请求，则确定该客户端处于异常状态，并对该客户端的异常状态进行记录，其中，n为大于1的正整数；
确定模块，用于根据记录的该客户端的异常状态次数，和/或，根据在记录的该客户端的异常状态时间之后该客户端的发送状态，确定该客户端是否出现故障。
第三方面，提供了一种计算机设备，包括存储器和处理器，该存储器存储有计算机程序，该计算机程序被该处理器执行时实现如上述第一方面任一所述的故障确定方法。
第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述第一方面任一所述的故障确定方法。
本申请实施例提供的技术方案带来的有益效果至少包括：
在本申请实施例提供的故障确定方法中，服务器接收客户端发送的心跳请求，若连续n次未成功接收到该客户端发送的心跳请求，则服务器可以确定客户端处于异常状态，并对该异常状态进行记录，而后，服务器可以根据记录的客户端的异常状态次数，和/或，根据在记录的客户端的异常状态时间之后客户端的发送状态，确定客户端是否出现故障，实际应用中，服务器没能成功接收到客户端发送的心跳请求很可能并不是由于客户端出现故障导致的，而是因为网络的短暂性断开导致的，有鉴于此，如果服务器只要检测到自身未成功接收到客户端发送的心跳请求就确定客户端出现故障，那么就会出现大量误判的情况发生，而在本申请实施例提供的技术方案中，服务器在n次未成功接收到该客户端发送的心跳请求后，对客户端的异常状态进行记录，而后，服务器又基于记录的客户端的异常状态次数以及在记录的客户端的异常状态时间之后客户端的发送状态中的至少一个，确定客户端是否出现故障，这样，就可以排除由于网络的短暂性断开而导致服务器未能成功接收到客户端发送的心跳请求的情况，使得对客户端是否出现故障的判断不受该情况的影响，因此，可以提高确定客户端是否出现故障的准确性。
附图说明
图1为本申请实施例提供的一种实施环境的示意图；
图2为本申请实施例提供的一种故障确定方法的流程图；
图3为本申请实施例提供的一种服务器记录客户端异常状态的技术过程的流程图；
图4为本申请实施例提供的一种确定客户端是否出现故障的技术过程的流程图；
图5为本申请实施例提供的另一种确定客户端是否出现故障的技术过程的流程图；
图6为本申请实施例提供的一种故障确定方法的流程图；
图7为本申请实施例提供的一种故障确定装置的框图；
图8为本申请实施例提供的另一种故障确定装置的框图；
图9为本申请实施例提供的一种服务器的框图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
客户端-服务器(Client-Server，C/S)架构是互联网领域中一种非常常见的系统架构，实际应用中，有必要及时发现并排除客户端出现的故障。
相关技术中，客户端可以周期性地向服务器发送心跳请求，服务器可以周期性地接收客户端发送的心跳请求，服务器在接收到客户端发送的心跳请求后，可以向客户端返回心跳请求，一旦服务器没能成功接收到客户端发送的心跳请求，服务器就可以确定客户端出现了故障。
实际应用中，服务器没能成功接收到客户端发送的心跳请求很可能是因为网络的短暂性断开导致的，例如，若服务器与客户端之间的网络出现了5分钟的暂时性断开，则服务器在网络暂时性断开的5分钟之内都将无法接收到客户端发送的心跳请求，而5分钟之后，随着网络的恢复，服务器又可以正常接收到客户端发送的心跳请求。
有鉴于此，若一旦服务器检测到自身没能成功接收到客户端发送的心跳请求便确定客户端出现故障，就会出现大量的误判的情况，这导致确定客户端是否出现故障的准确性较差。
考虑到以上情况，本申请实施例提供了一种故障确定方法，可以提高确定客户端是否出现故障的准确性。在该故障确定方法中，服务器接收客户端发送的心跳请求，若连续n次未成功接收到该客户端发送的心跳请求，则服务器可以确定客户端处于异常状态，并对客户端的异常状态进行记录，而后，服务器可以根据记录的客户端的异常状态次数，和/或，根据在记录的客户端的异常状态时间之后客户端的发送状态，确定客户端是否出现故障，实际应用中，服务器没能成功接收到客户端发送的心跳请求很可能并不是由于客户端出现故障导致的，而是因为网络的短暂性断开导致的，有鉴于此，如果服务器只要检测到自身未成功接收到客户端发送的心跳请求就确定客户端出现故障，那么就会出现大量误判的情况发生，而在本申请实施例提供的技术方案中，服务器在n次未成功接收到该客户端发送的心跳请求后，对客户端的异常状态进行记录，而后，服务器又基于记录的客户端的异常状态次数以及在记录的客户端的异常状态时间之后客户端的发送状态中的至少一个，确定客户端是否出现故障，这样，就可以排除由于网络的短暂性断开而导致服务器未能成功接收到客户端发送的心跳请求的情况，使得对客户端是否出现故障的判断不受该情况的影响，因此，可以提高确定客户端是否出现故障的准确性。
下面，将对本申请实施例提供的故障确定方法所涉及到的实施环境进行简要地说明。
如图1所示，该实施环境可以包括服务器101和客户端102，其中，服务器101和客户端102之间可以通过网络进行通信。
在本申请实施例中，服务器101可以为一台服务器，也可以为由多台服务器组成的服务器集群，客户端102可以为诸如手机、平板电脑、笔记本电脑、台式电脑、可穿戴设备、通信设备等的电子设备，客户端102也可以为安装于上述电子设备中的应用程序。
请参考图2，其示出了本申请实施例提供的一种故障确定方法的流程图，该故障确定方法可以应用于图1所示实施环境中的服务器。如图2所示，该故障确定方法可以包括以下步骤：
步骤201、服务器接收客户端发送的心跳请求。
在本申请实施例中，客户端可以周期性地向服务器发送心跳请求，服务器可以周期性地接收服务器发送的心跳请求，服务器在接收到客户端发送的心跳请求之后，可以向客户端返回心跳请求。
若服务器能够成功接收到客户端发送的心跳请求，则服务器可以确定自身与客户端之间的通信连接未断开，反之，若服务器不能成功接收到客户端发送的心跳请求，则服务器可以确定自身与客户端之间的通信连接断开。
同理地，若客户端能够成功接收到服务器发送的心跳请求，则客户端可以确定自身与服务器之间的通信连接未断开，反之，若客户端不能成功接收到服务器发送的心跳请求，则客户端可以确定自身与服务器之间的通信连接断开。
步骤202、若连续n次未成功接收到客户端发送的心跳请求，则服务器确定客户端处于异常状态，并对客户端的异常状态进行记录，n为大于1的正整数。
实际应用中，服务器未能成功接收到客户端发送的心跳请求的原因是多种多样的，其中，较为常见的两种原因为：1、客户端出现故障，由于客户端出现了故障，因此，客户端无法向服务器发送心跳请求，则服务器也就不能成功接收到客户端发送的心跳请求，2、服务器与客户端之间的网络出现了暂时性的断开，实际应用中，在网络环境不稳定的情况下，服务器与客户端之间的网络很可能会暂时性断开，由于服务器与客户端之间的网络暂时性断开，因此，即使客户端向服务器发送了心跳请求，服务器也无法成功接收到。
考虑到上述情况，为了避免对客户端是否出现故障产生误判，服务器可以在连续多次(也即是上文所述的n次)未成功接收到客户端发送的心跳请求的情况下，确定客户端处于异常状态，并对客户端的异常状态进行记录，以供服务器在后续步骤中判断客户端是否出现故障，这样，可以排除掉因网络暂时性断开而导致的服务器无法成功接收到客户端发送的心跳请求的情况，从而可以提高确定客户端是否出现故障的准确性。
在实际应用中，服务器未能成功接收到客户端发送的心跳请求的原因除了上文所述的两种以外，还可以是客户端处于重启过程中，例如，在客户端进行升级的过程中，客户端需要进行重启，在重启过程中，客户端无法向服务器发送心跳请求。
为了排除掉因客户端重启而导致的服务器无法成功接收到客户端发送的心跳请求的情况，避免对客户端是否出现故障产生误判，服务器可以在连续n次未成功接收到客户端发送的心跳请求的情况下，检测客户端是否处于重启过程中，例如，在一种可能的实现方式中，客户端重启之前可以向服务器发送重启信息，同时，客户端重启之后可以向服务器发送重启结束信息，服务器可以通过检测自身是否接收到重启信息以及重启结束信息的方式来判断客户端是否处于重启过程中。若客户端处于重启过程中，服务器可以确定客户端不处于异常状态，反之，若客户端未处于重启过程中，则服务器可以确定客户端处于异常状态，并对客户端的异常状态进行记录。
在本申请的可选实施例中，服务器对客户端的异常状态进行记录可以包括：服务器对客户端的标识信息(例如IP地址或者客户端ID等)、出现异常状态的次数以及出现异常状态的时间进行记录。
在一种可能的实现方式中，这里的“出现异常状态的时间”指的可以是每次出现异常状态的时间，例如，如果客户端出现了两次异常状态，则服务器可以对第一次出现异常状态的时间以及第二次出现异常状态的时间都进行记录。
在另一种可能的实现方式中，这里的“出现异常状态的时间”指的可以是第一次出现异常状态的时间，例如，如果客户端出现了两次异常状态，则服务器可以对第一次出现异常状态的时间进行记录。
表1所示为对客户端的异常状态进行记录的一种示例：
表1
如表1所示，客户端ID为23的客户端出现异常状态的次数为1次，出现异常状态的时间为0:30，客户端ID为45的客户端出现异常状态的次数为1次，出现异常状态的时间为0:32，客户端ID为24的客户端出现异常状态的次数为2次，其中，第一次出现异常状态的时间为0:35。
步骤203、服务器根据记录的客户端的异常状态次数，和/或，根据在记录的客户端的异常状态时间之后客户端的发送状态，确定客户端是否出现故障。
其中，客户端的发送状态可以包括客户端能够向服务器成功发送心跳请求的状态，以及客户端无法成功向服务器成功发送心跳请求的状态。
在本申请的可选实施例中，若服务器确定客户端出现了故障，则服务器可以向运维端发送故障排除信息，该故障排除信息用于指示运维人员对客户端进行修复。
在本申请的可选实施例中，若服务器确定客户端出现了故障，则服务器可以将存储的客户端对应的异常状态记录数据进行删除，这样，一方面可以节约服务器的存储空间，另一方面可以避免将来客户端再次出现故障或者异常状态时，存储的客户端对应的异常状态记录数据对服务器的判断造成影响。
下面，本申请实施例将对服务器记录客户端异常状态的技术过程进行简要说明，请参考图3，该技术过程包括以下步骤：
步骤301、服务器检测是否存储有与客户端对应的异常状态记录数据库。
其中，客户端对应的异常状态记录数据库包括异常状态次数和异常状态时间。上文中的表1示出了一种示例性的异常状态记录数据库，其中，表1包括客户端ID为23、45以及24的客户端所分别对应的异常状态记录数据库。
步骤302、若服务器未存储与客户端对应的异常状态记录数据库，则服务器创建客户端对应的异常状态记录数据库。
在本申请实施例中，若服务器未存储与客户端对应的异常状态记录数据库，则说明客户端是第一次出现异常状态，在这种情况下，服务器可以在本地创建与客户端对应的异常状态记录数据库，在创建与客户端对应的异常状态记录数据库的过程中，服务器可以与将客户端对应的异常状态记录数据库中的异常状态次数设置为第一预设值，例如，该第一预设值可以为1，并将与客户端对应的异常状态记录数据库中的异常状态时间记录为创建该客户端对应的异常状态记录数据库的时间。
步骤303、若服务器存储有与客户端对应的异常状态记录数据库，则服务器对客户端对应的异常状态记录数据库进行更新。
可选的，服务器可以将存储的与客户端对应的异常状态记录数据库中的异常状态次数与第二预设值相加，得到更新后的异常状态次数，其中，更新后的异常状态次数可以表征客户端出现异常状态的次数，该第二预设值可以为1。
可选的，服务器也可以利用客户端当前出现异常状态的时间更新服务器中存储的与客户端对应的异常状态记录数据库中的异常状态时间。
在本申请实施例中，若服务器存储有与客户端对应的异常状态记录数据库，则说明客户端不是第一次出现异常状态，在这种情况下，服务器可以对存储的与客户端对应的异常状态记录数据库中的异常状态次数以及异常状态时间中的至少一个进行更新，使得更新后的异常状态次数能够反映客户端出现异常状态的次数，更新后的异常状态时间能够反映客户端当前出现异常状态的时间。
如上文所述，服务器可以根据记录的客户端的异常状态次数，和/或，根据在记录的客户端的异常状态时间之后客户端的发送状态来确定客户端是否出现故障，下面，本申请实施例将对其中一种可能的技术过程进行简要说明，请参考图4，该技术过程可以包括以下步骤：
步骤401、服务器判断记录的客户端的异常状态次数是否超过第二阈值。
可选的，服务器可以读取与客户端对应的异常状态记录数据库中的异常状态次数，并判断该异常状态次数是否超过第二阈值。
步骤402、若记录的客户端的异常状态次数超过第二阈值，则服务器检测与记录的客户端的第一次异常状态时间的时间间隔是否超过第三预设时长。
可选的，服务器可以读取与客户端对应的异常状态记录数据库中的异常状态时间，若读取到的异常状态时间仅有一个，则服务器可以将读取到的异常状态时间作为客户端的第一次异常状态时间，而后，服务器可以检测当前时刻与客户端的第一次异常状态时间之间的时间间隔是否超过第三预设时长，若读取到的异常状态时间大于一个，则服务器可以将读取到的异常状态时间中最早的异常状态时间作为客户端的第一次异常状态时间，而后，服务器可以检测当前时刻与客户端的第一次异常状态时间之间的时间间隔是否超过第三预设时长。
步骤403、若与记录的客户端的第一次异常状态时间的时间间隔超过第三预设时长，则服务器确定客户端出现故障。
在本申请实施例中，若客户端的异常状态次数超过第二阈值，且，客户端的第一次异常状态时间与当前时刻之间的时间间隔超过第三预设时长，也即是，若客户端出现异常状态的次数较多，且，客户端出现异常状态持续的时长较长，则服务器可以确定客户端出现故障。
由于在网络暂时性断开的情况下，服务器检测到的客户端处于异常状态的次数通常较少，且，客户端处于异常状态的时长也较短，因此，在客户端出现异常状态的次数较多，且，客户端出现异常状态持续的时长较长的情况下，就可以排除网络暂时性断开的情况，此时，服务器可以确定客户端出现故障。
需要指出的是，在本申请的一种可能的实现方式中，若客户端的异常状态次数超过第二阈值，则服务器就可以直接确定客户端出现故障，也即是，若客户端出现异常状态的次数较多，则服务器可以确定客户端出现故障。这是考虑到在网络暂时性断开的情况下，服务器检测到的客户端处于异常状态的次数通常较少，因此，在客户端出现异常状态的次数较多的情况下，就可以排除网络暂时性断开的情况，此时，服务器可以确定客户端出现故障。
如上文所述，服务器可以根据记录的客户端的异常状态次数，和/或，根据在记录的客户端的异常状态时间之后客户端的发送状态来确定客户端是否出现故障，下面，本申请实施例将对另一种可能的技术过程进行简要说明，请参考图5，该技术过程可以包括以下步骤：
步骤501、服务器检测在记录的客户端的异常状态时间之后的第一预设时长内是否接收到客户端发送的心跳请求。
步骤502、若在该第一预设时长内服务器未接收到客户端发送的心跳请求，则服务器确定客户端出现故障。
通常情况下，在网络暂时性断开时，服务器无法成功接收到客户端发送的心跳请求，而随着网络的恢复，服务器就又可以成功接收到客户端发送的心跳请求了。
考虑到这种情况，服务器可以检测在记录的客户端的异常状态时间之后的第一预设时长内是否接收到客户端发送的心跳请求，也即是，服务器可以检测在客户端出现异常状态之后的第一预设时长内是否能接收到客户端发送的心跳请求，若能，则说明是由于网络暂时性断开而导致服务器无法成功接收到客户端发送的心跳请求，若不能，则说明客户端出现了故障。
在本申请的可选实施例中，服务器在记录的客户端的异常状态时间之后的第一预设时长内，可以停止对客户端的异常状态进行记录，这样，可以节约服务器的计算资源。
例如，服务器记录的客户端的异常状态时间为00:30，服务器可以检测在1分钟(第一预设时长)的时间内是否接收到客户端发送的心跳请求，也即是，服务器可以检测在00:31之前是否接收到客户端发送的心跳请求，并据此判断客户端是否出现故障。在这种情况下，00:30至00:31之间客户端的异常状态对服务器判断客户端是否出现故障并没有贡献，因此，服务器可以在00:30至00:31之间停止对客户端的异常状态进行记录，从而节约服务器的计算资源。
在本申请的可选实施例中，若在第一预设时长内接收到客户端发送的心跳请求，则服务器可以判断记录的客户端的异常状态次数是否超过第一阈值，若记录的客户端的异常状态次数超过第一阈值，则服务器可以检测与记录的客户端的第一次异常状态时间的时间间隔是否超过第二预设时长，若与记录的客户端的第一次异常状态时间的时间间隔超过第二预设时长，则服务器确定客户端出现故障。
在实际应用中，客户端的一种故障类型是客户端的通信组件出现了故障，导致客户端与服务器之间的通信连接断断续续，也即是，客户端某一段时间内可以与服务器成功建立通信连接，而另一端时间又无法与服务器成功建立通信连接。
为了识别这一故障，服务器在第一预设时长内接收到客户端发送的心跳请求之后，并不排除客户端出现故障的可能，而是判断记录的客户端的异常状态次数是否超过第一阈值，以及检测与记录的客户端的第一次异常状态时间的时间间隔是否超过第二预设时长，也即是，服务器可以判断客户端出现异常状态的次数较多，且，客户端出现异常状态持续的时长是否较长，若客户端出现异常状态的次数较多，且，客户端出现异常状态持续的时长较长，则说明很可能出现了客户端与服务器之间的通信连接断断续续的现象，因此，在这种情况下，服务器可以确定客户端出现了故障。
此外，需要指出的是，在实际应用中，服务器可以单独采用图4所示的策略来确定客户端是否出现故障，也可以单独采用图5所示的策略来确定客户端是否出现故障，还可以同时采用图4和图5所示的策略来确定客户端是否出现故障。在同时采用图4和图5所示的策略来确定客户端是否出现故障的情况下，若服务器基于图4所示的策略确定客户端出现了故障，同时，基于图5所示的策略也确定客户端出现了故障，则此时，服务器可以只针对客户端进行一次故障报告。
例如，假设客户端第10次出现了异常，按照图4所示的策略，由于服务器记录的客户端的异常状态次数超过9(第二阈值)次，且，与记录的客户端的第一次异常状态时间的时间间隔超过了1个小时(第三预设时长)，因此，服务器可以确定客户端出现了故障。与此同时，按照图5所示的策略，由于服务器检测到在记录的客户端第10次异常状态时间之后的3分钟(第一预设时长)内未接收到客户端发送的心跳请求，因此，服务器可以确定客户端出现了故障。此时，服务器只需要针对客户端进行一次故障报告。
请参考图6，其示出了本申请实施例提供的另一种故障确定方法的流程图，该故障确定方法可以包括以下步骤：
步骤601、客户端周期性地向服务器发送心跳请求。
在本申请的可选实施例中，客户端可以每隔3秒钟向服务器发送一次心跳请求。
步骤602、服务器接收到客户端发送的心跳请求之后向客户端回应心跳请求。
步骤603、服务器判断是否连续n次未接收到客户端发送的心跳请求。
在本申请的可选实施例中，服务器可以判断是否连续3次未收到客户端发送的心跳请求。
步骤604、若服务器连续n次未收到客户端发送的心跳请求，则服务器确定客户端处于异常状态，并对客户端的异常状态进行记录。
其中，对客户端的异常状态进行记录的内容可以包括：1、客户端的标识信息，可以是客户端的IP地址等；2客户端此次出现异常状态的时间；3、客户端出现异常状态的次数。
在本申请的实施例中，若服务器连续n次未收到客户端发送的心跳请求，则服务器可以同时开启一个m分钟(例如，3分钟)的定时器事件。
步骤605、服务器判断p分钟(例如，60分钟)之内客户端出现异常状态的次数是否超过u次(例如，10次)。
需要指出的是，p的值大于m的值。
步骤606、服务器利用m分钟的定时器事件判断在客户端处于异常状态之后m分钟之内是否接收到客户端发送的心跳请求。
步骤607、若在客户端处于异常状态之后m分钟之内未接收到客户端发送的心跳请求，或者，p分钟之内客户端出现异常状态的次数超过u次，则服务器向运维端发送故障排除信息，该故障排除信息用于指示运维人员对客户端进行修复。
需要指出的是，在向运维端发送故障排除信息之后，服务器可以将记录的客户端的异常状态进行清除处理。
还需要指出的是，如果同时满足p分钟客户端出现异常状态的次数超过u次和在客户端处于异常状态之后m分钟之内未接收到客户端发送的心跳请求这两个条件，服务器只向运维端发送一次故障排除信息。
请参考图7，其示出了本申请实施例提供的一种故障确定装置700的框图，该故障确定装置700可以配置于上文所述的服务器中。如图7所示，该故障确定装置700可以包括：接收模块701、记录模块702以及确定模块703。
接收模块701，用于接收客户端发送的心跳请求。
记录模块702，用于若连续n次未成功接收到该客户端发送的心跳请求，则确定该客户端处于异常状态，并对该客户端的异常状态进行记录，其中，n为大于1的正整数。
确定模块703，用于根据记录的该客户端的异常状态次数，和/或，根据在记录的该客户端的异常状态时间之后该客户端的发送状态，确定该客户端是否出现故障。
在本申请的一个实施例中，该确定模块703，具体用于：检测在记录的该客户端的异常状态时间之后的第一预设时长内是否接收到该客户端发送的心跳请求；若在该第一预设时长内未接收到该客户端发送的心跳请求，则确定该客户端出现故障。
在本申请的一个实施例中，该记录模块702，还用于：在记录的该客户端的异常状态时间之后的该第一预设时长内，停止对该客户端的异常状态进行记录。
在本申请的一个实施例中，该确定模块703，还用于：若在该第一预设时长内接收到该客户端发送的心跳请求，判断记录的该客户端的异常状态次数是否超过第一阈值；若记录的该客户端的异常状态次数超过第一阈值，则检测与记录的该客户端的第一次异常状态时间的时间间隔是否超过第二预设时长；若与记录的该客户端的第一次异常状态时间的时间间隔超过该第二预设时长，则确定该客户端出现故障。
在本申请的一个实施例中，该确定模块703，具体用于：判断记录的该客户端的异常状态次数是否超过第二阈值；若记录的该客户端的异常状态次数超过第二阈值，则检测与记录的该客户端的第一次异常状态时间的时间间隔是否超过第三预设时长；若与记录的该客户端的第一次异常状态时间的时间间隔超过该第三预设时长，则确定该客户端出现故障。
在本申请的一个实施例中，该记录模块702，具体用于：检测是否存储有与该客户端对应的异常状态记录数据库，该客户端对应的异常状态记录数据库包括异常状态次数和异常状态时间；若否，则创建该客户端对应的异常状态记录数据库；若是，则对该客户端对应的异常状态记录数据库进行更新。
在本申请的一个实施例中，该记录模块702，具体用于：若连续n次未成功接收到该客户端发送的心跳请求，则检测该客户端是否处于重启过程中；若否，则确定该客户端处于异常状态，并对该客户端的异常状态进行记录。
请参考图8，其示出了本申请实施例提供的另一种故障确定装置800的框图，该故障确定装置800除了包括故障确定装置700包括的各个模块，还包括发送模块704以及删除模块705。
该发送模块704，用于：若确定该客户端出现故障，则向运维端发送故障排除信息，该故障排除信息用于指示运维人员对该客户端进行修复。
该删除模块705，用于：若确定该客户端出现故障，则将存储的该客户端对应的异常状态记录数据进行删除。
本申请实施例提供的故障确定装置，可以实现上述方法实施例，其实现原理和技术效果类似，在此不再赘述。
关于故障确定装置的具体限定可以参见上文中对于故障确定方法的限定，在此不再赘述。上述故障确定装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
图9是根据一示例性实施例示出的一种服务器900的框图。参照图9，服务器900包括处理组件920，其进一步包括一个或多个处理器，以及由存储器922所代表的存储器资源，用于存储可由处理组件920进行的指令或者计算机程序，例如应用程序。存储器922中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件920被配置为进行指令，以进行上述故障确定方法。
服务器900还可以包括一个电源组件924被配置为进行设备900的电源管理，一个有线或无线网络接口926被配置为将设备900连接到网络，和一个输入输出(I/O)接口928。服务器900可以操作基于存储在存储器922的操作系统，例如Window8 8erverTM，Mac O8XTM，UnixTM,LinuxTM，FreeB8DTM或类似。
在示例性实施例中，还提供了一种包括指令的存储介质，例如包括指令的存储器922，上述指令可由服务器900的处理器进行以完成上述方法。存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
在本申请的一个实施例中，提供了一种计算机设备，该计算机设备可以为服务器，该计算机设备包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：
接收客户端发送的心跳请求；若连续n次未成功接收到该客户端发送的心跳请求，则确定该客户端处于异常状态，并对该客户端的异常状态进行记录，其中，n为大于1的正整数；根据记录的该客户端的异常状态次数，和/或，根据在记录的该客户端的异常状态时间之后该客户端的发送状态，确定该客户端是否出现故障。
在本申请的一个实施例中，处理器执行计算机程序时还实现以下步骤：检测在记录的该客户端的异常状态时间之后的第一预设时长内是否接收到该客户端发送的心跳请求；若在该第一预设时长内未接收到该客户端发送的心跳请求，则确定该客户端出现故障。
在本申请的一个实施例中，处理器执行计算机程序时还实现以下步骤：在记录的该客户端的异常状态时间之后的该第一预设时长内，停止对该客户端的异常状态进行记录。
在本申请的一个实施例中，处理器执行计算机程序时还实现以下步骤：若在该第一预设时长内接收到该客户端发送的心跳请求，判断记录的该客户端的异常状态次数是否超过第一阈值；若记录的该客户端的异常状态次数超过第一阈值，则检测与记录的该客户端的第一次异常状态时间的时间间隔是否超过第二预设时长；若与记录的该客户端的第一次异常状态时间的时间间隔超过该第二预设时长，则确定该客户端出现故障。
在本申请的一个实施例中，处理器执行计算机程序时还实现以下步骤：判断记录的该客户端的异常状态次数是否超过第二阈值；若记录的该客户端的异常状态次数超过第二阈值，则检测与记录的该客户端的第一次异常状态时间的时间间隔是否超过第三预设时长；若与记录的该客户端的第一次异常状态时间的时间间隔超过该第三预设时长，则确定该客户端出现故障。
在本申请的一个实施例中，处理器执行计算机程序时还实现以下步骤：检测是否存储有与该客户端对应的异常状态记录数据库，该客户端对应的异常状态记录数据库包括异常状态次数和异常状态时间；若否，则创建该客户端对应的异常状态记录数据库；若是，则对该客户端对应的异常状态记录数据库进行更新。
在本申请的一个实施例中，处理器执行计算机程序时还实现以下步骤：若连续n次未成功接收到该客户端发送的心跳请求，则检测该客户端是否处于重启过程中；若否，则确定该客户端处于异常状态，并对该客户端的异常状态进行记录。
在本申请的一个实施例中，处理器执行计算机程序时还实现以下步骤：若确定该客户端出现故障，则向运维端发送故障排除信息，该故障排除信息用于指示运维人员对该客户端进行修复。
在本申请的一个实施例中，处理器执行计算机程序时还实现以下步骤：若确定该客户端出现故障，则将存储的该客户端对应的异常状态记录数据进行删除。
本申请实施例提供的计算机设备，其实现原理和技术效果与上述方法实施例类似，在此不再赘述。
在本申请的一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：
接收客户端发送的心跳请求；若连续n次未成功接收到该客户端发送的心跳请求，则确定该客户端处于异常状态，并对该客户端的异常状态进行记录，其中，n为大于1的正整数；根据记录的该客户端的异常状态次数，和/或，根据在记录的该客户端的异常状态时间之后该客户端的发送状态，确定该客户端是否出现故障。
在本申请的一个实施例中，计算机程序被处理器执行时还实现以下步骤：检测在记录的该客户端的异常状态时间之后的第一预设时长内是否接收到该客户端发送的心跳请求；若在该第一预设时长内未接收到该客户端发送的心跳请求，则确定该客户端出现故障。
在本申请的一个实施例中，计算机程序被处理器执行时还实现以下步骤：在记录的该客户端的异常状态时间之后的该第一预设时长内，停止对该客户端的异常状态进行记录。
在本申请的一个实施例中，计算机程序被处理器执行时还实现以下步骤：若在该第一预设时长内接收到该客户端发送的心跳请求，判断记录的该客户端的异常状态次数是否超过第一阈值；若记录的该客户端的异常状态次数超过第一阈值，则检测与记录的该客户端的第一次异常状态时间的时间间隔是否超过第二预设时长；若与记录的该客户端的第一次异常状态时间的时间间隔超过该第二预设时长，则确定该客户端出现故障。
在本申请的一个实施例中，计算机程序被处理器执行时还实现以下步骤：判断记录的该客户端的异常状态次数是否超过第二阈值；若记录的该客户端的异常状态次数超过第二阈值，则检测与记录的该客户端的第一次异常状态时间的时间间隔是否超过第三预设时长；若与记录的该客户端的第一次异常状态时间的时间间隔超过该第三预设时长，则确定该客户端出现故障。
在本申请的一个实施例中，计算机程序被处理器执行时还实现以下步骤：检测是否存储有与该客户端对应的异常状态记录数据库，该客户端对应的异常状态记录数据库包括异常状态次数和异常状态时间；若否，则创建该客户端对应的异常状态记录数据库；若是，则对该客户端对应的异常状态记录数据库进行更新。
在本申请的一个实施例中，计算机程序被处理器执行时还实现以下步骤：若连续n次未成功接收到该客户端发送的心跳请求，则检测该客户端是否处于重启过程中；若否，则确定该客户端处于异常状态，并对该客户端的异常状态进行记录。
在本申请的一个实施例中，计算机程序被处理器执行时还实现以下步骤：若确定该客户端出现故障，则向运维端发送故障排除信息，该故障排除信息用于指示运维人员对该客户端进行修复。
在本申请的一个实施例中，计算机程序被处理器执行时还实现以下步骤：若确定该客户端出现故障，则将存储的该客户端对应的异常状态记录数据进行删除。
本实施例提供的计算机可读存储介质，其实现原理和技术效果与上述方法实施例类似，在此不再赘述。
其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。
以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。
