故障恢复方法和用于故障恢复的设备

摘要

本发明实施例提供了故障恢复方法和用于故障恢复的设备。一种故障恢复方法包括：第一设备加载工作实例的配置文件以运行所述工作实例；所述第一设备向第二设备发送所述配置文件，以使所述第二设备在确定所述第一设备无法运行所述工作实例时，根据所述配置文件运行所述工作实例。本发明实施例还提供了用于故障恢复的设备。根据上述技术方案，第一设备通过向第二设备发送配置文件，可以使第二设备对第一设备中出现故障的工作实例进行恢复，从而能够对工作实例进行有效容错，具有高可用性，避免单点故障造成工作实例运行的中断。

权利要求

1.一种故障恢复方法，所述故障恢复方法用于分布式系统，所述分布式系统包括第一设备和第二设备，其特征在于，所述故障恢复方法包括：所述第一设备加载工作实例的配置文件以运行所述工作实例；

所述第一设备向所述第二设备发送所述配置文件，以使所述第二设备在确定所述第一设备无法运行所述工作实例时，根据所述配置文件运行所述工作实例；

所述第一设备在所述工作实例出现故障时，恢复所述工作实例；

所述故障恢复方法还包括：

所述第一设备在恢复所述工作实例失败时，将所述工作实例的状态改变为用于指示所述第一设备无法运行所述工作实例的状态，以使所述第二设备根据该状态确定所述第一设备无法运行所述工作实例；或者所述第一设备在恢复所述工作实例失败时，向所述第二设备发送用于请求所述第二设备运行所述工作实例的请求信息，以使所述第二设备根据所述请求信息确定所述第一设备无法运行所述工作实例。

2.根据权利要求1所述的故障恢复方法，其特征在于，还包括：所述第一设备在所述工作实例的配置文件发生更新时，向所述第二设备发送该工作实例更新后的配置文件。

3.一种故障恢复方法，所述故障恢复方法用于分布式系统，所述分布式系统包括第一设备和第二设备，其特征在于，所述故障恢复方法包括：所述第二设备从所述第一设备接收并存储所述第一设备运行的工作实例的配置文件；

所述第二设备在确定所述第一设备无法运行所述工作实例时，根据所述配置文件运行所述工作实例；

所述故障恢复方法还包括：

所述第二设备检测由所述第一设备设置的所述工作实例的状态，当所述状态指示所述第一设备无法运行所述工作实例时，所述第二设备确定所述第一设备无法运行所述工作实例；或者所述第二设备在收到所述第一设备发送的用于请求所述第二设备运行所述工作实例的请求信息时，确定所述第一设备无法运行所述工作实例。

4.根据权利要求3所述的故障恢复方法，其特征在于，还包括：所述第二设备接收所述第一设备在所述工作实例的配置文件发生更新后发出的更新后的配置文件，并依据该更新后的配置文件更新存储的配置文件。

5.根据权利要求3所述的故障恢复方法，其特征在于，还包括：所述第二设备在运行所述工作实例失败时，记录所述工作实例失败的日志，或者向预定地址或第三方系统发送告警信息。

6.一种用于故障恢复的设备，所述设备用于分布式系统，其特征在于，所述设备包括：加载模块，用于加载工作实例的配置文件以运行所述工作实例；

第一发送模块，用于向所述分布式系统中的另一设备发送所述配置文件，以使所述另一设备在确定所述设备无法运行所述工作实例时，根据所述配置文件运行所述工作实例；

恢复模块，用于在所述工作实例出现故障时，恢复所述工作实例；

所述设备还包括：

更新模块，用于在恢复所述工作实例失败时，将所述工作实例的状态改变为用于指示所述设备无法运行所述工作实例的状态，以使所述另一设备根据该状态确定所述设备无法运行所述工作实例；或者第二发送模块，用于在恢复所述工作实例失败时，向所述另一设备发送用于请求所述另一设备运行所述工作实例的请求信息，以使所述另一设备根据所述请求信息确定所述设备无法运行所述工作实例。

7.根据权利要求6所述的设备，其特征在于，还包括：第三发送模块，用于在所述工作实例的配置文件发生更新时，向所述另一设备发送该工作实例更新后的配置文件。

8.一种用于故障恢复的设备，所述设备用于分布式系统，其特征在于，所述设备包括：第一接收模块，用于从所述分布式系统中的另一设备接收并存储所述另一设备运行的工作实例的配置文件；

恢复模块，用于在确定所述另一设备无法运行所述工作实例时，根据所述配置文件运行所述工作实例；

所述设备还包括：

检测模块，用于检测由所述另一设备设置的所述工作实例的状态，以及第一确定模块，用于当所述状态指示所述另一设备无法运行所述工作实例时，确定所述另一设备无法运行所述工作实例；或者第二确定模块，用于在收到所述另一设备发送的用于请求所述设备运行所述工作实例的请求信息时，确定所述另一设备无法运行所述工作实例。

9.根据权利要求8所述的设备，其特征在于，还包括：第二接收模块，用于接收所述另一设备在所述工作实例的配置文件发生更新后发出的更新后的配置文件；

更新模块，用于依据该更新后的配置文件更新存储的配置文件。

10.根据权利要求8所述的设备，其特征在于，还包括：记录模块，用于在所述设备运行所述工作实例失败时，记录所述工作实例失败的日志；

或者

发送模块，用于在所述设备运行所述工作实例失败时，向预定地址或第三方系统发送告警信息。

说明书

故障恢复方法和用于故障恢复的设备

技术领域

[0001] 本发明涉及计算机领域，并且更具体地，涉及计算机领域中的故障恢复方法和用于故障恢复的设备。

背景技术

[0002] 随着用户数的大幅增长和信息量的巨大增加，在许多行业里，尤其是电信业里，信息技术(Information Technology，IT)系统除了要求极大的处理能力之外，也越来越要求有极高的容错能力。即使面对海量的数据和并发处理，也要达到高可用的目标。

[0003] 当运行的工作实例发生故障时，现有的信息技术系统往往会重新运行该工作实例。然而，由于种种原因，重新运行可能会发生失败，由此导致发生故障的工作实例无法得到及时的恢复。

发明内容

[0004] 本发明提供了故障恢复方法和用于故障恢复的设备，解决了现有技术中故障恢复的局限性问题，能够对工作实例进行有效容错，具有高可用性。

[0005] 一方面，本发明提供了一种故障恢复方法，包括：第一设备加载工作实例的配置文件以运行所述工作实例；所述第一设备向第二设备发送所述配置文件，以使所述第二设备在确定所述第一设备无法运行所述工作实例时，根据所述配置文件运行所述工作实例。

[0006] 另一方面，本发明提供了一种故障恢复方法，包括：第二设备从第一设备接收并存储所述第一设备运行的工作实例的配置文件；所述第二设备在确定所述第一设备无法运行所述工作实例时，根据所述配置文件运行所述工作实例。

[0007] 再一方面，本发明提供了一种用于故障恢复的设备，包括：加载模块，用于加载工作实例的配置文件以运行所述工作实例；第一发送模块，用于向另一设备发送所述配置文件，以使所述另一设备在确定所述设备无法运行所述工作实例时，根据所述配置文件运行所述工作实例。

[0008] 又一方面，本发明提供了一种用于故障恢复的设备，包括：第一接收模块，用于从另一设备接收并存储所述另一设备运行的工作实例的配置文件；恢复模块，用于在确定所述另一设备无法运行所述工作实例时，根据所述配置文件运行所述工作实例。

[0009] 根据上述技术方案，通过利用工作实例的配置文件，可以在异地对出现故障的工作实例进行恢复，从而能够对工作实例进行有效容错，具有高可用性，避免单点故障造成工作实例运行的中断。

附图说明

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

[0011] 图1是根据本发明实施例的故障恢复方法的流程图。

[0012] 图2是根据本发明实施例的另一故障恢复方法的流程图。

[0013] 图3是在分布式系统中进行故障恢复的例子的示意图。

[0014] 图4是在图3所示的例子中进行故障恢复的流程图。

[0015] 图5是在图3所示的例子中进行故障恢复的时序图。

[0016] 图6是根据本发明实施例的用于故障恢复的设备的结构框图。

[0017] 图7是根据本发明实施例的用于故障恢复的另一设备的结构框图。

[0018] 图8是根据本发明实施例的用于故障恢复的再一设备的结构框图。

[0019] 图9是根据本发明实施例的用于故障恢复的又一设备的结构框图。

具体实施方式

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

[0021] 首先，结合图1描述根据本发明实施例的故障恢复方法100。

[0022] 如图1所示，故障恢复方法100包括：

[0023] 在S110中，第一设备加载工作实例的配置文件以运行工作实例；

[0024] 在S120中，第一设备向第二设备发送配置文件，以使第二设备在确定第一设备无法运行工作实例时，根据配置文件运行工作实例。

[0025] 方法100由第一设备执行。第一设备和第二设备可以是分布式系统中的两个设备，它们可以协同完成相同的任务，也可以完成不同的任务。第一设备和第二设备之间可以是主-从(master-slave)关系，当作为主设备的第一设备发生故障时，作为从设备的第二设备可以接手工作。第一设备和第二设备也可以是对等(peer-to-peer)关系，相互之间可以进行备份，当某个设备有故障时，其他设备接手其工作。本发明不对第一设备和第二设备之间的关系进行限定。

[0026] 在第一设备和第二设备中都可以运行工作实例。工作实例的运行需要由设备加载该工作实例的配置文件。在第一设备中运行有至少一个工作实例，在第二设备中是否有工作实例运行不作限制。假设，在第一设备中运行有工作实例A1，第一设备由于硬件问题、软件问题等而致使工作实例A1的运行出现故障，导致工作实例A1不能继续运行下去。

[0027] 为了解决工作实例A1出现的故障，第一设备可以将工作实例A1的配置文件发送给第二设备，这样第二设备可以在工作实例A1出现故障时，通过获取的工作实例A1的配置文件而在第二设备上恢复工作实例A1，使得工作实例A1作为第二设备上新建的工作实例B1而继续运行下去。这样，通过利用配置文件而在异地恢复工作实例，可以实现对工作实例的有效容错，具有高可用性，避免单点故障造成工作实例运行的中断。接下来，详细描述根据本发明实施例的S110至S120。

[0028] 在S110中，第一设备通过加载工作实例的配置文件，可以在第一设备中运行该工作实例。加载配置文件的过程与现有技术相同，不再赘述。

[0029] 在S120中，第一设备可以将工作实例的配置文件发送给第二设备，这样如果工作实例出现故障而不能在第一设备中正常运行时，第二设备可以通过加载从第一设备获取的配置文件来运行相应工作实例，从而实现对有故障的工作实例的错误恢复。

[0030] 根据本发明的实施例，当第一设备中运行的某个工作实例(用工作实例A1表示)出现故障时，第一设备可以首先尝试在第一设备内恢复该工作实例。这样，如果在第一设备中恢复工作实例A1成功，则无需第二设备根据配置文件在异地进行恢复了。

[0031] 但是，也有可能第一设备在本地恢复工作实例A1失败。在该情况下，需要在第二设备上进行工作实例的异地恢复。根据本发明的一个实施例，第一设备在恢复工作实例A1失败时，可以将工作实例A1的状态改变为用于指示第一设备无法运行工作实例A1的状态，以使第二设备根据该状态确定第一设备无法运行工作实例A1。在本发明的另一实施例中，第一设备在恢复工作实例A1失败时，可以向第二设备发送用于请求第二设备运行工作实例A1的请求信息，以使第二设备根据请求信息确定第一设备无法运行工作实例A1。这样，第二设备在确定工作实例A1不能在第一设备中正常运行的情况下，可以根据获取的工作实例A1的配置文件在第二设备中进行故障恢复。对工作实例的恢复可以通过继续执行工作实例的后续过程实现，也可以通过重新执行工作实例A1的全过程实现，还可以通过本领域技术人员可以想到的其他方式实现。

[0032] 当工作实例出现故障时，优先本地恢复，再进行异地恢复，可以尽量不改变工作实例的运行环境，不因故障的产生而对系统产生较大的影响。通过本地恢复和异地恢复相结合的方式，可以提高容错的有效性，避免单一容错方式下不能有效进行故障恢复。从而，通过本地恢复和异地恢复相结合的方式，可以提高容错的效率和成功率。

[0033] 此外，当需要进行异地恢复时，第一设备可以主动向第二设备发送请求信息以使第二设备进行故障恢复；第一设备也可以仅改变工作实例的状态，而由第二设备主动发现故障的存在而进行异地恢复。这样，可以通过灵活的方式便捷地进行异地恢复，实现简单。

[0034] 在具体实现过程中，第一设备可定期向第二设备上报第一设备上运行的工作实例的状态。在这种情况下，当第二设备在连续的至少一个周期(该周期数量可根据具体需要进行预先设置)内都未收到第一设备上报的第一设备上运行的工作实例的状态时，第二设备即可认定第一设备发生故障，即第一设备无法运行工作实例，然后通过加载从第一设备获取的配置文件来运行相应工作实例。如果第一设备发生故障，则第一设备无法运行设置在该第一设备上的所有工作实例。

[0035] 此外，在具体实现过程中，第二设备也可定期向第一设备发送状态查询消息，以查询第一设备上运行的工作实例的状态。在这种情况下，当第二设备在连续的至少一个周期(该周期数量可根据具体需要进行预先设置)内都未收到第一设备返回的第一设备上运行的工作实例的状态(即第一设备连续几个周期都未响应第二设备的状态查询消息)时，第二设备即可认定第一设备发生故障，即第一设备无法运行工作实例，然后通过加载从第一设备获取的配置文件来运行相应工作实例。如果第一设备发生故障，则第一设备无法运行设置在该第一设备上的所有工作实例。

[0036] 根据本发明的一个实施例，第一设备在工作实例的配置文件发生更新时，向第二设备发送该工作实例更新后的配置文件。

[0037] 其中，如果第一设备中某个或某些工作实例的配置文件更新，那么第一设备可以主动向第二设备发送更新后的配置文件，以使第二设备可以根据最新的配置文件正确对故障进行恢复。

[0038] 根据本发明实施例提供的故障恢复方法，通过利用工作实例的配置文件，可以在异地对出现故障的工作实例进行恢复，从而能够对工作实例进行有效容错，具有高可用性，避免单点故障造成工作实例运行的中断。特别是在计算机软件分布式系统中，由于分布式层容错的存在和容器层容错的存在，使得再加上本发明实施例提供的工作实例层的容错，可以实现分层级的容错，从而能够实现更强的故障恢复功能，具有更高的可靠性。同时，由于在工作实例的运行过程中可以恢复故障，使得可以动态并及时地恢复工作实例，避免引入过大延时而影响系统处理性能。

[0039] 图2是从第二设备一侧对本发明实施例提供的故障恢复方法进行描述的流程图。

[0040] 如图2所示，故障恢复方法200包括：

[0041] 在S210中，第二设备从第一设备接收并存储第一设备运行的工作实例的配置文件；

[0042] 在S220中，第二设备在确定第一设备无法运行工作实例时，根据配置文件运行工作实例。

[0043] 方法200由第二设备执行。由于第二设备的操作与上述第一设备的操作相对应，因此，方法200的描述可以参考方法100中的相应内容。

[0044] 在S210中，第二设备从第一设备接收的配置文件可以包括所有在第一设备中运行的工作实例的配置文件。当第一设备加载某工作实例的配置文件时，第一设备可以将该配置文件发送给第二设备，以使第二设备也可以通过加载该配置文件而运行相应的工作实例。

[0045] 第二设备也可能只获取在第一设备中运行的部分工作实例的配置文件，这部分工作实例由于可靠性要求较高或者重要性较大等原因，需要在多个设备中进行配置文件的备份，以实现高效的容错。这样，第一设备可以将这部分工作实例的配置文件发送给第二设备。

[0046] 当然，本领域技术人员可以想到，第二设备也可以请求获取第一设备中某些工作实例的配置文件，以便对这些工作实例进行异地恢复而容错。

[0047] 在S220中，当第二设备确定第一设备上运行的工作实例A1不能在第一设备中正常运行时，第二设备可以加载在S210中获取的工作实例A1的配置文件，从而在第二设备上执行工作实例A1。工作实例A1在第一设备中不能正常运行说明工作实例A1出现故障，该故障可能是由于第一设备中软件执行问题造成的，也可能是由于硬件资源限制造成的，还可能是其他问题引发的工作实例A1不能正常运行。

[0048] 这样，虽然工作实例A1在第一设备上运行失败，但是可以在第二设备上继续得到处理，从而可以进行有效的容错。此外，第二设备恢复的工作实例A1对于该工作实例是否属于与第二设备运行的任务相同的任务没有限制，使得本发明实施例提供的故障恢复方法可以突破现有技术中只能对相同任务进行容错的限制，具有更强的可用性和有效性。

[0049] 根据本发明的实施例，第二设备可以通过多种方式确定某工作实例在第一设备中是否正常运行。

[0050] 根据本发明的一个实施例，在S220之前，还可以包括如下步骤：第二设备检测由第一设备设置的工作实例的状态；当该状态指示第一设备无法运行该工作实例时，第二设备确定第一设备无法运行该工作实例。

[0051] 其中，第一设备可以分别为在第一设备中运行的工作实例A1至An设置状态，通过状态来表明工作实例A1至An是正常运行还是出现故障。例如，可以为工作实例设置三个状态，第一状态为正常态，表示工作实例正常运行；第二状态为过渡态，表示工作实例虽然出现故障但正在尝试本地恢复；第三状态为故障态，表示工作实例在本地恢复失败而不能在本地继续执行。当第二设备检测到的工作实例的状态为第三状态时，说明该工作实例不能在第一设备中正常执行。当第二设备检测到的工作实例的状态为第一状态或第二状态时，第二设备可以确定该工作实例还没有出现故障，因此还不需要进行异地恢复。上述为工作实例设置的状态只是一个例子，并不对本发明的保护范围构成任何限制，本领域技术人员还可以想到其他设置状态的方式，通过状态来告知第二设备是否需要对相应工作实例进行异地故障恢复。

[0052] 根据本发明的一个实施例，在S220之前，还可以包括如下步骤：第二设备在收到第一设备发送的用于请求第二设备运行工作实例的请求信息时，确定第一设备无法运行该工作实例。

[0053] 其中，当第一设备发现工作实例A1出现故障而不能在本地恢复时，或者第一设备发现工作实例A1出现故障但本地没有足够可用的资源来恢复时，或者虽然工作实例A1没有出现故障、但第一设备希望将工作实例A1移动到第二设备上执行时，第一设备可以向第二设备发送请求信息。当第二设备收到请求信息时，第二设备确定工作实例A1出现故障而不能在第一设备中正常执行，因此第二设备确定恢复工作实例A1而排除故障。

[0054] 在具体实现过程中，第一设备可定期向第二设备上报第一设备上运行的工作实例的状态。在这种情况下，当第二设备在连续的至少一个周期(该周期数量可根据具体需要进行预先设置)内都未收到第一设备上报的第一设备上运行的工作实例的状态时，第二设备即可认定第一设备发生故障，即第一设备无法运行工作实例，然后通过加载从第一设备获取的配置文件来运行相应工作实例。如果第一设备发生故障，则第一设备无法运行设置在该第一设备上的所有工作实例。

[0055] 此外，在具体实现过程中，第二设备也可定期向第一设备发送状态查询消息，以查询第一设备上运行的工作实例的状态。在这种情况下，当第二设备在连续的至少一个周期(该周期数量可根据具体需要进行预先设置)内都未收到第一设备返回的第一设备上运行的工作实例的状态(即第一设备连续几个周期都未响应第二设备的状态查询消息)时，第二设备即可认定第一设备发生故障，即第一设备无法运行工作实例，然后通过加载从第一设备获取的配置文件来运行相应工作实例。如果第一设备发生故障，则第一设备无法运行设置在该第一设备上的所有工作实例。

[0056] 根据本发明的一个实施例，第二设备接收第一设备在工作实例的配置文件发生更新后发出的更新后的配置文件，并依据该更新后的配置文件更新存储的配置文件。这样，第二设备中可以保存最新的配置文件，从而可以正确恢复故障，避免使用过时的配置文件而造成资源浪费和无效恢复。

[0057] 根据本发明的一个实施例，在S220之后，还可以包括如下步骤：第二设备在运行工作实例失败时，记录工作实例恢复失败的日志，或者向预定地址或第三方系统发送告警信息。

[0058] 其中，如果第二设备恢复工作实例A1失败，则可以记录相应日志，以等待技术人员根据日志对工作实例A1进行处理。第二设备还可以向预定地址或第三方系统发送告警信息，以及时通知工作实例A1出现故障。预定地址可以是技术人员操作的用于对系统进行管理维护的计算机的地址，可以是该计算机的IP(互联网协议，Internet Protocol)地址，也可以是MAC(介质访问控制，Media Access Control)地址，还可以是其他用于唯一标识该计算机的地址。第三方系统可以是用于进行故障监控的软件系统，也可以是管理员计算机等。

[0059] 根据本发明实施例提供的故障恢复方法，第二设备通过从第一设备获取工作实例的配置文件，可以在异地对出现故障的工作实例进行恢复，从而能够对工作实例进行有效容错，具有高可用性，避免单点故障造成工作实例运行的中断。特别是在计算机软件分布式系统中，由于分布式层容错和容器层容错的存在，使得再加上本发明实施例提供的工作实例层的容错，可以实现分层级的容错，从而能够实现更强的故障恢复功能，具有更高的可靠性。同时，由于在工作实例的运行过程中可以恢复故障，使得可以动态并及时地恢复工作实例，避免引入过大延时而影响系统处理性能。

[0060] 接下来，结合具体的例子来描述根据本发明实施例的故障恢复方法。在如下例子中，将工作实例具体化为对不同国家的话单文件的操作，将第一设备和第二设备具体化为Tomcat服务器。但本领域技术人员可以想到，工作实例也可以是其它处理对象，第一设备和第二设备也可以是其他类型的设备，其具体形式对本发明的保护范围不构成限制，在图3至图5中描述的例子只是为了更好地说明本发明的发明构思，以使本领域技术人员更加全面地理解本发明的技术方案，而并不对本发明的保护范围构成任何限制。

[0061] 在图3中示出了分布式系统中的Tomcat服务器A和Tomcat服务器B。Tomcat服务器是Java技术领域常用的开源应用服务器。在每个Tomcat服务器中，可以运行多个工作实例以执行部署的任务。

[0062] 在图3所示的例子中利用了J2EE(Java2平台企业版，Java 2 Platform Enterprise Edition)领域中的软件架构。在该软件架构中，可以在Tomcat服务器中创建Tomcat实例，在Tomcat实例中创建Servlet容器，将CTS(持续运行的电信服务器，Continues Telecom Server)框架部署在Servlet容器中并运行，并在Servlet容器中部署应用程序，应用程序可以表现为不同的工作实例。这里，Tomcat服务器中的内部软件结构只是一个例子，而并不对本发明实现环境构成限制，本领域技术人员可以想到通过诸如J2EE Servlet容器之类的其他软件架构在设备中部署工作实例。

[0063] 在Tomcat服务器构成的分布式系统中，可以将分布式系统分为三层，分别是分布式层、Tomcat层和工作实例层。在分布式层中，可以部署多个Tomcat服务器组成分布式系统，具有天然的防止单点故障的作用。在Tomcat层中，即CTS框架中，可以通过心跳检测机制来检测其他机器上的Tomcat实例是否出现故障。当其他机器上的Tomcat实例出现故障时，该Tomcat实例可以得到重启。在工作实例层中包含多个工作实例，在该层也会存在心跳检测机制，可以通过工作实例层的心跳检测来检测工作实例是否出现故障。

[0064] 如图3所示，在Tomcat服务器A的CTS框架中，运行有用于处理阿根廷地区的话单文件的工作实例和用于处理乌拉圭地区的话单文件的工作实例，分别简称为阿根廷工作实例和乌拉圭工作实例。在Tomcat服务器B的CTS框架中，运行有用于处理智利地区的话单文件的工作实例，简称为智利工作实例。

[0065] Tomcat服务器处于分布式层，CTS框架处于容器层，三个工作实例处于工作实例层。在图3中示出了CTS框架之间的心跳检测，当该心跳检测机制检测到某CTS框架故障时，可以重启该CTS框架。另外，在工作实例层的三个工作实例之间也存在心跳检测机制，但是未在图3中示出，当工作实例层的心跳检测机制检测到某个工作实例的故障时，可以在本地重启或异地恢复该工作实例。

[0066] 通常在一个Tomcat服务器中建立一个Tomcat实例。为了描述的简便，在图3中示出的是在Tomcat服务器A中运行的Tomcat实例A以及在Tomcat服务器B中运行的Tomcat实例B。

[0067] 当Tomcat实例A中的阿根廷工作实例出现故障时，可能是该阿根廷工作实例出现故障，也可能是Tomcat实例A中的CTS框架出现故障。如果是该阿根廷工作实例出现故障，则可以在Tomcat实例A中的CTS框架中重启该工作实例。如果是Tomcat实例A中的CTS框架出现故障，那么第二层心跳检测可以检测到出现故障的CTS框架，并尝试重启该CTS框架，当CTS框架重启成功时，阿根廷工作实例在本地得到恢复。阿根廷工作实例的故障可以由第三层的心跳检测机制发现，并触发在本地(即Tomcat实例A)或远程(即Tomcat实例B)进行故障恢复。当Tomcat实例A本地恢复失败之后，可以在Tomcat实例B中恢复阿根廷工作实例。如果Tomcat实例B恢复阿根廷工作实例成功，则阿根廷工作实例在Tomcat实例B的CTS框架中继续运行。从而实现对工作实例的恢复。

[0068] 此外，通常，第三层的心跳检测的检测周期比第二层的心跳检测的检测周期长。通过容器层和工作实例层的心跳检测机制都可以对出现故障的工作实例进行恢复，从而可实现多层级容错，具有更高的可靠性。

[0069] 每个工作实例有对应的实例配置文件，它是工作实例将其工作和参数配置持久化到硬盘上作为文件保存起来的对应物，类似于Java中对象序列化的概念。当分布式系统运行后，各设备上的工作实例会把在本地运行的工作实例的配置文件传输给其他设备。这样，当设备A上的工作实例AX重启不了而不能正常工作时，其他负荷低的设备B可以根据出现故障的工作实例AX的配置文件，在该设备上异地自动恢复出现故障的工作实例，形成工作实例BX。对于设备A的工作实例AX而言，它的工作被动地被设备B接管而形成工作实例BX。另外，工作实例AX在出现故障之前，或者在设备A负荷超载之前，工作实例AX或设备A可以主动地将工作实例AX的执行移交出去，以在设备B上运行工作实例BX。这样的主动地工作交接与被动地工作接管的方法相结合，不仅可以实现故障转移(failover)，而且如果对设备的负荷设定合理的阈值，还可以实现动态的负载均衡，达到极高的高可用性。

[0070] 在Tomcat实例A和Tomcat实例B之间，可以通过如图4所示的流程图来实现对出现故障的阿根廷工作实例的恢复。

[0071] 在S410中，Tomcat实例A和Tomcat实例B初始化成功，运行正常：Tomcat实例A加载了阿根廷和乌拉圭的工作实例配置文件；Tomcat实例B加载了智利的工作实例配置文件。

[0072] 在S415中，Tomcat实例A和B分别启动了各自加载的阿根廷、乌拉圭和智利的工作实例，开始工作，同时，Tomcat实例A和B的CTS框架之间的心跳检测建立。

[0073] 在S420中，如果Tomcat实例A中的CTS框架心跳检测到Tomcat实例B中的CTS框架运行失败，则会尝试启动Tomcat实例B中的CTS框架；反之亦然。这是CTS框架层级的重启恢复。该步骤可以周期性地执行，其执行顺序不受限制。

[0074] 如果通过CTS框架心跳检测还检测到某个工作实例的配置文件出现更新，则将更新后的配置文件同步更新到本地。

[0075] 在S425中，Tomcat实例A和B中的CTS框架可以通过CTS框架心跳检测或其他独立过程，彼此获取对方的工作实例配置文件。

[0076] 在S430中，Tomcat实例A和B中的CTS框架在本地/远程检测到阿根廷工作实例运行失败。在这之后，可以在工作实例层进行重启恢复以排除工作实例的故障。

[0077] 在S435中，Tomcat实例A中的CTS框架把阿根廷工作实例的状态设置为“暂时失败”状态，并在本地尝试重启阿根廷工作实例。

[0078] 在S440中，Tomcat实例A判断本地故障恢复是否成功。如果阿根廷工作实例在本地得到恢复，则前进到S445；如果在本地没有恢复阿根廷工作实例，则前进到S450。这样，可以实现优先在本地恢复工作实例。

[0079] 此外，如果Tomcat实例A本地资源不满足预定要求，例如超过资源利用率的上限、不能提供阿根廷工作实例要求占用的资源等，则Tomcat实例A还可以主动通知远程的Tomcat实例B中的CTS框架恢复阿根廷工作实例，将工作实例主动移交给远程设备。在该情况下，阿根廷工作实例可能没有真实出现故障，但由于Tomcat实例A不能运行它，也可以视为阿根廷工作实例出现故障。

[0080] 如果在S440中Tomcat实例A在本地恢复了阿根廷工作实例，则在S445中，Tomcat实例A中的CTS框架和工作实例都可以正常运行，Tomcat实例A将阿根廷工作实例的状态恢复为“正常”状态。

[0081] 如果在S440中Tomcat实例A在本地恢复阿根廷工作实例失败，则在S450中，Tomcat实例A将阿根廷工作实例的状态设置为“本地永久失败”状态。

[0082] 在S455中，Tomcat实例B中的CTS框架发现Tomcat实例A中阿根廷工作实例的工作状态为“本地永久失败”状态，说明阿根廷工作实例在本地恢复失败，于是Tomcat实例B根据在S425中获取的配置文件，在Tomcat实例B中新建阿根廷工作实例。这样，可以实现本地恢复和远程恢复的结合，为故障恢复提供更多的途径，从而带来更高的可靠性。

[0083] 在S460中，Tomcat实例B确定远程恢复(即在Tomcat实例B中恢复阿根廷工作实例)是否成功。如果远程恢复成功，则前进到S465；如果远程恢复失败，则前进到S470。

[0084] 在S465中，Tomcat实例B中的CTS框架根据阿根廷工作实例的配置文件，在Tomcat实例B上完成阿根廷工作实例的新建，并执行阿根廷工作实例的任务。阿根廷工作实例在该情况下的恢复是通过Tomcat实例B查看Tomcat实例A上记录的阿根廷工作实例的状态而完成的，对于Tomcat实例A而言，这种工作接管(Job Takeover)是被动的。

[0085] 在S470中，Tomcat实例B在远程恢复阿根廷工作实例失败，把阿根廷工作实例的状态改变为“永久失败”状态。

[0086] 在S475中，Tomcat实例B中的CTS框架记录日志，该日志用于指示远程恢复阿根廷工作实例失败，或者Tomcat实例B中的CTS框架向用户指定的地址发送告警。这样，可以便于人工介入，从而可以更及时地解决阿根廷工作实例的故障。

[0087] 在上述包含Tomcat服务器A和Tomcat服务器B的分布式系统中，可以支持热升级，即在Tomcat服务器不停机时，可以修改工作实例的配置参数，从而改变工作行为。当修改了某工作实例的配置参数时，该工作实例会及时将自己的配置文件传输给其他设备，这样其他设备也可以得到最新的工作实例配置文件版本了，从而可以正确的对工作实例进行恢复。

[0088] 接下来，结合图5具体描述在图3所示的例子中恢复阿根廷工作实例的具体过程和细节，该具体过程和细节同样只是一个例子，用于帮助更好地理解本发明的技术方案而不对本发明构成任何限制。

[0089] 为了描述的简便，在下面对5的描述中，用CTS1表示Tomcat实例A中的CTS框架，用CTS2表示Tomcat实例B中的CTS框架。

[0090] 在S505中，Tomcat实例A初始化成功，运行正常：Tomcat实例A加载了阿根廷和乌拉圭的工作实例的配置文件。

[0091] 在S510中，Tomcat实例B初始化成功，运行正常：Tomcat实例B加载了智利的工作实例的配置文件。

[0092] 在S515中，Tomcat实例A启动了加载的阿根廷和乌拉圭的工作实例，阿根廷工作实例和乌拉圭工作实例开始正常工作。

[0093] 在S520中，Tomcat实例B启动了加载的智利的工作实例，智利工作实例开始正常工作。

[0094] 接着，CTS1建立与CTS2的心跳检测机制。在S525中，CTS1向CTS2发送启动心跳(SetupHeartBeat)。在S530中，CTS 1从CTS2获取心跳检测到的信息。

[0095] 接着，CTS2建立与CTS1的心跳检测机制。在S535中，CTS2向CTS1发送启动心跳。在S540中，CTS2从CTS1获取心跳检测到的信息。

[0096] 在S530和S540中获取的信息可以包括但不限于网络是否连通、工作实例是什么状态、工作实例配置文件是否更新等。如果工作实例配置文件有更新，则会同步更新到本地。另外，CTS1建立心跳检测机制和CTS2建立心跳检测机制的顺序可以不受上述顺序的限制。

[0097] 在S545中，Tomcat实例A中的CTS框架在本地检测到阿根廷工作实例运行失败，Tomcat实例B中的CTS框架在远程检测到阿根廷工作实例运行失败。接着，Tomcat实例A中的CTS框架把阿根廷工作实例的状态设置为“暂时失败”状态，并在本地尝试重启阿根廷工作实例。

[0098] 在S550中，CTS1确定本地恢复是否成功。如果本地恢复成功，则在S552中Tomcat实例A中的CTS框架和工作实例都运行正常，CTS1把阿根廷工作实例的状态恢复为“正常”状态。如果本地恢复失败，则在S554中Tomcat实例A中的CTS框架把阿根廷工作实例的状态设置为“本地永久失败”状态。

[0099] 在该例子中，假设CTS1在本地恢复阿根廷工作实例失败，则故障恢复流程继续执行。

[0100] 在S555中，CTS2心跳检测定时地运行。

[0101] 在S560中，CTS2检测到CTS1中的阿根廷工作实利实例的状态为“本地永久失败”状态。在该情况下，CTS2尝试在Tomcat实例B中恢复阿根廷工作实例。

[0102] 在S565中，CTS2确定对阿根廷工作实例的远程恢复是否成功。如果远程恢复成功，则在S567中Tomcat实例B中的CTS框架在Tomcat服务器B上根据阿根廷工作实例的配置文件新建阿根廷工作实例。如果远程恢复失败，则在S569中Tomcat实例B中的CTS框架把阿根廷工作实例的状态设置为“永久失败”状态。

[0103] 如果对阿根廷工作实例的远程恢复也失败，那么在S570中，Tomcat实例B中的CTS框架记录日志，或者发送告警给用户指定的地址，例如第三方监控告警软件所在的地址，以便人工介入。这样，通过上述故障恢复流程，可以优先对故障工作实例进行本地恢复，当本地恢复失败后，可以进行远程恢复，这种本地恢复和远程恢复相结合的方式，可以提供更高的可靠性。

[0104] 工作实例的状态并不限于图5中所举的例子，在其他实例中还可以为工作实例设置其他状态来表征工作实例是否可以在本地恢复或远程恢复。此外，在故障恢复流程的具体实现中，可以为不同的步骤编写不同的函数来实现。举例来说，可以在S505和S510中编写函数load( )，在S515和S520中编写函数startup( )，在S545中编写函数VerifyStatus( )，这些函数分别实现对应步骤的操作。当然，函数的名称只是一个例子而不构成限制。另外，在本实施例中，本地重启恢复与远程重建恢复都可以有相同的函数调用接口，是否恢复成功，可以由具体的程序员来决定。例如，可以通过VerifyStatus( )函数调用后返回的值来指明工作实例当前的运行状态。此外，在图5所示的流程中，也可以使CTS框架定义每个工作实例所需的接口函数。例如，用startup( )函数来启动业务的工作实例，用shutdown( )函数来停止该工作实例，用reactivate( )函数来重新激活该工作实例，reactivate( )函数的默认实现可以是先调用shutdown( )函数、再调用startup( )函数。

[0105] 根据本发明实施例提供的根据配置文件来恢复工作实例的故障恢复方法，可以通过分层级的方式来进行容错，即分别在分布式层、容器层和工作实例层进行容错，从而为系统带来更高的可靠性。无论将同样的工作实例灵活地部署在一台设备或多台设备上组成同构的分布式系统，还是将不同的工作实例部署为异构工作任务的分布式系统，都可以实现故障恢复。同时本发明实施例还提出了主动的工作移交和被动的工作接管相结合的方法，结合动态通知更新后的工作实例配置文件的方式，可以达到极强的高可用性。

[0106] 上面描述了根据本发明实施例的故障恢复方法，下面描述根据本发明实施例的设备的结构框图。由于下述的各设备可以用于进行故障恢复，因此其各模块的操作可以参考上述方法的描述和各例子中的描述，为了避免重复，下文只作简单说明而不具体展开。

[0107] 图6是根据本发明实施例的用于故障恢复的设备600的结构框图。

[0108] 设备600包括加载模块610和第一发送模块620。设备600可以是分布式系统中的处理设备，还可以是服务器设备，也可以是本领域技术人员可以想到的其他计算机设备。加载模块610可以通过处理器实现，第一发送模块620可以通过输出接口实现。

[0109] 加载模块610用于加载工作实例的配置文件以运行工作实例。第一发送模块620用于向另一设备发送配置文件，以使另一设备在确定设备600无法运行工作实例时，根据配置文件运行工作实例。

[0110] 加载模块610和第一发送模块620的上述和其他操作和/或功能可以参考上述方法100和相关部分的描述，为了避免重复，不再赘述。

[0111] 根据本发明实施例提供的用于故障恢复的设备，通过向另一设备发送配置文件，可以使另一设备根据配置文件对该设备上出现故障的工作实例进行恢复，实现有效容错，具有高可用性，避免单点故障造成工作实例运行的中断。另外，由于在计算机软件分布式系统中分布式层容错和容器层容错的存在，使得再加上本发明实施例提供的工作实例层的容错，可以实现分层级的容错，从而能够实现更强的故障恢复功能，具有更高的可靠性。同时，由于在工作实例的运行过程中可以恢复故障，使得可以动态并及时地恢复工作实例，避免引入过大延时而影响系统处理性能。

[0112] 图7是根据本发明实施例的用于故障恢复的设备700的结构框图。

[0113] 设备700的加载模块710和第一发送模块720与设备600的加载模块610和第一发送模块620基本相同。

[0114] 根据本发明的一个实施例，设备700还可以包括恢复模块730，恢复模块730可以通过处理器实现。恢复模块730用于在工作实例出现故障时，恢复工作实例。

[0115] 根据本发明的一个实施例，当设备700可以通过恢复模块730在本地对出现故障的工作实例进行本地恢复时，设备700还可以包括更新模块740和/或第二发送模块750，更新模块740可以通过处理器实现，第二发送模块750可以通过输出接口实现。更新模块740用于在恢复工作实例失败时，将该工作实例的状态改变为用于指示设备700无法运行该工作实例的状态，以使另一设备根据该状态确定设备700无法运行该工作实例。第二发送模块750用于在恢复工作实例失败时，向另一设备发送用于请求另一设备运行该工作实例的请求信息，以使另一设备根据请求信息确定设备700无法运行该工作实例。这样，通过将本地恢复和异地恢复相结合的方式，可以增大故障恢复的效率和成功率，增强容错性能，提高可靠性。

[0116] 根据本发明的一个实施例，设备700还可以包括第三发送模块760，第三发送模块760可以通过输出接口实现。第三发送模块760用于在工作实例的配置文件发生更新时，向另一设备发送该工作实例更新后的配置文件。这样，当工作实例出现故障后，另一设备可以根据最新的配置文件进行正确的故障恢复。

[0117] 恢复模块730、更新模块740、第二发送模块750和第三发送模块760的上述和其他操作和/或功能可以参考上述方法100和相关部分的描述，为了避免重复，不再赘述。

[0118] 根据本发明实施例提供的用于故障恢复的设备，通过主动和/或被动的进行故障恢复，不仅可以对工作实例进行有效容错，还可以在需要时接管其他设备上的工作实例，因此，不仅具有更高的可靠性，还具有高可用性。

[0119] 图8是根据本发明实施例的用于故障恢复的设备800的结构框图。

[0120] 设备800包括第一接收模块810和恢复模块820。设备800可以是分布式系统中的处理设备，还可以是服务器设备，也可以是本领域技术人员可以想到的其他计算机设备。第一接收模块810可以通过输入接口和存储器实现，恢复模块820可以通过处理器实现。

[0121] 第一接收模块810用于从另一设备接收并存储所述另一设备运行的工作实例的配置文件。恢复模块820用于在确定所述另一设备无法运行该工作实例时，根据配置文件运行工作实例。

[0122] 第一接收模块810和恢复模块820的上述和其他操作和/或功能可以参考上述方法200和相关部分的描述，为了避免重复，不再赘述。

[0123] 根据本发明实施例提供的用于故障恢复的设备，该设备通过从另一设备获取工作实例的配置文件，可以在该设备上对另一设备中出现故障的工作实例进行恢复，从而能够对工作实例进行有效容错，具有高可用性，避免单点故障造成工作实例运行的中断。特别是在计算机软件分布式系统中，由于分布式层容错和容器层容错的存在，使得再加上本发明实施例提供的工作实例层的容错，可以实现分层级的容错，从而能够实现更强的故障恢复功能，具有更高的可靠性。同时，由于在工作实例的运行过程中可以恢复故障，使得可以动态并及时地恢复工作实例，避免引入过大延时而影响系统处理性能。

[0124] 图9是根据本发明实施例的用于故障恢复的设备900的结构框图。

[0125] 设备900的第一接收模块910和恢复模块920与设备800的第一接收模块810和恢复模块820基本相同。

[0126] 根据本发明的一个实施例，设备900还可以包括检测模块930和第一确定模块940，检测模块930和第一确定模块940可以通过处理器实现。检测模块930用于检测由另一设备设置的工作实例的状态。第一确定模块940用于当该状态指示另一设备无法运行该工作实例时，确定另一设备无法运行该工作实例。这样，设备900在第一确定模块940确定工作实例不能正常运行时，可以使恢复模块920根据配置文件进行故障恢复。

[0127] 根据本发明的一个实施例，设备900还可以包括第二确定模块950，第二确定模块950可以通过处理器实现。第二确定模块950用于在收到另一设备发送的用于请求设备900运行工作实例的请求信息时，确定另一设备无法运行该工作实例。这样，恢复模块920可以在第二确定模块950确定工作实例出现故障时，根据配置文件对该工作实例进行故障恢复。

[0128] 根据本发明的实施例，设备900可以同时包含检测模块930、第一确定模块940和第二确定模块950。这样，可以将检测模块930和第一确定模块940实现的被动工作接管与第二确定模块950实现的主动工作交接相结合，不仅可以实现故障转移，而且如果对设备的负荷设定合理的阈值，还可以通过主动地工作交接实现动态的负载均衡，达到极高的高可用性。

[0129] 根据本发明的一个实施例，设备900还可以包括第二接收模块960和更新模块970，第二接收模块960可以通过输入接口实现，更新模块970可以通过处理器实现。第二接收模块960用于接收另一设备在工作实例的配置文件发生更新后发出的更新后的配置文件。更新模块970用于依据该更新后的配置文件更新存储的配置文件。这样，设备900可以获取关于工作实例的最新配置文件，便于在工作实例出现故障时进行正确恢复。

[0130] 根据本发明的实施例，设备900还可以包括记录模块980和/或发送模块990，记录模块980可以通过处理器实现，发送模块990可以通过输出接口实现。记录模块980用于在设备900运行工作实例失败时，记录工作实例恢复失败的日志。发送模块990用于在设备900运行工作实例失败时，向预定地址或第三方系统发送告警信息。通过记录工作日志和/或发送告警信息，可以在本地恢复和远程恢复失败而不能由设备自动恢复的情况下，及时便于人工介入，从而可以更快地解决工作实例出现的故障。

[0131] 检测模块930、第一确定模块940、第二确定模块950、第二接收模块960、更新模块970、记录模块980和发送模块990的上述和其他操作和/或功能可以参考上述方法200和相关部分的描述，为了避免重复，不再赘述。

[0132] 此外，在具体实现过程中，图6和图7中的设备600和700均可包括一状态报告模块，用于报告设备600和700上运行的工作实例的状态。在这种情况下，图8和图9中的设备800和900均可包括一状态接收模块，用于接收设备600和700上运行的工作实例的状态。当状态接收模块在连续的至少一个周期(该周期数量可根据具体需要进行预先设置)内都未收到状态报告模块上报的设备600和700上运行的工作实例的状态时，状态接收模块即可认定设备600和700发生故障，即设备600和700无法运行工作实例，此后，设备800和900中的恢复模块820即可通过加载从设备600和700获取的配置文件来运行相应工作实例。如果设备600和700发生故障，则设备600和700无法运行设置在该设备600和700上的所有工作实例。

[0133] 此外，在具体实现过程中，图8和图9中的设备800和900均可包括一状态查询模块，用于定期向设备600和700发送状态查询消息，以查询设备600和700上运行的工作实例的状态。在这种情况下，图6和图7中的设备600和700均可包括一状态响应模块，用于响应状态查询消息，向状态查询模块返回设备600和700上运行的工作实例的状态。当状态查询模块在连续的至少一个周期(该周期数量可根据具体需要进行预先设置)内都未收到状态响应模块返回的设备600和700上运行的工作实例的状态(即状态响应模块连续几个周期都未响应状态查询模块的状态查询消息)时，状态查询模块即可认定设备600和700发生故障，即设备600和700无法运行工作实例，此后，设备800和900中的恢复模块820即可通过加载从设备600和700获取的配置文件来运行相应工作实例。如果设备600和700发生故障，则设备600和700无法运行设置在该设备600和700上的所有工作实例。

[0134] 根据本发明实施例提供的用于故障恢复的设备，通过主动和/或被动的进行故障恢复，不仅可以对工作实例进行有效容错，还可以在需要时接管其他设备上的工作实例，因此，不仅具有更高的可靠性，还具有高可用性。

[0135] 本领域技术人员可以意识到，结合本文中所公开的实施例中描述的各方法步骤和单元，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各实施例的步骤及组成。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

[0136] 结合本文中所公开的实施例描述的方法步骤可以用硬件、处理器执行的软件程序、或者二者的结合来实施。软件程序可以置于随机存取存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM或技术领域内所公知的任意其它形式的存储介质中。

[0137] 尽管已示出和描述了本发明的一些实施例，但本领域技术人员应该理解，在不脱离本发明的原理和精神的情况下，可对这些实施例进行各种修改，这样的修改应落入本发明的范围内。