CN106933545B - 应用系统及其启动保护方法及装置 - Google Patents

Abstract

本申请实施例提供了一种应用系统及其启动保护方法及装置，该方法包括：在第一应用系统向第二系统发起获取启动所依赖数据的请求后，判断是否在设定时间范围内接收到所述第二系统针对所述请求返回的依赖数据；如果在所述设定时间范围内接收到所述依赖数据，则判断所述依赖数据是否符合预设数据格式；如果所述依赖数据不符合所述预设数据格式，或者如果在所述设定时间范围内未接收到所述依赖数据，则调用预存的所述第一应用系统上一次的成功启动所加载的对应数据，以供所述第一应用系统本次启动时加载。本申请实施例可提高应用系统的启动成功率。

Description

应用系统及其启动保护方法及装置

技术领域

本申请涉及系统启动技术领域，尤其是涉及一种应用系统及其启动保护方法及装置。

背景技术

当前多数的应用系统通常由多个子业务集群组成。例如一个应用系统可以包括：用户相关的子系统、交易相关的子系统、账务相关的子系统等，同时对于一些通用性的资源文件会进行统一存储，比如将所有的文件集中存储在文件子系统等。如图1所示，当一个应用系统启动时，其很可能会依赖于多个外部数据，比如依赖于：其它应用系统提供的数据，数据库(Database,DB)中存储的一些配置信息，以及文件系统中的某些文件数据等。因此，该应用系统只有获取到这些依赖的外部数据后才可能正常启动并提供相应的业务服务。

在实际应用中，应用系统可能会由于一些原因(比如网络抖动、环境问题、以及其它系统竞争资源等)导致启动失败，特别是由于网络长时间断网、DB宕机、数据被意外更改等原因导致的启动失败会直接影响到应用系统的在线业务服务。

虽然很多系统常采用冗余设计的方式来提高系统的可靠性，比如DB常提供主集群+备集群的方式；对于文件系统，在存储时常保存多份数据到不同的节点，当其中某一节点失效时可以切换到其它节点上；而对于应用系统，常采用集群的方式提供服务，当其中某一子系统出现异常时将其下线，并改由其它正常的子系统提供服务。

然而，本申请的发明人发现，即使使用了这些DB、文件系统也可能难以避免应用系统的启动失败。这是因为，系统间的网络抖动(比如应用系统与DB之间的偶发性的网络抖动)，可能不会或者不足以触发主备用间的切换，此外，当DB、文件系统或者底层的应用服务是正常的，但是其提供的应用系统启动所依赖的数据是错误的或者缺失的(比如数据库管理员意外操作了一些错误的数据到DB中，或者程序漏洞导致意外删除了一些文件等)，此时依旧会导致上层的应用系统启动失败。

发明内容

本申请实施例的目的在于提供一种应用系统及其启动保护方法及装置，以提高应用系统的启动成功率。

为达到上述目的，一方面，本申请实施例提供了一种应用系统启动保护方法，包括以下步骤：

在第一应用系统向第二系统发起获取启动所依赖数据的请求后，判断是否在设定时间范围内接收到所述第二系统针对所述请求返回的依赖数据；

如果在所述设定时间范围内接收到所述依赖数据，则判断所述依赖数据是否符合预设数据格式；

如果所述依赖数据不符合所述预设数据格式，或者如果在所述设定时间范围内未接收到所述依赖数据，则调用预存的所述第一应用系统上一次的成功启动所加载的对应数据，以供所述第一应用系统本次启动时加载。

另一方面，本申请实施例还提供了一种应用系统启动保护装置，包括：

数据接收模块，用于在第一应用系统向第二系统发起获取启动所依赖数据的请求后，判断是否在设定时间范围内接收到所述第二系统针对所述请求返回的依赖数据；

格式判断模块，用于当所述数据接收模块在所述设定时间范围内接收到所述依赖数据时，判断所述依赖数据是否符合预设数据格式；

第一启动协调模块，用于当所述依赖数据不符合所述预设数据格式，或者所述数据接收模块在所述设定时间范围内未接收到所述依赖数据时，调用预存的所述第一应用系统上一次的成功启动所加载的对应数据，以供所述第一应用系统本次启动时加载。

再一方面，本申请实施例还提供了一种应用系统，其包括上述的应用系统启动保护装置。

本申请的实施例中，在第一应用系统向第二系统发起获取启动所依赖数据的请求后，判断是否在设定时间范围内接收到第二系统针对请求返回的依赖数据；如果在设定时间范围内未接收到依赖数据，或者虽然在设定时间范围内接收到依赖数据但该依赖数据的格式有问题，则调用预存的第一应用系统上一次的成功启动所加载的对应数据，以供第一应用系统本次启动时加载。由于应用系统上一次的成功启动所加载的对应数据是正确的，因此，即使当前应用系统和其他相关系统之间出现了断网、宕机、网络抖动或者依赖数据格式错误等问题，本申请的实施例仍可以保证应用系统在启动时可加载到正确的启动所依赖数据，从而提高了应用系统的启动成功率。

附图说明

此处所说明的附图用来提供对本申请实施例的进一步理解，构成本申请实施例的一部分，并不构成对本申请实施例的限定。在附图中：

图1为现有技术中一集群系统的组成结构框图；

图2为本申请一实施例的应用系统启动保护方法的流程图；

图3为本申请一实施例的应用系统启动保护装置的结构框图；

图4为本申请另一实施例的应用系统启动保护装置的结构框图；

图5为本申请一实施例的应用系统结构框图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本申请实施例做进一步详细说明。在此，本申请实施例的示意性实施例及其说明用于解释本申请实施例，但并不作为对本申请实施例的限定。

下面结合附图，对本申请实施例的具体实施方式作进一步的详细说明。

参考图2所示，本申请实施例的应用系统启动保护方法包括以下步骤：

步骤S101、在第一应用系统向第二系统发起获取启动所依赖数据的请求后，接收所述第二系统针对所述请求返回的依赖数据。

本申请实施例中，所述第二系统包括第二应用系统(即相对于第一应用系统的其他应用系统)、文件系统和/或数据库等。此外，本申请实施例的第一应用系统和第二系统均可以是单机的系统，也可以是集群的系统(比如分布式系统等)。

本申请实施例中，这里所述的启动所依赖数据是指应用系统在启动时所需要的存储于其他系统中的依赖数据。举例来说，假设第一应用系统为A，其在启动时除了需要自身存储的启动所依赖数据a(比如一些配置信息等)之外，还需要分别向第二应用系统B获取到b数据，文件系统C获取到c数据，以及数据库D获取到d数据后才可能正常启动。如果A向第二应用系统B发起调用启动所依赖数据的请求，那么此时的启动所依赖数据就是指b数据，类似的，如果A向文件系统C发起访问启动所依赖数据的请求，那么此时的启动所依赖数据就是指c数据，如果A向数据库D发起查询启动所依赖数据的请求，那么此时的启动所依赖数据就是指d数据。

本申请实施例中，第一应用系统向第二系统发起获取启动所依赖数据的请求时机一般可以是第一应用系统启动时；此外，当第二系统中的所述第一应用系统的启动所依赖数据有更新时，所述第一应用系统也可以向第二系统发起获取启动所依赖数据的请求。

步骤S102、判断是否在设定时间范围内接收到所述第二系统针对所述请求返回的依赖数据。如果在设定时间范围内接收到所述第二系统针对所述请求返回的依赖数据，则执行步骤S103；如果在设定时间范围内未接收到所述第二系统针对所述请求返回的依赖数据，则执行步骤S104。

本申请实施例中，设定时间范围一般可以为所述第一应用系统在发出所述请求后的等待时间。并且所述第一应用系统在发出所述请求后的等待时间可以通知机制等方式获得，所述的通知机制例如可以通过回调函数等实现。

步骤S103、判断所述依赖数据是否符合预设数据格式。一般的，第一应用系统向所述第二系统发起的获取启动所依赖数据的请求中会指定启动所依赖数据的数据格式。如果所述依赖数据不符合所述预设数据格式，则执行步骤S104。

步骤S104、调用预存的所述第一应用系统上一次的成功启动所加载的对应数据，以供所述第一应用系统本次启动时加载。

本申请实施例中，所述的上一次的成功启动是指第一应用系统最近一次的成功启动。所述第一应用系统上一次的成功启动说明了当时启动时所加载的启动所依赖数据是正确的，而本申请实例将这种正确数据返回至所述第一应用系统以供其启动加载无疑会极大的提高所述第一应用系统启动成功的几率。

本申请的另一些实施例中，如果所述依赖数据符合所述预设数据格式，则应用系统启动保护方法还可以包括如下步骤：

步骤S105、比较所述依赖数据与预存的所述第一应用系统上一次的成功启动所加载的对应数据是否一致。如果所述依赖数据与预存的所述第一应用系统上一次的成功启动所加载的对应数据一致，则执行步骤S106；如果所述依赖数据与预存的所述第一应用系统上一次的成功启动所加载的对应数据不一致，则执行步骤S107。

本申请实施例中，所述的对应数据是指：所述第一应用系统在每次启动时可能需要加载多份数据，而这些多份数据的其中一份数据可能来自于所述第二系统，那么这份来自于所述第二系统的数据就是本次所述第二系统针对所述请求返回的依赖数据的对应数据。比如，所述第一应用系统上一次的成功启动所加载的数据x来自于所述第二系统，而本次所述第二系统针对所述请求返回的响应中的依赖数据为x’，那么数据x即为数据x’的对应数据，也就说本步骤中的比较对象为x和x’。

步骤S106、保存所述依赖数据，并在所述第一应用系统完成包含所述依赖数据的启动加载后，将本次启动所加载的数据标记为最近一次成功启动时加载的数据。其中，所述的保存一般为本地保存(比如保存到本地磁盘)。

步骤S107、保存所述依赖数据，并在所述第一应用系统完成包含所述依赖数据的启动加载后，检验所述第一应用系统的本次启动是否成功；其中，所述的保存一般为本地保存(比如保存到本地磁盘)。如果所述第一应用系统的本次启动成功，则执行步骤S108；如果所述第一应用系统的本次启动失败，则跳转执行步骤S104，即调用预存的所述第一应用系统上一次的成功启动所加载的对应数据，以供所述第一应用系统再次启动加载。

本申请实施例中所述检验所述第一应用系统的本次启动是否成功可以是一次性的检测。在本申请另一实施例中，所述检验所述第一应用系统的本次启动是否成功还可以是在设定时限(例如在所述第一应用系统完成包含所述依赖数据的启动加载后的一个小时)内多次检验所述第一应用系统的本次启动是否均成功，否则视所述第一应用系统的本次启动为失败。在本申请的一些实施例中，所述的多次检验可以为定时检验(例如每三分钟进行一次检验)。在本申请的另一些实施例中，所述的多次检验可以为随机检验。

此外，本申请实施例中，检验的内容可以包括系统端口是否正常、系统对外响应是否正常、和/或系统是否可提供正常服务。而在本申请另一实施例中，还可以通过事件标记的方式来判断所述第一应用系统是否正常启动，当所述第一应用系统正常启动之后其会进行事件标记(比如写一个文件)，如果在所述第一应用系统启动后的设定时间内收到该事件标记则表明所述第一应用系统已成功启动，否则表明所述第一应用系统启动失败。

步骤S108、将本次启动所加载的数据标记为最近一次成功启动时加载的数据。

本申请实施例中，保存最近一次成功启动时加载的数据的意义在于为所述第一应用系统后续的启动提供便利。在本申请的一实施例中，同一时刻可以保留多个历史版本的成功启动时加载的数据，当有新版本的数据被存储时，过期版本(即最早版本)的数据会被删除掉，这样的好处在于，当所述第一应用系统加载了所述最近一次成功启动的数据后仍然没有成功启动时，还可以考虑通过加载更早版本的成功启动时所加载的数据来重新启动。当然，在本申请的另一实施例中，为了防止历史加载数据过多占用存储资源，一般仅需保留几个(例如三个)版本的成功启动时加载的数据即可。

在本申请的一些实施例中，作为一种优化措施，如果所述依赖数据与所述第一应用系统上一次的成功启动所加载的对应数据不一致，还可以将该依赖数据标记为问题数据并保存。其目的在于，在所述第一应用系统下次向所述第二系统发起获取启动所依赖数据的请求时，如果接收到相同的数据，则可以直接识别为问题数据，并不预加载，以免浪费系统资源。而在本申请的另一些实施例中，如果所述依赖数据与所述第一应用系统上一次的成功启动所加载的对应数据不同，也可以直接删除该依赖数据，以节省存储空间。

虽然上文描述的过程流程包括以特定顺序出现的多个操作，但是，应当清楚了解，这些过程可以包括更多或更少的操作，这些操作可以顺序执行或并行执行(例如使用并行处理器或多线程环境)。

本申请的实施例中，在第一应用系统向第二系统发起获取启动所依赖数据的请求后，判断是否在设定时间范围内接收到第二系统针对请求返回的依赖数据；如果在设定时间范围内未接收到依赖数据，或者虽然在设定时间范围内接收到依赖数据但该依赖数据的格式有问题，则调用预存的第一应用系统上一次的成功启动所加载的对应数据，以供第一应用系统本次启动时加载。由于应用系统上一次的成功启动所加载的对应数据是正确的，因此，即使当前应用系统和其他相关系统之间出现了断网、宕机、网络抖动或者依赖数据格式错误等问题，本申请的实施例仍可以保证应用系统在启动时可加载到正确的启动所依赖数据，从而提高了应用系统的启动成功率。

此外，如果设定时间范围内接收到的依赖数据符合预设数据格式，则比较依赖数据与预存的第一应用系统上一次的成功启动所加载的对应数据是否一致。如果一致，则保存依赖数据并直接加载该依赖数据；如果不一致，则保存依赖数据并在第一应用系统完成包含依赖数据的启动加载后，检验第一应用系统的本次启动是否成功。如果成功，则将本次启动所加载的数据标记为最近一次成功启动时加载的数据。如果失败，则调用预存的第一应用系统上一次的成功启动所加载的对应数据，以供第一应用系统再次启动加载。因此，即使其他相关系统返回的依赖数据的内容有错误的或者有缺失，本申请的实施例仍然可以保证应用系统在启动时可加载到正确的启动所依赖数据，从而进一步提高了应用系统的启动成功率。

参考图3所示，本申请一实施例的应用系统启动保护装置包括：

数据接收模块31，用于在第一应用系统向第二系统发起获取启动所依赖数据的请求后，判断是否在设定时间范围内接收到所述第二系统针对所述请求返回的依赖数据。

本申请实施例中，所述第二系统包括第二应用系统(即相对于第一应用系统的其他应用系统)、文件系统和/或数据库等。此外，本申请实施例的第一应用系统和第二系统均可以是单机的系统，也可以是集群的系统(比如分布式系统等)。

本申请实施例中，这里所述的启动所依赖数据是指应用系统在启动时所需要的存储于其他系统中的依赖数据。举例来说，假设第一应用系统为A，其在启动时除了需要自身存储的启动所依赖数据a(比如一些配置信息等)之外，还需要分别向第二应用系统B获取到b数据，文件系统C获取到c数据，以及数据库D获取到d数据后才可能正常启动。如果A向第二应用系统B发起调用启动所依赖数据的请求，那么此时的启动所依赖数据就是指b数据，类似的，如果A向文件系统C发起访问启动所依赖数据的请求，那么此时的启动所依赖数据就是指c数据，如果A向数据库D发起查询启动所依赖数据的请求，那么此时的启动所依赖数据就是指d数据。

本申请实施例中，第一应用系统向第二系统发起获取启动所依赖数据的请求时机一般可以是第一应用系统启动时；此外，当第二系统中的所述第一应用系统的启动所依赖数据有更新时，所述第一应用系统也可以向第二系统发起获取启动所依赖数据的请求。

本申请实施例中，第一应用系统向第二系统发起获取启动所依赖数据的请求时机一般可以是第一应用系统启动时；此外，当第二系统中的所述第一应用系统的启动所依赖数据有更新时，所述第一应用系统也可以向第二系统发起获取启动所依赖数据的请求。

本申请实施例中，设定时间范围一般可以为所述第一应用系统在发出所述请求后的等待时间。并且所述第一应用系统在发出所述请求后的等待时间可以通知机制等方式获得，所述的通知机制例如可以通过回调函数等实现。

格式判断模块30，用于当所述数据接收模块31在所述设定时间范围内接收到所述依赖数据时，判断所述依赖数据是否符合预设数据格式。一般的，第一应用系统向所述第二系统发起的获取启动所依赖数据的请求中会指定启动所依赖数据的数据格式。

第一启动协调模块32，用于当所述依赖数据不符合所述预设数据格式，或者所述数据接收模块31在所述设定时间范围内未接收到所述依赖数据时，调用预存的所述第一应用系统上一次的成功启动所加载的对应数据，以供所述第一应用系统本次启动时加载。

所述第一应用系统上一次的成功启动说明了当时启动时所加载的启动所依赖数据是正确的，而本申请实例将这种正确数据返回至所述第一应用系统以供其启动加载无疑会极大的提高所述第一应用系统启动成功的几率。

本申请另一些实施例中，应用系统启动保护装置还可以包括：

数据比较模块33，用于当所述依赖数据符合所述预设数据格式时，比较所述依赖数据与预存的所述第一应用系统上一次的成功启动所加载的对应数据是否一致。

本申请实施例中，所述的对应数据是指：所述第一应用系统在每次启动时可能需要加载多份数据，而这些多份数据的其中一份数据可能来自于所述第二系统，那么这份来自于所述第二系统的数据就是本次所述第二系统针对所述请求返回的依赖数据的对应数据。比如，所述第一应用系统上一次的成功启动所加载的数据x来自于所述第二系统，而本次所述第二系统针对所述请求返回的响应中的依赖数据为x’，那么数据x即为数据x’的对应数据，也就说本步骤中的比较对象为x和x’。

第二启动协调模块35，用于当所述依赖数据与预存的所述第一应用系统上一次的成功启动所加载的对应数据不一致时，则保存所述依赖数据。其中，所述的保存一般为本地保存(比如保存到本地磁盘)。

健康检查模块36，用于在所述第一应用系统完成包含所述依赖数据的启动加载后，检验所述第一应用系统的本次启动是否成功。

本申请实施例中所述检验所述第一应用系统的本次启动是否成功可以是一次性的检测。在本申请另一实施例中，所述检验所述第一应用系统的本次启动是否成功还可以是在设定时限(例如在所述第一应用系统完成包含所述依赖数据的启动加载后的一个小时)内多次检验所述第一应用系统的本次启动是否均成功，否则视所述第一应用系统的本次启动为失败。在本申请的一些实施例中，所述的多次检验可以为定时检验(例如每三分钟进行一次检验)。在本申请的另一些实施例中，所述的多次检验可以为随机检验。

此外，本申请实施例中，检验的内容可以包括系统端口是否正常、系统对外响应是否正常、和/或系统是否可提供正常服务。由于上述检验内容属于本领域常规技术手段，在此不必赘述。而在本申请另一实施例中，还可以通过事件标记的方式来判断所述第一应用系统是否正常启动，当所述第一应用系统正常启动之后其会进行事件标记(比如写一个文件)，如果在所述第一应用系统启动后的设定时间内收到该事件标记则表明所述第一应用系统已成功启动，否则表明所述第一应用系统启动失败。

第三启动协调模块37，用于当所述第一应用系统的本次启动失败时，调用预存的所述第一应用系统上一次的成功启动所加载的对应数据，以供所述第一应用系统再次启动加载。

第四启动协调模块34，用于当所述依赖数据与预存的所述第一应用系统上一次的成功启动所加载的对应数据一致时，保存所述依赖数据，并在所述第一应用系统完成包含所述依赖数据的启动加载后，将本次启动所加载的数据标记为最近一次成功启动时加载的数据。其中，所述的保存一般为本地保存(比如保存到本地磁盘)。

第一数据标记模块38，用于当所述第一应用系统的本次启动成功时，将本次启动所加载的数据标记为最近一次成功启动时加载的数据。

本申请实施例中，保存最近一次成功启动时加载的数据的意义在于为所述第一应用系统后续的启动提供便利。在本申请的一实施例中，同一时刻可以保留多个历史版本的成功启动时加载的数据，当有新版本的数据被存储时，过期版本(即最早版本)的数据会被删除掉，这样的好处在于，当所述第一应用系统加载了所述最近一次成功启动的数据后仍然没有成功启动时，还可以考虑通过加载更早版本的成功启动时所加载的数据来重新启动。当然，在本申请的另一实施例中，为了防止历史加载数据过多占用存储资源，一般仅需保留几个(例如三个)版本的成功启动时加载的数据即可。

第二数据标记模块39，用于当所述第一应用系统的本次启动失败时，将所述依赖数据标记为问题数据。在本申请的一些实施例中，作为一种优化措施，如果所述依赖数据与所述第一应用系统上一次的成功启动所加载的对应数据不一致，还可以将该依赖数据标记为问题数据并保存。其目的在于，在所述第一应用系统下次向所述第二系统发起获取启动所依赖数据的请求时，如果接收到相同的数据，则可以直接识别为问题数据，并不预加载，以免浪费系统资源。

结合图4所示，在本申请另一实施例中，在其他模块不变的前提下，上述应用系统启动保护装置的第二数据标记模块39可以替换为数据删除模块39’。所述数据删除模块39’用于当所述第一应用系统的本次启动失败时，删除所述依赖数据，以节省存储空间。

本申请的实施例中，在第一应用系统向第二系统发起获取启动所依赖数据的请求后，数据接收模块判断是否在设定时间范围内接收到第二系统针对请求返回的依赖数据；如果在设定时间范围内未接收到依赖数据，或者虽然在设定时间范围内接收到依赖数据但该依赖数据的格式有问题，则第一启动协调模块调用预存的第一应用系统上一次的成功启动所加载的对应数据，以供第一应用系统本次启动时加载。由于应用系统上一次的成功启动所加载的对应数据是正确的，因此，即使当前应用系统和其他相关系统之间出现了断网、宕机、网络抖动或者依赖数据格式错误等问题，本申请的实施例仍可以保证应用系统在启动时可加载到正确的启动所依赖数据，从而提高了应用系统的启动成功率。

此外，如果设定时间范围内接收到的依赖数据符合预设数据格式，则数据比较模块比较依赖数据与预存的第一应用系统上一次的成功启动所加载的对应数据是否一致。如果一致，则第四启动协调模块保存依赖数据并直接加载该依赖数据；如果不一致，第二启动协调模块保存依赖数据并在第一应用系统完成包含依赖数据的启动加载后，检验第一应用系统的本次启动是否成功。如果成功，则第一数据标记模块将本次启动所加载的数据标记为最近一次成功启动时加载的数据。如果失败，则第三启动协调模块调用预存的第一应用系统上一次的成功启动所加载的对应数据，以供第一应用系统再次启动加载。因此，即使其他相关系统返回的依赖数据的内容有错误的或者有缺失，本申请的实施例仍然可以保证应用系统在启动时可加载到正确的启动所依赖数据，从而进一步提高了应用系统的启动成功率。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

上述装置可作为应用系统的一部分设置于应用系统中，实现其功能。作为另一种实施方式，上述装置也可以独立布置于第一应用系统和第二系统之间实现其功能。

参考图5所示，本申请实施例的应用系统是在原有模块的基础上，设置有应用系统启动保护装置，即应用系统启动保护装置构成本申请实施例的应用系统的一部分，该应用系统启动保护装置通过与应用系统的原有模块及本地磁盘进行交互以实现其功能(例如数据存储时，与本地磁盘进行交互，再比如，返回数据时与应用系统的原有模块进行交互等等)。具体的，请参见上述装置实施例，在此不再赘述。

以上本申请实施例所描述的方法或装置可以直接嵌入可由处理器执行的软件模块中。软件模块可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。

本领域技术人员还可以了解到，本申请实施例列出的各种说明性逻辑块和步骤还可以通过软硬件结合来实现，比如将本申请实施例的频谱分析部分用硬件实现，而其他部分仍以软件实现。至于是通过软件还是软硬件结合来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本申请实施例保护的范围。

以上所述的具体实施例，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请实施例的具体实施例而已，并不用于限定本申请的保护范围，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (11)

1.一种应用系统启动保护方法，其特征在于，应用于第一应用系统，包括以下步骤：

在第一应用系统向第二系统发起获取启动所依赖数据的请求后，判断是否在设定时间范围内接收到所述第二系统针对所述请求返回的依赖数据；其中，启动所依赖数据是指第一应用系统在启动时所需要的存储于所述第二系统中的依赖数据；

如果在所述设定时间范围内接收到所述依赖数据，则判断所述依赖数据是否符合预设数据格式，以及判断所述依赖数据是否为预先存储的问题数据，其中，所述问题数据为启动失败时所对应的依赖数据；

如果所述依赖数据不符合所述预设数据格式，或者所述依赖数据为问题数据，或者如果在所述设定时间范围内未接收到所述依赖数据，则调用预存的所述第一应用系统上一次的成功启动所加载的对应数据，以供所述第一应用系统本次启动时加载；

如果所述依赖数据符合所述预设数据格式，且所述依赖数据不属于问题数据，则比较所述依赖数据与预存的所述第一应用系统上一次的成功启动所加载的对应数据是否一致；

如果所述依赖数据与预存的所述第一应用系统上一次的成功启动所加载的对应数据不一致，则保存所述依赖数据，并在所述第一应用系统完成包含所述依赖数据的启动加载后，检验所述第一应用系统的本次启动是否成功；

如果所述第一应用系统的本次启动失败，则调用预存的所述第一应用系统上一次的成功启动所加载的对应数据，以供所述第一应用系统再次启动加载。

2.根据权利要求1所述的应用系统启动保护方法，其特征在于，还包括：

如果所述第一应用系统的本次启动成功，将本次启动所加载的数据标记为最近一次成功启动时加载的数据。

3.根据权利要求1所述的应用系统启动保护方法，其特征在于，在所述第一应用系统的本次启动失败时，还包括：

删除所述依赖数据，或者将所述依赖数据标记为问题数据。

4.根据权利要求1所述的应用系统启动保护方法，其特征在于，所述检验所述第一应用系统的本次启动是否成功，包括：

在设定时限内多次检验所述第一应用系统的本次启动是否均成功。

5.根据权利要求1所述的应用系统启动保护方法，其特征在于，所述第二系统包括第二应用系统、文件系统和/或数据库。

6.一种应用系统启动保护装置，其特征在于，应用于第一应用系统，包括：

数据接收模块，用于在第一应用系统向第二系统发起获取启动所依赖数据的请求后，判断是否在设定时间范围内接收到所述第二系统针对所述请求返回的依赖数据；其中，启动所依赖数据是指第一应用系统在启动时所需要的存储于所述第二系统中的依赖数据；

格式判断模块，用于当所述数据接收模块在所述设定时间范围内接收到所述依赖数据时，判断所述依赖数据是否符合预设数据格式，以及判断所述依赖数据是否为预先存储的问题数据，其中，所述问题数据为启动失败时所对应的依赖数据；

第一启动协调模块，用于当所述依赖数据不符合所述预设数据格式，或者所述依赖数据为问题数据，或者所述数据接收模块在所述设定时间范围内未接收到所述依赖数据时，调用预存的所述第一应用系统上一次的成功启动所加载的对应数据，以供所述第一应用系统本次启动时加载；

数据比较模块，用于当所述依赖数据符合所述预设数据格式，且所述依赖数据不属于问题数据时，比较所述依赖数据与预存的所述第一应用系统上一次的成功启动所加载的对应数据是否一致；

第二启动协调模块，用于当所述依赖数据与预存的所述第一应用系统上一次的成功启动所加载的对应数据不一致时，则保存所述依赖数据；

健康检查模块，用于在所述第一应用系统完成包含所述依赖数据的启动加载后，检验所述第一应用系统的本次启动是否成功；

第三启动协调模块，用于当所述第一应用系统的本次启动失败时，调用预存的所述第一应用系统上一次的成功启动所加载的对应数据，以供所述第一应用系统再次启动加载。

7.根据权利要求6所述的应用系统启动保护装置，其特征在于，还包括：

第一数据标记模块，用于当所述第一应用系统的本次启动成功时，将本次启动所加载的数据标记为最近一次成功启动时加载的数据。

8.根据权利要求6所述的应用系统启动保护装置，其特征在于，还包括：

数据删除模块，用于当所述第一应用系统的本次启动失败时，删除所述依赖数据；

或者，第二数据标记模块，用于当所述第一应用系统的本次启动失败时，将所述依赖数据标记为问题数据。

9.根据权利要求6所述的应用系统启动保护装置，其特征在于，所述健康检查模块检验所述第一应用系统的本次启动是否成功，包括：

在设定时限内多次检验所述第一应用系统的本次启动是否均成功。

10.根据权利要求6所述的应用系统启动保护装置，其特征在于，所述第二系统包括第二应用系统、文件系统和/或数据库。

11.一种应用系统，其特征在于，其包括权利要求6～10任意一项所述的应用系统启动保护装置。

Images