CN111737060A - 处理组件异常的方法、装置及电子设备 - Google Patents

Abstract

本发明提供了一种处理组件异常的方法、装置及电子设备，涉及大数据技术领域，该方法包括获取组件进程的当前运行状态；将该组件进程的当前运行状态发送给状态管理服务器，以使状态管理服务器根据预先配置的该组件进程的期望运行状态，和该当前运行状态，确定是否重启该组件进程；如果接收到状态管理服务器的重启组件进程的指令，重启该组件进程。本发明实施例通过在外设的状态管理服务器上配置目标组件对应组件进程的期望运行状态，并将该组件进程的实时运行状态发送给该管理服务器，在当前运行状态与其期望运行状态不一致时，可以重启该组件进程或保持进程的当前状态，实现大数据组件异常退出时的自动重启，并且可以更加灵活地配置重启策略。

Description

处理组件异常的方法、装置及电子设备

技术领域

本发明涉及大数据技术领域，尤其是涉及一种处理组件异常的方法、装置及电子设备。

背景技术

大数据组件是构成大数据平台的核心内容，组件一般是运行在集群中的一些进程，当进程所在设备因为故障宕机重启时，或者进程本身遇到异常错误时，进程会异常退出，这时候大数据平台可能因为大数据组件的进程丢失而出现异常。

当前大数据组件异常退出时的重启方式包括以下两种：一种是当组件异常退出时发出告警，由运维人员手动登陆设备重启组件进程；另一种是通过系统管理进程，例如给组件进程配置supervisor或者设置开机自启动，当进程退出时自动重启进程。其中，对于前一种方式，手动重启进程的操作较为繁琐，且耗时较多；对于后一种方式，只要进程退出就执行重启，重启策略单一，重启策略的配置灵活性较差，且无法将组件进程重启与否的信息发送给运维人员。

整体而言，现有的大数据组件异常退出时的自重启方式，重启策略的配置灵活性较差。

发明内容

有鉴于此，本发明的目的在于提供一种处理组件异常的方法、装置及电子设备，可以在大数据组件异常退出时，自动重启组件进程，并且重启策略的配置灵活性更佳。

第一方面，本发明实施例提供了一种处理组件异常的方法，该方法应用于第一服务器，该第一服务器上运行有目标组件对应的组件进程，该方法包括：获取该组件进程的当前运行状态；将该组件进程的当前运行状态发送给状态管理服务器，以使该状态管理服务器根据预先配置的该组件进程的期望运行状态，和该当前运行状态，确定是否重启该组件进程；如果接收到该状态管理服务器的重启该组件进程的指令，重启该组件进程。

在本发明较佳的实施方式中，该获取该组件进程的当前运行状态的步骤，包括：定时检测该组件进程是否存活，得到该组件进程的当前运行状态。

在本发明较佳的实施方式中，上述根据预先配置的该组件进程的期望运行状态，和该当前运行状态，确定是否重启该组件进程的步骤，包括：如果该组件进程的当前运行状态为死亡状态(dead)，且预先配置的期望运行状态为正常运行(running)，确定重启该组件进程；如果该组件进程的当前运行状态为死亡状态(dead)，且预先配置的期望运行状态为维持现状(maintain)，确定不重启该组件进程。

在本发明较佳的实施方式中，上述如果接收到该状态管理服务器的重启该组件进程的指令，重启该组件进程的步骤，包括：如果接收到该状态管理服务器的重启该组件进程的指令，按照预设的重启策略重启该组件进程；该指令由该状态管理服务器在确定重启该组件进程时发出。

在本发明较佳的实施方式中，在上述状态管理服务器上还设置有开关控件，当该开关控件关闭时，该状态管理服务器不向该第一服务器发送针对该组件进程的重启指令。

在本发明较佳的实施方式中，上述重启策略包括该组件进程的重启执行参数；上述按照预设的重启策略重启该组件进程的步骤，包括：根据该重启执行参数重启该组件进程；其中，该重启执行参数包括：重启生命周期内的最大重启尝试次数，单个时间窗口内的最大重启尝试次数，该时间窗口的长度，以及两次重启尝试之间的时间间隔；并且，该重启生命周期包括多个该时间窗口。

在本发明较佳的实施方式中，上述状态管理服务器还与预设的网页模块通信连接，该网页模块用于展示该组件进程的当前运行状态，重启尝试次数，以及重启失败的告警信息。

第二方面，本发明实施例还提供了一种处理组件异常的装置，该装置应用于第一服务器，该第一服务器上运行有目标组件对应的组件进程，该装置包括：当前运行状态获取模块，用于获取该组件进程的当前运行状态；当前运行状态发送模块，用于将该组件进程的当前运行状态发送给状态管理服务器，以使该状态管理服务器根据预先配置的该组件进程的期望运行状态，和该当前运行状态，确定是否重启该组件进程；组件进程重启模块，用于如果接收到该状态管理服务器的重启该组件进程的指令，重启该组件进程。

第三方面，本发明实施例还提供了一种电子设备，该电子设备包括处理器和存储器，该存储器存储有能够被该处理器执行的计算机可执行指令，该处理器执行该计算机可执行指令以实现上述处理组件异常的方法。

第四方面，本发明实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令在被处理器调用和执行时，计算机可执行指令促使处理器实现上述处理组件异常的方法。

本发明实施例带来了以下有益效果：

本发明实施例提供的一种处理组件异常的方法、装置及电子设备，获取该组件进程的当前运行状态；将该组件进程的当前运行状态发送给状态管理服务器，以使该状态管理服务器根据预先配置的该组件进程的期望运行状态，和该当前运行状态，确定是否重启该组件进程；如果接收到该状态管理服务器的重启该组件进程的指令，重启该组件进程。该方式中，通过在外设的状态管理服务器上配置目标组件对应组件进程的期望运行状态，并将该组件进程的实时运行状态发送给该管理服务器，以使其在该组件进程的当前运行状态与其期望运行状态不一致时，可以重启该组件进程或保持进程的当前状态，实现大数据组件异常退出时，自动重启组件进程，且重启策略的配置灵活性更佳。

本公开的其他特征和优点将在随后的说明书中阐述，或者，部分特征和优点可以从说明书推知或毫无疑义地确定，或者通过实施本公开的上述技术即可得知。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

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

图1为本发明实施例提供的一种处理组件异常的方法的流程示意图；

图2为本发明实施例提供的一种处理组件异常过程中第一服务器和状态管理服务器的交互示意图；

图3为本发明实施例提供的一种处理组件异常的应用场景示意图；

图4为本发明实施例提供的一种状态管理服务器上的状态流转示意图；

图5为本发明实施例提供的一种处理组件异常的装置的结构示意图；

图6为本发明实施例提供的一种电子设备的结构示意图。

图标：31-集群服务器；32-状态管理服务器；33-网页模块；51-当前运行状态获取模块；52-当前运行状态发送模块；53-组件进程重启模块；61-处理器；62-存储器；63-总线；64-通信接口。

具体实施方式

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

大数据平台一般都是由大数据组件(如hadoop、spark、hbase和hive等)部署构成，其主要部署方式是集群化部署，大数据组件安装在多个设备上，并由大数据平台对外提供统一的大数据服务。

考虑到现有的大数据组件异常退出时的自重启方式，重启策略的配置灵活性较差的问题，本发明实施例提供的一种处理组件异常的方法、装置及电子设备，该方式可以应用于大数据组件异常或其他组件异常处理的应用场景中。为便于对本实施例进行理解，首先对本发明实施例所公开的一种处理组件异常的方法进行详细介绍。

参见图1，所示为本发明实施例提供的一种处理组件异常的方法的流程示意图，其中，该方法应用于第一服务器，该第一服务器上运行有目标组件对应的组件进程，由图1可见，该方法包括以下步骤：

步骤S102：获取该组件进程的当前运行状态。

这里，上述第一服务器可以是集群服务器，也可以是非集群服务器；并且，上述目标组件可以是大数据组件，例如hadoop、spark、hbase和hive等，也可以是其他组件，例如用户界面组件、图表组件等。

另外，组件进程是作用于组件工件的一系列用户定义步骤，每个组件至少具有一个已定义的进程，也可以具有多个进程。在本实施例中，目标组件对应的组件进程运行在上述第一服务器上。

通常，进程的运行状态反映进程执行过程的变化，这些状态随着进程的执行和外界条件的变化而转换，例如，在三态模型中进程的运行状态分为三个基本状态，即运行态，就绪态和阻塞态。在其他可能的应用中，对于上述组件进程的运行状态还可以包括死亡(dead)、重启中(autostart)等，在此不作限定。

在实际操作中，为了在组件异常退出时可以进行重启或其他应对措施，需要在组件异常退出时及时获知退出信息。在其中一种可能的实施方式中，可以通过定时检测目标组件对应的组件进程是否存活，得到该组件进程的当前运行状态，进而根据组件进程的当前运行状态获知组件是否异常退出。其中，假设检测到组件进程依然存活，对应当前运行状态为正常运行(running)，则可知目标组件没有异常退出；假设检测到组件进程不存活，也即对应当前运行状态为死亡(dead)，则可知目标组件异常退出。

步骤S104：将该组件进程的当前运行状态发送给状态管理服务器，以使该状态管理服务器根据预先配置的该组件进程的期望运行状态，和该当前运行状态，确定是否重启该组件进程。

在实际操作中，用户可以根据实际需求灵活设置不同组件对应的组件进程的期望运行状态，其中，通常可以设置组件进程的期望运行状态为正常运行(running)或者维持现状(maintain)。

假设组件进程的期望运行状态为正常运行(running)，而该组件进程的当前运行状态也为running，则不需要重启该组件进程；假设该组件进程的期望运行状态为正常运行(running)，而该组件进程的当前运行状态为死亡状态(dead)，则确定重启该组件进程。

在至少一种可能的实施方式中，可以在该状态管理服务器上实现状态机，并通过该状态机实现基于组件进程的当前运行状态和该组件进程的期望运行状态，进行确定是否重启该组件进程的控制操作。这里，状态机由状态寄存器和组合逻辑电路构成，能够根据控制信号按照预先设定的状态进行状态转移，是协调相关信号动作、完成特定操作的控制中心。

步骤S106：如果接收到该状态管理服务器的重启该组件进程的指令，重启该组件进程。

当状态管理服务器确定需要重启该组件进程时，向上述第一服务器发送重启该组件进程的指令，当该第一服务器接收到重启指令时，重启该组件进程。

这样，通过在外设的状态管理服务器上配置目标组件对应组件进程的期望运行状态，并将该组件进程的实时运行状态发送给该管理服务器，以使其在该组件进程的当前运行状态与其期望运行状态不一致时，可以重启该组件进程或保持进程的当前状态，从而实现大数据组件异常退出时，可以自动重启组件进程。相比于现有组件异常退出时的自重启方式，本实施例提供的组件重启方案不需要运维人员手动登陆设备进行重启，并且，相对于系统管理组件重启的方式，本方式可以实现组件进程在异常退出时重启进程或者维持现状，具有更好的灵活性。

本发明实施例提供的一种处理组件异常的方法，获取该组件进程的当前运行状态；将该组件进程的当前运行状态发送给状态管理服务器，以使该状态管理服务器根据预先配置的该组件进程的期望运行状态，和该当前运行状态，确定是否重启该组件进程；如果接收到该状态管理服务器的重启该组件进程的指令，重启该组件进程。该方式实现了大数据组件异常退出时，可以重启该组件进程或保持进程的当前状态，从而可以更加灵活地配置重启策略。

在图1所示处理组件异常的方法的基础上，本实施例从第一服务器和状态管理服务器之间交互通信的角度，重点描述了状态管理服务器根据预先配置的组件进程的期望运行状态，和该组件进程的当前运行状态，确定是否重启该组件进程的实现方式。

如图2所示，其为一种处理组件异常过程中第一服务器和状态管理服务器的交互示意图，由图2可见，该组件异常的处理过程包括下述步骤：

步骤S202：第一服务器获取目标组件对应的组件进程的当前运行状态。

在该第一服务器上运行有目标组件对应的组件进程，由该第一服务器获取该组件进程的当前运行状态。这里，本实施例中的步骤S202，对应上述实施例中的步骤S102，相应内容的描述可以参考前述实施例的对应部分，在此不再赘述。

步骤S204：第一服务器将该组件进程的当前运行状态发送给状态管理服务器。

在其中一种可能的实施方式中，第一服务器通过组件管理服务周期性获取目标组件的组件进程的运行状态，并将当前运行状态发送给管理服务器。

步骤S206：状态管理服务器接收到该组件进程的当前运行状态为死亡状态，且预先配置的期望运行状态为正常运行，确定重启该组件进程。

在本实施例中，预先配置目标组件对应组件进程的期望运行状态为正常运行(running)，其中，如果状态管理服务器接收到第一服务器发送的该组件进程的当前运行状态为死亡状态(dead)，则确定需要重启该组件进程。

在另一种实施方式中，如果该组件进程预先配置的期望运行状态为维持现状(maintain)，而第一服务器接收到该组件进程的当前运行状态为死亡状态(dead)，则确定不重启该组件进程。

步骤S208：状态管理服务器向第一服务器发送重启该组件进程的指令。

状态管理服务器确定重启该组件进程后，向第一服务器发送重启该组件进程的指令。

在其中一种可能的实施方式中，在上述状态管理服务器上还设置有开关控件，当该开关控件关闭时，该状态管理服务器不向该第一服务器发送针对该组件进程的重启指令。这样，只有在该开关控件开启的情况下，状态管理服务器才提供对向第一服务器发送重启指令的服务，否则，组件异常退出不会执行重启操作。

步骤S210：第一服务器按照预设的重启策略重启该组件进程。

在其中一种可能的实施方式中，该重启策略包括该组件进程的重启执行参数，并且，根据该重启执行参数重启该组件进程。具体地，该重启执行参数包括重启生命周期内的最大重启尝试次数，单个时间窗口内的最大重启尝试次数，单个时间窗口的长度，以及两次重启尝试之间的时间间隔；并且，该重启生命周期包括多个该时间窗口。

在实际操作中，为了方便运维人员获取组件进程的重启信息，例如是否重启、重启几次、何时重启等，还可以设置网页模块，并且该网页模块与状态管理服务器通信连接，其中，状态管理服务器将组件进程的重启执行情况上报给该网页模块，并由该网页模块展示该组件进程的当前运行状态，重启尝试次数，以及重启失败的告警信息等。

本实施例提供的处理组件异常的方法，通过在状态管理服务器上预先设置目标组件对应组件进程的期望运行状态为正常运行(running)，当状态管理服务器从第一服务器接收到该组件进程的实际运行状态为死亡状态(dead)时，向第一服务器发送重启该组件进程的指令，以使第一服务器根据预设的重启策略重启该组件进程，从而实现了组件异常退出时，可以自动重启该组件进程。

为了更清楚理解前述实施例的处理组件异常的方法，本实施例还介绍了一个处理组件异常的应用实例。

如图3所示为一种处理组件异常的应用场景示意图，在图3示出的实施方式中，集群服务器31与状态管理服务器32通信连接，并且，该状态管理服务器32还与网页模块33通信连接。

其中，在该集群服务器31上运行有大数据组件，实例性的包括Hadoop、Spark和Hbase,其中，在该集群服务器31上运行有组件管理服务(agent)，agent通过持有大数据组件管理脚本来进行大数据组件的管理。

另外，在状态管理服务器32上实现了一个进行状态管理的状态机。在实际操作中，agent定时(例如1分钟、5分钟等)检查大数据组件进程是否存活，并将存活结果上报给状态管理服务器32，状态管理服务器32接收组件进程的存活结果，并将结果传给状态机，由状态机根据组件进程的存活情况(当前运行状态)以及预设的期望运行状态，判断该组件进程是否需要重启，如果需要重启，则通知agent执行大数据组件重启指令，如果不需要重启，则忽略组件进程的当前运行状态。

在本实施例中，还在状态管理服务器32端提供大数据组件是否开启自动重启的开关控件，如果关闭该开关控件，则组件异常退出时将不会执行异常重启。

此外，本实施例中状态管理服务器32上的状态机的判断逻辑参见图4，其为一种状态管理服务器32上的状态流转示意图，在图4示出的实施方式中，该状态机包括四种状态，分别为正常运行(running)、维持现状(maintain)、死亡状态(dead)和重启(autostart)。

其中，如果agent上报的组件进程的当前运行状态是dead，而状态管理服务器32上预设的期望运行状态是running，由于dead不等于runnnig，此时，状态管理服务器32会判断该组件进程的下一个状态可能是autostart或者maintain。

如果用户关闭了管理服务器上的重启开关控件，也即关闭了组件进程的自动重启功能，此时，下一个状态进入maintain状态，无需自动重启。

如果用户打开了上述开关控件，也即开启了组件进程的自动重启功能，则下一个状态进入autostart状态，此时，会触发状态管理服务器32通知agent执行该组件进程的重启操作。

其中，如果该组件进程重启成功，则会向状态管理服务器32返回组件进程的当前运行状态为running，此时，由于组件进程的期望运行状态已经改变为autostart，而running不等于autostart，则组件进程的状态进入到runnig状态。而如果该组件进程重启失败，则状态管理服务器32会接收到该组件进程上报的当前运行状态为dead，由于dead不等于autostart，此时状态管理服务器32又会再次进入到autostart状态，并通知agent再次重试启动该组件进程。

具体地，agent在执行重启组件进程时，会根据预先设定的配置策略进行重启，具体重启策略包括下述重启执行参数：

enabled：集群级别自动拉起功能的开关；

lifetime_max_count：自动拉起生命周期的最大次数；

max_count：在一个时间窗口内，自动拉起动作的最大尝试次数；

window_in_minutes：自动拉起功能的时间窗口长度；

retry_interval：两次重试之间的时间间隔。

其中，状态管理服务器32按照上述重启策略不断重试，直到组件进程重启成功或者到达重启次数上限，当重试到达上限时，通过网页模块33进行告警提示。这里，上述重启策略可以根据实际应用环境灵活调整，在此不作限定。

本实施例提供的处理组件异常的方法，实现了大数据组件异常退出时，自动重启组件进程，且可以灵活地配置重启策略。

对应于图1中所示的理组件异常的方法，本发明实施例还提供了一种处理组件异常的装置，参见图5，所示为一种处理组件异常的装置的结构示意图，该装置应用于第一服务器，该第一服务器上运行有目标组件对应的组件进程。在图5示出的实施方式中，该装置包括依次连接的当前运行状态获取模块51、当前运行状态发送模块52和组件进程重启模块53，其中，各个模块的功能如下：

当前运行状态获取模块51，用于获取该组件进程的当前运行状态；

当前运行状态发送模块52，用于将该组件进程的当前运行状态发送给状态管理服务器，以使该状态管理服务器根据预先配置的该组件进程的期望运行状态，和该当前运行状态，确定是否重启该组件进程；

组件进程重启模块53，用于如果接收到该状态管理服务器的重启该组件进程的指令，重启该组件进程。

本发明实施例提供的一种处理组件异常的装置，获取该组件进程的当前运行状态；将该组件进程的当前运行状态发送给状态管理服务器，以使该状态管理服务器根据预先配置的该组件进程的期望运行状态，和该当前运行状态，确定是否重启该组件进程；如果接收到该状态管理服务器的重启该组件进程的指令，重启该组件进程。该装置中，通过在外设的状态管理服务器上配置目标组件对应组件进程的期望运行状态，并将该组件进程的实时运行状态发送给该管理服务器，以使其在该组件进程的当前运行状态与其期望运行状态不一致时，可以重启该组件进程或保持进程的当前状态，实现大数据组件异常退出时，自动重启组件进程，且重启策略的配置灵活性更佳。

在其中一种可能的实施方式中，上述当前运行状态获取模块51还用于：定时检测该组件进程是否存活，得到该组件进程的当前运行状态。

在另一种可能的实施方式中，上述根据预先配置的该组件进程的期望运行状态，和该当前运行状态，确定是否重启该组件进程的步骤，包括：如果该组件进程的当前运行状态为死亡状态(dead)，且预先配置的期望运行状态为正常运行(running)，确定重启该组件进程；如果该组件进程的当前运行状态为死亡状态(dead)，且预先配置的期望运行状态为维持现状(maintain)，确定不重启该组件进程。

在另一种可能的实施方式中，上述组件进程重启模块53还用于：如果接收到该状态管理服务器的重启该组件进程的指令，按照预设的重启策略重启该组件进程；该指令由该状态管理服务器在确定重启该组件进程时发出。

在另一种可能的实施方式中，在上述状态管理服务器上还设置有开关控件，当该开关控件关闭时，该状态管理服务器不向该第一服务器发送针对该组件进程的重启指令。

在另一种可能的实施方式中，上述重启策略包括该组件进程的重启执行参数；上述组件进程重启模块53还用于：根据该重启执行参数重启该组件进程；其中，该重启执行参数包括：重启生命周期内的最大重启尝试次数，单个时间窗口内的最大重启尝试次数，该时间窗口的长度，以及两次重启尝试之间的时间间隔；并且，该重启生命周期包括多个该时间窗口。

在另一种可能的实施方式中，上述状态管理服务器还与预设的网页模块通信连接，该网页模块用于展示该组件进程的当前运行状态，重启尝试次数，以及重启失败的告警信息。

本发明实施例提供的处理组件异常的装置，其实现原理及产生的技术效果和前述处理组件异常的方法实施例相同，为简要描述，处理组件异常的装置的实施例部分未提及之处，可参考前述处理组件异常的方法实施例中相应内容。

本发明实施例还提供了一种电子设备，如图6所示，为该电子设备的结构示意图，其中，该电子设备包括处理器61和存储器62，该存储器62存储有能够被该处理器61执行的机器可执行指令，该处理器61执行该机器可执行指令以实现上述处理组件异常的方法。

在图6示出的实施方式中，该电子设备还包括总线63和通信接口64，其中，处理器61、通信接口64和存储器62通过总线连接。

其中，存储器62可能包含高速随机存取存储器(RAM，Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口64(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。总线可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

处理器61可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器61中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器61可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital SignalProcessing，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称ASIC)、现成可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器61读取存储器62中的信息，结合其硬件完成前述实施例的处理组件异常的方法的步骤。

本发明实施例还提供了一种机器可读存储介质，该机器可读存储介质存储有机器可执行指令，该机器可执行指令在被处理器调用和执行时，该机器可执行指令促使处理器实现上述处理组件异常的方法，具体实现可参见前述方法实施例，在此不再赘述。

本发明实施例所提供的处理组件异常的方法、处理组件异常的装置和电子设备的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的处理组件异常的方法，具体实现可参见方法实施例，在此不再赘述。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

另外，在本发明实施例的描述中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种处理组件异常的方法，其特征在于，所述方法应用于第一服务器，所述第一服务器上运行有目标组件对应的组件进程，所述方法包括：

获取所述组件进程的当前运行状态；

将所述组件进程的当前运行状态发送给状态管理服务器，以使所述状态管理服务器根据预先配置的所述组件进程的期望运行状态，和所述当前运行状态，确定是否重启所述组件进程；

如果接收到所述状态管理服务器的重启所述组件进程的指令，重启所述组件进程。

2.根据权利要求1所述的处理组件异常的方法，其特征在于，所述获取所述组件进程的当前运行状态的步骤，包括：

定时检测所述组件进程是否存活，得到所述组件进程的当前运行状态。

3.根据权利要求1所述的处理组件异常的方法，其特征在于，所述根据预先配置的所述组件进程的期望运行状态，和所述当前运行状态，确定是否重启所述组件进程的步骤，包括：

如果所述组件进程的当前运行状态为死亡状态，且预先配置的期望运行状态为正常运行，确定重启所述组件进程；

如果所述组件进程的当前运行状态为死亡状态，且预先配置的期望运行状态为维持现状，确定不重启所述组件进程。

4.根据权利要求1所述的处理组件异常的方法，其特征在于，所述如果接收到所述状态管理服务器的重启所述组件进程的指令，重启所述组件进程的步骤，包括：

如果接收到所述状态管理服务器的重启所述组件进程的指令，按照预设的重启策略重启所述组件进程；所述指令由所述状态管理服务器在确定重启所述组件进程时发出。

5.根据权利要求4所述的处理组件异常的方法，其特征在于，在所述状态管理服务器上还设置有开关控件，当所述开关控件关闭时，所述状态管理服务器不向所述第一服务器发送针对所述组件进程的重启指令。

6.根据权利要求4所述的处理组件异常的方法，其特征在于，所述重启策略包括所述组件进程的重启执行参数；

所述按照预设的重启策略重启所述组件进程的步骤，包括：

根据所述重启执行参数重启所述组件进程；其中，所述重启执行参数包括：重启生命周期内的最大重启尝试次数，单个时间窗口内的最大重启尝试次数，所述时间窗口的长度，以及两次重启尝试之间的时间间隔；并且，所述重启生命周期包括多个所述时间窗口。

7.根据权利要求1所述的处理组件异常的方法，其特征在于，所述状态管理服务器还与预设的网页模块通信连接，所述网页模块用于展示所述组件进程的当前运行状态，重启尝试次数，以及重启失败的告警信息。

8.一种处理组件异常的装置，其特征在于，所述装置应用于第一服务器，所述第一服务器上运行有目标组件对应的组件进程，所述装置包括：

当前运行状态获取模块，用于获取所述组件进程的当前运行状态；

当前运行状态发送模块，用于将所述组件进程的当前运行状态发送给状态管理服务器，以使所述状态管理服务器根据预先配置的所述组件进程的期望运行状态，和所述当前运行状态，确定是否重启所述组件进程；

组件进程重启模块，用于如果接收到所述状态管理服务器的重启所述组件进程的指令，重启所述组件进程。

9.一种电子设备，其特征在于，所述电子设备包括处理器和存储器，所述存储器存储有能够被所述处理器执行的计算机可执行指令，所述处理器执行所述计算机可执行指令以实现权利要求1至7任一项所述的处理组件异常的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令在被处理器调用和执行时，计算机可执行指令促使处理器实现权利要求1至7任一项所述的处理组件异常的方法。

Images