一种用于分布式程序的容错方法和系统

摘要

本发明旨在提供一种用于分布式程序的容错方法和系统，其能按顺序启动部署在不同容错客户端上的程序进程，当任何一个有依赖关系的进程崩溃时，容错服务器可以根据其上配置好的策略执行相应的操作，而容错客户端只需要利用现有的监视程序执行监视、负责报告进程状态以及接收并执行由容错服务器发送或由运维人员下发的指令，就能够按顺序启动上述进程，以保证工作能正常进行。所述系统具有容错服务器和至少一个容错客户端，容错客户端监视其自身运行的分布式程序的进程的状态，当监视到状态异常时通知容错服务器，容错服务器利用策略执行模块根据自动重启策略或手动重启策略并按照进程依赖关系表格中规定的进程间的依赖关系执行重启容错处理。

说明书

技术领域

本申请涉及一种容错方法和系统，具体而言，涉及一种用于分布式程序的容错方法和系统。

背景技术

监视程序是监视计算机进程运行状态的程序，当监视程序确定被监视的计算机进程出现未运行的情况或出现异常的状况时，监视程序尝试启动或重新启动所述被监视的计算机进程。截至目前，这种监视程序都只能监视本机的计算机进程，其对本机上的进程按顺序来操作，如果其中的一个进程出现了异常则会按照启动顺序来启动其所监视的进程。

但随着对计算机运行能力的日益增大的需求，很多任务已无法由单个计算机处理完成。在此背景下，分布式程序应运而生，因其具有资源共享，负载均衡，安全性高等优点，所以分布式程序的应用越来越广泛。分布式程序利用网络技术在分布式计算机系统中的几台计算机上同时协同执行程序来共同完成一项任务。但一个新的问题是现有的本机进程状态监视程序已难以应对分布式程序的状态监视任务。因此，当分布式程序出错时，管理员必须到分布式计算机系统中的各个计算机处分别查看进程的出错情况，这将消耗管理员大量的时间和精力。

发明内容

本发明的目的在于提供一种用于分布式程序的容错方法和系统，其能按顺序启动部署在不同容错客户端上的程序进程，当任何一个有依赖关系的进程崩溃时，容错服务器可以根据其上配置好的策略执行相应的操作，而容错客户端只需要利用现有的监视程序执行监视、负责报告进程状态以及接收并执行由容错服务器发送或由运维人员下发的指令，就能够按顺序启动上述进程，以保证工作能正常进行。

本发明的目的是通过下述方式实现的：

本发明提供了一种用于分布式程序的容错方法，用于具有容错服务器和至少一个容错客户端的容错系统中，所述方法包括下述步骤：容错客户端利用其进程状态状态监视模块监视其自身运行的分布式程序的进程的状态；当监视到进程状态异常时，容错客户端利用进程状态异常信息生成模块生成进程状态异常信息，并利用通信模块将所述信息发送到容错服务器；容错服务器通过其通信模块接收进程状态异常信息；容错服务器利用策略执行模块根据自动重启策略或手动重启策略并按照进程依赖关系表格中规定的进程间的依赖关系执行重启容错处理，其中所述自动重启策略或手动重启策略是利用策略指定模块预先指定的；在执行重启容错处理后，容错客户端利用通信模块向容错服务器报告进程启动的结果。

本发明还提供了一种用于分布式程序的容错系统，具有容错服务器和至少一个容错客户端。所述容错服务器包括：通信模块，用于与容错客户端进行通信，接收容错客户端发来的进程状态异常信息；策略指定模块，用于预先指定重启容错处理中所使用的自动重启策略或手动重启策略；策略执行模块，根据由策略指定模块预先制定的策略，执行对应的重启容错处理；策略数据库，存储自动重启策略和手动重启策略；进程依赖关系数据库，存储有表示分布式程序进程间依赖关系的进程依赖关系表格。所述容错客户端包括：进程状态监视模块，用于监视其自身运行的分布式程序的进程的状态；进程状态异常信息生成模块，用于在监视到进程状态异常时生成进程状态异常信息；通信模块，用于与容错服务器进行通信，将进程状态异常信息发送到容错服务器。

通过上述的用于分布式程序的容错方法和系统，可以利用现有的监视程序，只需对该程序进行简单设置，增加进程状态异常信息生成模块和通信模块(其中进程状态异常信息生成模块用于在监视到进程状态异常时生成进程状态异常信息，通信模块用于与容错服务器进行通信，将进程状态异常信息发送到容错服务器)，就可以自动监控分布式程序进程的状态，并当分布式程序进程出错时可以自动执行应对处理，省去了管理员到各台计算机分别查看进程运行状况的步骤。此外，当分布式程序进程的部署出现变化时，例如增加新的进程而导致进程关系的增加、或者现有进程关系发生变化，只需要修改或增加策略数据库中相应的策略，同时新增相应的容错客户端，而无需更改其他配置，就可以实现相应的容错机制。

附图说明

在下文中将参照附图描述本发明的具体实施方式，结合下述具体描述，本发明的各个方面和优点将变得显而易见。在所附附图中：

图1A是根据本发明的用于分布式程序的容错系统的框图。

图1B是根据本发明的用于分布式程序的容错系统的物理部署图。

图2根据本发明一个实施方式的用于分布式程序的容错方法的流程图。

图3是采用基于自动重启策略的容错方法的流程图。

图4是采用基于手动重启策略的容错方法的流程图。

图5是采用基于自动重启策略和辅助策略的容错方法的流程图。

具体实施方式

下面，将参照附图描述本发明的具体实施方式。

图1A是根据本发明的用于分布式程序的容错系统的框图。如图1所示，所述容错系统包括容错服务器10、容错客户端20、容错客户端30，所有容错服务器和容错客户端之间都通过网络连接在一起，所述网络包括但不限于局域网、广域网等。并且，应当理解，在此描述的这种配置仅是用于说明的目的，系统可以包括任意数目的容错服务器和容错客户端。

所述容错服务器包括通信模块102、策略指定模块104、策略执行模块106、策略数据库108、进程依赖关系数据库110。所述通信模块102用于与容错客户端进行通信，接收容错客户端发来的进程状态异常信息，所述策略指定模块104用于预先指定重启容错处理中所使用的自动重启策略或手动重启策略，优选地，所述预先指示的方式是用户通过诸如鼠标、键盘之类的计算机输入设备手动输入的，所述策略执行模块106根据由策略指定模块104预先指定的策略，执行对应的重启容错处理，所述策略数据库108存储自动重启策略和手动重启策略，所述进程依赖关系数据库110存储有表示分布式程序进程间依赖关系的进程依赖关系表格。

所述容错客户端包括进程状态状态监视模块202、进程状态异常信息生成模块204和通信模块206。所述进程状态状态监视模块202用于监视其自身运行的分布式程序的进程的状态，所述进程状态异常信息生成模块204用于在监视到进程状态异常时生成进程状态异常信息，所述通信模块206用于与容错服务器进行通信，将进程状态异常信息发送到容错服务器。

上述的结构是本申请的逻辑配置，也就是说，上述的容错客户端和容错服务器属于不同的逻辑结构，实际上其可以配置于相同的或不同的物理节点中。因本申请针对的是分布式程序的容错，所以只需将容错客户端配置于不同的物理节点即可。例如，如图1B所示，对于具有一个容错服务器和两个容错客户端的系统而言，一个容错服务器和一个容错客户端可以物理配置于节点1中，而另一个容错客户端可以物理配置于另一个节点2中。但应当理解，上述配置方式仅是用于说明的目的，系统可以包括任意数目的容错服务器和容错客户端，也可以采用其他的配置，如所述一个容错服务器和两个容错客户端分别配置于三个不同的节点等。

下面对策略进行详细说明。策略一词来自设计模式中的策略模式(Strategy)：它定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法的变化不会影响到使用算法的客户。在本发明中，在策略数据库中存储有应对进程状态异常情况的各种策略。所使用的策略包括自动重启策略和手动重启策略，以及其他的辅助策略。当分布式程序发生异常时，就执行自动重启策略或手动重启策略，同时可选地也可以执行辅助策略。

自动重启策略，是当容错服务器接收到容错客户端发来进程状态异常信息时向容错客户端发送指令使之自动重启的策略，这里自动重启策略又可以分为只发送重启本进程、重启自己以及序号在其后面的所有的、需要按序号全部从头开始的策略。

手动重启策略，是当容错服务器接收到容错客户端发来进程状态异常信息时通知运维人员以使其手动确认是否需重启进程的策略，例如包括：给运维人员发送短信以使其确认重启进程的策略；给运维人员打电话播放某某服务异常语音以使其确认重启进程的策略；给运维人员发送邮件通知以使其确认重启进程的策略等。应当理解，在此描述的这些手动重启策略仅是用于说明的目的，在执行容错处理的过程中，可以使用上述手动重启策略中的任意一个或任意多个的组合，例如发送邮件同时还发报警短信，这就是两种策略的组合。此外，在本发明中可以采用其他在此未明示的任何适合的手动重启策略。

辅助策略是当执行自动重启策略和手动重启策略时执行辅助功能的策略，例如记录错误日志的策略等，但辅助策略并非实现容错机制的必要部分，根据需要，可以不执行辅助策略。此外，在本发明中可以采用其他在此未明示的任何适合的辅助策略。

图2是根据本发明一个实施方式的用于分布式程序的容错方法的流程图。如图2所示，所述方法开始于步骤S201。在步骤S201，容错客户端启动处理主线程，容错服务器启动处理主线程，并检查有无超时的容错客户端。在步骤S202，容错客户端向容错服务器发送登录请求，输入登陆账号及密码。在步骤S203，容错服务器接收容错客户端的登录请求，并核对登陆账号和密码是否与所存储的登录账号和密码匹配，如果核对结果是匹配，则容错服务更新容错客户端的信息。在步骤S204，容错服务器向容错客户端发送登录回复信息，确认容错客户端已成功登录。在步骤S205，容错客户端向容错服务器发送心跳信息。在步骤S206，容错服务器接收并更新容错客户端的心跳信息。容错服务器根据容错客户端是否还在发送心跳来判断二者之间的物理链路是否正常。在步骤S207，容错服务器向容错客户端发送心跳回复信息，确认容错客户端的心跳信息已被成功接收。在步骤S208，容错客户端利用其进程状态监视模块监视在其自身内运行的分布式程序的进程的状态。在步骤S209，当监视到进程状态异常时，容错客户端利用进程状态异常信息生成模块生成进程状态异常信息，并利用通讯模块将其发送到容错服务器。在步骤S210，容错服务器接收进程状态异常信息，并根据自动重启策略或手动重启策略、按照进程依赖关系数据库中定义的进程间的依赖关系，利用策略执行模块执行预定的重启容错处理，其中所述自动或手动重启策略是由运维人员利用策略指定模块预先指定的。在步骤S211，容错客户端向容错服务器报告进程启动结果。处理结束。

图3是采用基于自动重启策略的容错方法的流程图。如图3所示，所述方法开始于步骤S301。在步骤S301中，容错客户端的进程状态监视模块发现自己所监视的进程A出现了异常，就生成进程状态异常信息，并利用通信模块将所述消息发送至容错服务器。在步骤S302，容错服务器接收到进程A状态异常信息，查找进程依赖表格，发现进程B依赖进程A。在步骤303，根据预先指定的自动重启策略，容错服务器向容错客户端发送结束进程B的指令。在步骤304，当容错客户端接收到结束进程B的指令时，则结束进程B，而后将结束进程B成功的执行结果消息回复给容错服务器。在步骤S305，容错服务器接收到结束进程B成功的消息，而后发送重新启动进程A的消息至容错客户端。在步骤S306，容错客户端执行重启进程A的指令，并将重启进程A成功的执行结果消息回复给容错服务器。在步骤S307，容错服务器接收重启进程A成功的消息，而后发送启动进程B的指令。在步骤S308，容错客户端接收启动进程B的指令并启动进程B，而后将启动进程B成功的消息发送至容错服务器。在步骤S309，容错服务器接收所述启动进程B成功的消息。至此本容错方法结束。

图4是采用基于手动重启策略的容错方法的流程图，例如采用向运维人员打电话播放报警录音。如图4所示，所述方法开始于步骤S401。在步骤S401中，容错客户端的进程状态监视模块发现自己所监视的进程A出现了异常，就生成进程状态异常信息，并利用通信模块将所述消息发送至容错服务器。在步骤S402，容错服务器接收到进程A状态异常信息，并查找进程依赖表格，发现进程B依赖进程A。在步骤403，根据预先指定的向运维人员打电话播放报警录音的手动重启策略，容错服务器向运维人员打电话并播放报警录音。在步骤404，当运维人员接收到该电话时就执行手动确认，容错客户端结束进程B，而后容错客户端将结束进程B成功的执行结果消息回复给容错服务器。在步骤S405，容错服务器接收到结束进程B成功的消息，而后发送重新启动进程A的消息至容错客户端。在步骤S406，容错客户端执行重启进程A的指令，并将重启进程A成功的执行结果消息回复给容错服务器。在步骤S407，容错服务器接收重启进程A成功的消息，而后发送启动进程B的指令。在步骤S408，容错客户端接收启动进程B的指令并启动进程B，而后将启动进程B成功的消息发送至容错服务器。在步骤S409，容错服务器接收所述启动进程B成功的消息。至此本容错方法结束。

图5是采用基于自动重启策略和辅助策略的容错方法的流程图。如图5所示，其与图3所示的容错方法的区别仅在于在步骤S309容错服务器收到进程B启动成消息之后还包括步骤S501，由容错服务器记录错误日志，以备日后查验使用。但所述记录错误日志仅是辅助策略的一个具体实施方式，辅助策略并非局例如还可以采用基于手动重启策略和辅助策略的容错方法，例如在所示的方法中添加记录错误日志以及其他任何适合的步骤。

下面将以举例说明的方式描述本申请中的进程依赖关系。

参见下面的表1，是三个示例性的进程名称及进程所存储路径的表格。三个进程分别是网关、控制中心以及录音服务器。但应当理解，这些进程仅是示例性的，还可以使用任意多个数目的其他的进程。

表1

  进程的名字   进程的全路径   网关   C:\infobird\ibserver.exe  控制中心   d:\infobird\ibCtlServer.exe  录音服务器   d:\infobird\ibMonitor.exe[0033]进程依赖关系数据库中存储有定义分布式程序进程间依赖关系的进程依赖关系表。所述表格具有启动序号、进程名称、进程所在客户端名称、延时多少秒后发送下一条指令、定时重启设置、特殊重启标致等项目。下面结合表2，将以控制中心、网关以及录音服务器这三个进程为例一一对各个项目进行解释说明。启动序号表示进程间的依赖关系。

表2(定时启动是所见即所得的)

 启动 序号   进程名称   进程所在客户  端名称 延时多少称数后发送下  一条指令 定时重启设置   特殊重启  标志   1   控制中心   容错客户端1   1   time＝″17:5:5″  WhichWeek＝″7″  everydayRestart＝″TRUE″   0   2   网关   容错客户端2   1   time＝″15:5:5″  WhichWeek＝″7″  everydayRestart＝″TRUE″   1   3   录音服务   容错客户端2   1   time＝″12:5:5″  WhichWeek＝″7″  everydayRestart＝″TRUE″   0

以表2中所示为例，启动序号为2的进程网关依赖于启动序号为1的进程控制中心，而启动序号为3的进程录音服务器依赖于启动序号为2的进程网关，进而间接依赖于启动序号为1的进程控制中心。进程所在客户端名称表明分布式程序的进程分别位于哪个容错客户端中，例如控制中心位于容错客户端1中，进程网关和录音服务器位于容错客户端2中。例如，当进程控制中心发生异常时，控制中心所在的容错客户端1会向容错服务器发送进程状况异常信息，容错服务器接收到该信息，则查找进程依赖表格，发现网关和录音服务器对控制中心具有依赖关系，那么容错服务器就会根据预先指定的策略执行自动或手动的容错处理。以自动容错处理为例，容错服务器向容错客户端2发出结束进程网关和录音服务器的指令。在成功关闭上述两个进程后，容错服务器发送指令到容错客户端1以启动控制中心，而后再发送指令到容错客户端2以先后启动网关和录音服务器。

依赖关系表格中的延时秒数、定时重启设置以及特殊重启标志是可选的。延时秒数是表示在接收到触发信息后到发送下一条指令之间的时间，通过设置该项目，可以避免网络中个别路由故障出现的指令实际到达顺序不正确的现象。定时重启设置用于确保进程可以定时重启，启动序号从1开始，顺序递增，无论程序是出错了(跳框，死了)，还是飞了(进程消失，没启动)，都会按启动顺序来修复。并且，定时启动具有所见即所得的特性，所谓定时启动所见即所得，是指启动的顺序不再与启动顺序、延时秒数、和特殊重启标志有关，而只跟附图中配置的时间、日期有关，也就是说，如果设置定时启动，则只根据“定时重启设置”中设置的时间执行重启。例如，表2所示就是打破了依赖关系在每天的17点5分5秒重启进程控制中心、15点5分5秒重启进程网关、12点5分5秒重启进程录音服务器。此外，如果不想设置定时重启服务，则不定时启动的方法是，把WhichWeek设为空，everydayRestart设置为假。如：WhichWeek＝″″everydayRestart＝″FALSF″参数time(时:分:秒)WhichWeek星期几(1～7)可以定时在每周几的几点钟重起下列应用，如果everydayRestart＝″TRUE″则WhichWeek无效。对于特殊重启标志，当特殊重启标志取0值时，表示只重启自己，跟启动序号无关；当特殊重启标志取1值时，表示重启自己以及序号在其后面的所有的进程；当特殊重启标志取2值时，表示需要按序号全部从头开始启动所有的进程。一般情况下，特殊重启标志均为1，而特殊重启标志0和2是用于打破启动序号的限制的，打破了进程间的依赖关系，一般留作扩展，或者仅仅是实现非常规的启动方式。就像有些程序大部分人都是正常使用，可是程序的开发者却留了后门，紧急时候自己来用的非常规手段。在出现硬件故障、过热等无法恢复的情况时，可以设置值为2的特殊重启标志，此时就可以依序重启所有的分布式程序。值为0的特殊重启标志表示该进程与其他进程间没有依赖关系，是独立的，但为了统一配置启动的需要，将其设置在该表中，并利用0特殊重启标志来打破与其他进程间的依赖关系。

下面介绍客户端配置文件和服务器配置文件。

客户端配置文件如下：

    <？xml version＝″1.0″encoding＝″GB2312″？>

    <p  AutoStart＝″true″name＝″容错客户端″localPort＝″10011″ADServerIP＝″127.0.0.1″

ADServerPort″10012″>

    <apps>

        <app name＝″网关″fullPathName＝″C:\ibServer.exe″/>

        <app name＝″Scankeyword″fullPathName＝″D:\程序\tt\Scankeyword.exe″/>

    </apps>

</p>

对于客户端配置文件的说明如下：

    1、<p>标签的name是客户端的名字，必须填写，并且不能重复。

    2、<app>标签的name是进程的名字，必须填写，在同一客户端上不能重复。

    3、ADServerIP＝″127.0.0.1″ADServerPort＝″10012″是容错服务器的ip和端口也

必须填写。

    服务器端配置文件如下：

    <？xml version＝″1.0″encoding＝″GB2312″？>

    <p AutoStart＝″true″localPort＝″10012″>

        <appsByOrder>

            <app order＝″1″name＝″Scankeyword″whichClient＝″容错客户端″afterSencsSendNextIns＝″1″

time＝″15:5:5″WhichWeek＝″7″everydayRestart ″TRUE″specialRestartFlag＝″1″/>

            <app order＝″2″name＝″网关″whichClient＝″容错客户端″afterSencsSendNextIns＝″1″

time＝″15:5:5″WhichWeek＝″7″everydayRestart＝″TRUE″specialRestartFlag＝″0″/>

    </appsByOrder>

</p>

服务器配置文件说明如下：

1、启动顺序从1开始，顺序递增，以保证可定时重起.以无论程序是出错了(跳框、死了)，还是飞了(进程消失，没启动)都会按启动顺序来修复

2、不定时启动服务的方法是，把WhichWeek设为空，everydayRestart设置为假。如：WhichWeek＝″″everydayRestart＝″FALSE″

3、参数time(时:分:秒)WhichWeek星期几(1～7)可以定时在每周几的几点钟重起下列应用，如果cverydayRestart＝″TRUE″则WhichWeek无效.

4、whichClicnt是指程序所在的客户端。specialRestart Flag取值0-只重启自己跟启动序号无关，1-重启自己以及序号在其后面的所有的，2-需要按序号全部从头开始。

5、注意定时启动是所见即所得的，跟启动顺序、延时秒数、和特殊重启标志都无关。

通过上述的客户端配置文件和服务器配置文件的设置，可以将分布式程序(在本申请中以控制中心、网关、录音服务器等应用为例)无序的部署在任意不同的物理机器上，利用该客户端配置文件，客户端就知晓其将要监视哪些进程，服务器端配置文件只是一个表现形式，也可以表现为数据库的表格，或者数据库中存放的策略等。根据分布式进程依赖关系表格，无论如何部署，分布式程序间的依赖关系却是固定的。并且，通过本发明的上述实施方式，可以自动监控分布式程序进程的状态，并当分布式程序进程出错时可以自动执行应对处理，从而节省了大量的人力物力。

如上所述已经描述了本发明的具体实施方式。然而，本发明不局限于上述实施方式的范围。在不脱离本发明精神和范围的情况下可以对上述实施方式做出各种修改和改进。本发明的范围由所附权利要求进行限定。