一种恢复节点事件的方法、装置及系统与流程

本申请涉及通信领域，尤其涉及一种恢复节点事件的方法、装置及系统。
背景技术：
：在业务管理系统中，通常由控制节点检查各个节点的状态以获取某个节点的节点事件，并通知该节点事件给管理节点，由管理节点将该节点事件通知给业务节点处理。其中，该节点事件包括故障(fault)事件、启动恢复(standby)事件和正常(normal)事件。fault事件表示该节点故障，standby事件表示该节点正在启动恢复，normal事件表示该节点可正常提供业务。业务节点处理该节点的fault事件是指业务节点将该节点上运行的业务下线，并将该业务迁移到其他正常节点上，以保证业务不中断；业务节点处理该节点的standby事件是指该节点故障恢复后，业务节点将原来在该节点上运行的部分业务迁移回该节点，以保证各个节点的负载均衡；业务节点处理该节点的normal事件是指业务节点将该节点加入正常节点列表，以标记该节点可正常提供业务。通常，业务管理系统中，管理节点分为一个主管理节点和多个备管理节点，该主管理节点完成上述节点事件的通知和处理；在主管理节点故障后，从多个备管理节点重新选择一个主管理节点，并由该重新选择的主管理节点继续完成节点事件的通知和处理。例如，如果某个管理节点在处理某个节点事件的过程中发生故障，且该管理节点为主管理节点(以下称为旧主管理节点)，那么该管理节点确定需要切换主管理节点，将备管理节点作为新主管理节点，并由该新主管理节点继续完成节点事件的通知和处理。在旧主管理节点发生故障且新主管理节点恢复过程中，可能会使得旧主管理节点未处理完该节点事件，而新主管理节点又无法获知该节点事件，从而导致该节点事件被遗漏的问题。为了解决该问题，通常采用下述方案恢复该节点事件：旧主管理节点为每个业务节点设置一个缓冲队列记录其至少最近3次处理节点事件的情况，并为该缓冲队列中记录的节点事件分别增加描述属性，以及将这些记录了节点事件的缓冲队列存入持久性存储介质中；同时这些缓冲队列还需要在所有业务节点间保持一致。然而，采用上述方法防止节点事件被遗漏时，由于需要为每个业务节点分别设置一个缓冲队列，并为该缓冲队列中记录的节点事件分别增加描述属性，以及将这些记录了节点事件的缓冲队列存入持久性存储介质中，因此在业务节点比较多时，可能会使得存入持久性存储介质的数据量比较大，从而对业务管理系统的性能产生影响，并且由于这些缓冲队列需要在所有业务节点间保持一致，因此使得节点事件的处理机制比较复杂。技术实现要素：本申请提供一种恢复节点事件的方法、装置及系统，能够在防止节点事件被遗漏的情况下，使得节点事件不对业务管理系统的性能产生影响、且简化了节点事件的处理机制。第一方面，本申请提供一种恢复节点事件的方法，该方法可以包括：第一主管理节点获取第一节点的第一状态；并且第一主管理节点获取第一节点的第二状态；以及第一主管理节点根据该第一状态和该第二状态，确定是否恢复第一节点的节点事件。其中，第一状态为第一主管理节点记录的第一节点的状态或者控制节点当前发送的第一节点的状态，第二状态为业务节点记录的第一节点的状态。本申请提供的恢复节点事件的方法，在旧主管理节点发生故障时，第一主管理节点可以作为新的主管理节点代替旧主管理节点处理第一节点的节点事件，第一主管理节点获取该第一主管理节点记录的或者控制节点当前发送的第一节点的状态(例如第一状态)，并且该第一主管理节点获取业务节点记录的第一节点的状态(例如第二状态)，然后第一主管理节点根据其获取的第一节点的第一状态和第一节点的第二状态，确定是否恢复第一节点的节点事件。本发明实施例提供的恢复节点事件的方法，一方面，由于通常情况下，第一主管理节点记录的第一节点的状态(即上述第一状态)为旧主管理节点上一次成功处理节点事件后记录的第一节点的状态，控制节点当前发送的第一节点的状态(即上述第一状态)为当前第一节点的实时状态，业务节点记录的第一节点的状态(例如上述第二状态)为业务节点上一次成功处理完节点事件后记录的第一节点的状态，因此第一主管理节点根据第一主管理节点记录的第一节点的状态和第一主管理节点获取的业务节点记录的第一节点的状态，或者根据控制节点当前发送的第一节点的状态和第一主管理节点获取的业务节点记录的第一节点的状态，能够准确地确定第一主管理节点作为主管理节点之前第一节点的节点事件是否已被成功处理，从而可以准确地确定是否需要恢复第一节点的节点事件，如此可以防止节点事件被遗漏；另一方面，由于本发明实施例提供的恢复节点事件的方法无需保存业务节点最近多次处理的节点事件，因此不但能够避免保存大量数据对业务管理的性能产生的影响，而且能够避免复杂的节点事件的处理机制。如此，本申请提供的恢复节点事件的方法，能够在防止节点事件被遗漏的情况下，使得节点事件不对业务管理系统的性能产生影响、且简化了节点事件的处理机制。在第一方面的第一种可选的实现方式中，在上述第一主管理节点获取第一节点的第一状态之前，本申请提供的恢复节点事件的方法还可以包括：第一主管理节点确定该第一主管理节点作为主管理节点。本申请中，在旧主管理节点发生故障时，业务管理系统中的多个备选管理节点可以参与选择新主管理节点，第一主管理节点即为业务管理系统中的新主管理节点，如此，可以由该第一主管理节点处理控制节点发送新节点事件并确定是否恢复第一节点的节点事件。在第一方面的第二种可选的实现方式中，上述第一节点的第一状态可以为正常状态、启动恢复状态或故障状态，第一节点的第二状态可以为正常状态、启动恢复状态、故障状态或空状态。本申请中，第一主管理节点可以根据其获取的第一节点的第一状态和第一节点的第二状态，并且可以根据第一状态和第二状态的实际情况确定是否恢复第一节点的节点事件(包括恢复fault事件和standby事件)。本申请中，第一主管理节点确定恢复第一节点的节点事件包括恢复第一节点的fault事件和standby事件，下面分别说明第一主管理节点恢复第一节点的fault事件和第一节点的standby事件。在第一方面的第三种可选的实现方式中，当第一主管理节点获取的第一状态为该第一主管理节点记录的第一节点的状态时，第一主管理节点根据第一状态和第二状态，确定是否恢复第一节点的节点事件的方法可以包括：在第一状态为正常状态、启动恢复状态或故障状态，第二状态为故障状态的情况下，第一主管理节点确定恢复第一节点的节点事件。在第一方面的第四种可选的实现方式中，上述第一方面的第三种可选的实现方式中，第一主管理节点确定恢复的第一节点的节点事件为故障事件(即fault事件)。本申请中，若第一节点的fault事件被遗漏，说明业务节点未处理完该fault事件，即业务节点未将第一节点下线，并将该第一节点上的业务迁移到其他正常的任务节点上，则用户的业务在未来可能会继续被分配到该第一节点上，而第一节点已经故障，无法再处理业务，从而导致业务处理失败，影响用户的业务正常运行。本申请提供的恢复节点事件的方法，第一主管理节点可以根据该第一主管理节点记录的第一节点的状态(即第一状态)和业务节点记录的第一节点的状态(即第二状态)是否恢复第一节点的fault事件，可以防止第一节点的fault事件被遗漏，并且第一主管理节点无需保存业务节点最近多次处理的节点事件，能够使得节点事件不对业务管理系统的性能产生影响、且简化了节点事件的处理机制使得节点事件。在第一方面的第五种可选的实现方式中，当第一主管理节点获取的第一状态为控制节点当前发送的第一节点的状态时，第一主管理节点根据第一状态和第二状态，确定是否恢复第一节点的节点事件的方法可以包括：在第一状态为正常状态，第二状态为启动恢复状态、故障状态或空状态的情况下，第一主管理节点确定恢复第一节点的节点事件。在第一方面的第六种可选的实现方式中，上述第一方面的第五种可选的实现方式中，第一主管理节点确定恢复的第一节点的节点事件为启动恢复事件(即standby事件)。本申请中，若第一节点的standby事件被遗漏，说明业务节点未处理完该standby事件，即业务节点未将第一节点上线，并且未将原先由该第一节点处理的业务迁移回该第一节点上，则该第一节点无法启动恢复，也无法处理业务，如此，可能会浪费第一节点的资源，并且可能会导致业务管理系统中各个任务节点的负载不平衡。本申请提供的恢复节点事件的方法，第一主管理节点可以根据该控制节点当前发送的第一节点的状态(即第一状态)和业务节点记录的第一节点的状态(即第二状态)是否恢复第一节点的standby事件，可以防止第一节点的standby事件被遗漏，并且第一主管理节点无需保存业务节点最近多次处理的节点事件，能够使得节点事件不对业务管理系统的性能产生影响、且简化了节点事件的处理机制使得节点事件。第二方面，本申请提供一种管理节点，该管理节点可以包括获取模块和确定模块。其中，获取模块用于获取第一节点的第一状态，并且获取第一节点的第二状态，该第一状态为管理节点记录的第一节点的状态或者控制节点当前发送的第一节点的状态，该第二状态为业务节点记录的第一节点的状态；确定模块用于根据获取模块获取的第一状态和获取模块获取的第二状态，确定是否恢复第一节点的节点事件。在第二方面的第一种可选的实现方式中，上述确定模块还可以用于在获取模块获取第一节点的第一状态之前，确定上述管理节点为主管理节点。在第二方面的第二种可选的实现方式中，第一节点的第一状态为正常状态、启动恢复状态或故障状态，该第二节点的第二状态为正常状态、启动恢复状态、故障状态或空状态。在第二方面的第三种可选的实现方式中，当上述获取模块获取的第一状态为管理节点记录的第一节点的状态时，上述确定模块具体用于在第一状态为正常状态、启动恢复状态或故障状态，第二状态为故障状态的情况下，确定恢复第一节点的节点事件。在第二方面的第四种可选的实现方式中，第二方面的第三种可选的实现方式中，确定模块确定恢复的是第一节点的故障事件(fault事件)。在第二方面的第五种可选的实现方式中，当上述获取模块获取的第一状态为控制节点当前发送的第一节点的状态时，上述确定模块具体用于在第一状态为正常状态，第二状态为启动恢复状态、故障状态或空状态的情况下，确定恢复第一节点的节点事件。在第二方面的第六种可选的实现方式中，上述第二方面的第五种可选的实现方式中，确定模块确定恢复的是第一节点的启动恢复事件(即standby事件)。第二方面及其各种可选的实现方式的技术效果可以参见上述对第一方面及其各种可选的实现方式的技术效果的相关描述，此处不再赘述。第三方面，本申请提供一种管理节点，该管理节点可以包括处理器和与该处理器耦合连接的存储器。该存储器可以用于存储计算机指令。当该管理节点运行时，该处理器执行该存储器存储的该计算机指令，以使得该管理节点执行上述第一方面及其各种可选的实现方式中任意之一所述的恢复节点事件的方法。第四方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质可以包括计算机指令。当该计算机指令在管理节点上运行时，使得该管理节点执行上述第一方面及其各种可选的实现方式中任意之一所述的恢复节点事件的方法。第五方面，本申请提供一种包括计算机指令的计算机程序产品，当该计算机程序产品在管理节点上运行时，使得该管理节点执行上述第一方面及其各种可选的实现方式中任意之一所述的恢复节点事件的方法。第三方面至第五方面的相关内容和技术效果的描述可以参见上述对第一方面及其各种可选的实现方式的相关内容和技术效果的相关描述，此处不再赘述。第六方面，本申请提供一种业务管理系统，该业务管理系统可以包括第一节点，业务节点，控制节点，以及上述第二方面及其各种可选的实现方式中任意之一所述的管理节点，第二方面及其各种可选的实现方式中任意之一所述的管理节点为第一主管理节点。或者，该业务管理系统可以包括第一节点，业务节点，控制节点，以及上述第三方面所述的管理节点，第三方面所述的管理节点为第一主管理节点。第六方面的相关内容和技术效果可以参见上述对第二方面及其各种可选的实现方式的相关内容和技术效果的相关描述，此处不再赘述。附图说明图1为本发明实施例提供的任务节点的状态迁移的示意图；图2为本发明实施例提供的一种业务管理系统的架构示意图；图3为本发明实施例提供的一种服务器的硬件示意图；图4为本发明实施例提供的恢复节点事件的方法示意图一；图5为本发明实施例提供的恢复节点事件的方法示意图二；图6为本发明实施例提供的恢复节点事件的方法示意图三；图7为本发明实施例提供的一种管理节点的结构示意图一；图8为本发明实施例提供的一种管理节点的结构示意图二；图9为本发明实施例提供的一种业务节点的结构示意图一；图10为本发明实施例提供的一种业务节点的结构示意图二。具体实施方式本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。本发明实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一状态和第二状态等是用于区别不同的状态，而不是用于描述状态的特定顺序。在本发明实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本发明实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。在本发明实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个管理节点是指两个或两个以上的管理节点；多个业务是指两个或两个以上的业务节点。下面对本发明实施例提供的恢复节点事件的方法、装置及系统中涉及的一些概念做解释说明。控制节点：在业务管理系统中，控制节点可以监测该业务管理系统中的各个节点(例如业务节点、管理节点和任务节点等)的状态，如此，可以在各个节点的状态异常时做出相应的调整，以保证业务管理系统正常地工作。管理节点：在业务管理系统中，管理节点可以管理业务管理系统中的任务节点，具体包括处理任务节点的节点事件、向业务节点发送任务节点的节点事件等。业务节点：在业务管理系统中，业务节点可以处理任务节点节点事件，具体可以包括将任务节点下线或者上线等。任务节点：在业务管理系统中，任务节点可以处理用户的业务，以保证用户的业务顺利地运行。任务节点的状态：任务节点的状态可以包括故障状态、启动恢复状态和正常状态。本发明实施例中，任务节点的各种状态之间可以迁移变化，示例性的，如图1所示为一个任务节点的状态迁移的示意图，图1中，任务节点的状态迁移包括5种情况(图1中以①-⑤分别示意)，下面对这5中情况做详细的说明。第①种：启动恢复状态迁移到正常状态。本发明实施例中，任务节点从启动恢复状态迁移到正常状态可以理解为该任务节点正常启动，并且启动后恢复为正常状态，该任务节点可以处理业务。第②种：正常状态迁移到启动恢复状态。本发明实施例中，任务节点从正常状态迁移到启动恢复状态可以理解为该任务节点在短时间内重启了，在重启的过程中，该任务节点的状态变为启动恢复状态，该任务节点暂时无法处理业务。第③种：启动恢复状态迁移到故障状态。本发明实施例中，任务节点从启动恢复状态迁移到故障状态可以理解为该任务节点在启动的过程中发生故障，该任务节点的状态变为故障状态，该任务节点无法处理业务。第④种：故障状态迁移到启动恢复状态。本发明实施例中，任务节点从故障状态迁移到启动恢复状态可以理解为该任务节点的故障解除之后，该任务节点重新启动，该任务节点的状态变为启动恢复状态，该第一节点暂时无法处理业务。第⑤种：正常状态迁移到故障状态。本发明实施例中，任务节点从正常状态迁移到故障状态可以理解为该任务节点在正常处理业务的过程中发生故障，该任务节点的状态变为故障状态，该任务节点无法处理业务。需要说明的是，本发明实施例中，一个任务节点的状态不能从故障状态迁移到正常状态，这是因为一个任务节点发生故障之后，在该任务节点恢复正常的过程中，该任务节点必须先重新启动再恢复正常，即该任务节点的状态必须从故障状态先迁移到启动恢复状态，再从启动恢复状态迁移到正常状态。任务节点的节点事件：任务节点的节点事件可以包括fault事件、standby事件和normal事件。本发明实施例中，fault事件表示任务节点处于故障状态(即表示该任务节点无法处理业务)；standby事件表示任务节点处于启动恢复的状态(即表示该任务节点正在启动，启动后可以恢复为正常状态，并在恢复为正常状态后可以处理业务)；normal事件表示任务节点处于正常状态(即表示该任务节点可以处理业务)。基于
背景技术：
提及的恢复节点事件的方法，由于在
背景技术：
中，需要为每个业务节点分别设置一个缓冲队列，并为该缓冲队列中记录的节点事件分别增加描述属性，以及将这些记录了节点事件的缓冲队列存入持久性存储介质中，因此在业务节点比较多时，可能会使得存入持久性存储介质的数据量比较大，从而对业务管理系统的性能产生影响，并且由于这些缓冲队列需要在所有业务节点间保持一致，因此使得节点事件的处理机制比较复杂。为了解决上述问题，本发明实施例提供一种恢复节点事件的方法、装置及系统，业务管理系统中的主管理节点发生故障之后，可以从多个备管理节点中选择一个备管理节点作为新主管理节点，新主管理节点根据该新主管理节点记录的第一节点的状态和该新主管理节点获取的业务节点记录的第一节点的状态，确定是否恢复第一节点的节点事件。本发明实施例提供的恢复节点事件的方法，可以防止节点事件被遗漏，并且能够防止节点事件被遗漏的情况下，使得节点事件不对业务管理系统的性能产生影响、且简化了节点事件的处理机制。本发明实施例提供的恢复节点事件的方法可以应用于业务管理系统中，如图2所示，为本发明实施例提供的一种业务管理系统的架构示意图，在图2中，该业务管理系统包括控制节点10，至少一个管理节点(图2中是以该业务管理系统包括3个管理节点为例示意的，分别记为管理节点11a、管理节点11b和管理节点11c)，至少一个业务节点(图2中是以该业务管理系统包括3个业务节点为例示意的，分别记为业务节点12a、业务节点12b和业务节点12c)，以及至少一个任务节点(图2中是以该业务管理系统包括4个任务节点为例示意的，分别记为任务节点13a、任务节点13b、任务节点13c和任务节点14d)。其中，控制节点分别与至少一个管理节点和至少一个任务节点连接，至少一个业务节点与至少一个管理节点连接(一个业务节点对应一个管理节点)。本发明实施例中，任务节点用于处理用户的各种业务，上述业务管理系统中的控制节点可以检测各个任务节点的状态，并且可以向管理节点发送表示任务节点的状态的节点事件，从而管理节点可以通知业务节点该节点事件，业务节点可以处理该节点事件(例如包括故障事件、正常事件和启动恢复事件)并且更新该业务节点记录的任务节点的状态，然后通知业务管理系统中的所有管理节点该节点事件处理完成，以使得该所有管理节点更新所有管理节点记录的任务节点的状态。需要说明的是，本发明实施例中，上述业务管理系统中的管理节点、业务节点和任务节点的数量可以根据实际使用需求确定，本发明实施例不作具体限定。需要说明的是，本发明实施例中，上述如图2所示的至少一个管理节点中的每一个管理节点可以为同一种结构的设备，也可以为不同结构的设备。同理，上述如图2所示的至少一个业务节点中的每一个业务节点也可以为同一种结构的设备，也可以为不同结构的设备，上述如图2所示的至少一个任务节点也可以为同一种结构的设备，也可以为不同结构的设备。本发明实施例中，假设上述至少一个管理节点中的每一个管理节点为同一种结构的设备，下面介绍本发明实施例提供的管理节点的硬件结构。示例性的，本发明实施例提供的管理节点可以为服务器，以图2所示的管理节点为服务器为例，对本发明实施例提供的管理节点的硬件结构进行示例性的说明。图3为本发明实施例提供的服务器的硬件示意图，如图3所示的服务器可以包括：处理器20、存储器21和通信接口22。处理器20是服务器的核心部件，用于运行服务器的操作系统与服务器上安装的应用程序(包括系统应用程序和第三方应用程序)。本发明实施例中，处理器20具体可以为中央处理器(centralprocessingunit，cpu)，通用处理器，数字信号处理器(digitalsignalprocessor，dsp)，专用集成电路(application-specificintegratedcircuit，asic)，现场可编程门阵列(fieldprogrammablegatearray，fpga)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合，其可以实现或执行本发明实施例公开的内容所描述的各种示例性的逻辑方框，模块和电路；处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等。存储器21用于存储服务器的程序代码和数据。本发明实施例中，存储器31具体可以包括易失性存储器(volatilememory)，例如随机存取存储器(random-accessmemory，ram)；该存储器也可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-onlymemory，rom)，快闪存储器(flashmemory)，硬盘(harddisk，hdd)或固态硬盘(solid-statedisk，ssd)；该存储器还可以包括上述种类的存储器的组合。通信接口22用于服务器与其他设备进行通信的接口电路，通信接口可以为收发器、收发电路等具有收发功能的结构，通信接口包括串行通信接口和并行通信接口。本发明实施例中，上述如图2所示的控制节点、至少一个业务节点和至少一个任务节点均可以为服务器，且可以为与上述如图3所示的服务器的结构相同的服务器，或者可以为包括如图3所示的服务器的所有组件以及其他组件的服务器。假设控制节点、至少一个业务节点和至少一个任务节点均为与如图3所示的服务器的结构相同的服务器，对于本发明实施例提供的控制节点、业务节点和任务节点的各个组件的具体描述可以参见对图3所示的服务器的各个组件的相关描述，此处不再赘述。本发明实施例提供的恢复节点事件的方法可以应用于业务管理系统中的主管理节点发生故障的场景中。具体的，在业务管理系统处理一个节点(例如第一节点)的节点事件的过程中，该业务管理系统中的主管理节点发生故障，在这种情况下，可以重新选择一个管理节点作为新主管理节点(以下均称为第一主管理节点)，并由第一主管理节点确定是否恢复原来的主管理节点(以下均称为旧主管理节点)发生故障时，业务管理系统中可能遗漏的节点事件。为了清楚地描述本发明实施例提供的恢复节点事件的方法，在下述实施例中，以业务管理系统连续两次处理节点事件为例介绍恢复节点事件的方法，其中，将旧主管理节点发生故障前，业务管理系统正在处理的第一节点的节点事件称为第一节点的第一节点事件，将旧主管理节点发生故障后，业务管理管理系统中控制节点当前发送的待处理的第一节点的新的节点事件称为第一节点的第二节点事件，在第一主管理节点代替旧主管理节点处理之后，第一主管理节点可以确定是否恢复第一节点事件。下面对本发明实施例提供的恢复节点事件的方法做详细地说明。本发明实施例提供一种恢复节点事件的方法，如图4所示，该方法可以包括：s101、控制节点获取第一节点的状态。本发明实施例中，业务管理系统中的控制节点可以监测该业务管理系统中的各个节点(例如任务节点、管理节点和业务节点等)的状态，如此，可以在各个节点的状态异常时做出相应的调整(例如切换节点等)，以保证业务管理系统正常地工作。示例性的，本发明实施例中，如果业务管理系统中的某一个任务节点(例如上述第一节点)发生故障或者重启时，那么该第一节点暂时不能再处理业务，待该第一节点恢复正常时才可以继续处理业务。假设业务管理系统中的第一节点发生故障，该第一节点不能继续再处理业务，从而可能会导致下一次到达该第一节点的业务均不能被成功的处理。为了保证用户的业务顺利地被处理，业务管理系统中的控制节点可以将其检测到的第一节点的状态(即故障状态)，从而业务管理系统可以根据控制节点获取的第一节点的状态对该业务管理系统中的各个节点做相应的调整。可选的，本发明实施例中，控制节点可以周期性地检测第一节点的状态，以使得业务管理系统及时地根据第一节点的状态变化对该业务管理系统中的各个节点做相应的调整，从而保证业务管理系统能够正常地工作。需要说明的是，对于第一节点的状态的具体描述，可以参见上述实施例中对于第一节点的状态的相关描述，此处不再赘述。s102、控制节点根据第一节点的状态，向所有管理节点发送第一节点的第一节点事件。本发明实施例中，一个任务节点的状态与该任务节点的节点事件的类型具有一一对应的关系，即任务节点的故障状态、启动恢复状态和正常状态与该任务节点的fault事件、standby事件和normal事件)具有一一对应的关系。如表1所示，为本发明实施例中一个任务节点的状态与该任务节点的节点事件的类型之间的对应关系的示例。表1任务节点的状态任务节点的节点事件的类型故障状态fault事件启动恢复状态standby事件正常状态normal事件本发明实施例中，控制节点检测到第一节点的状态之后，控制节点可以根据第一节点的状态确定第一节点的第一节点事件的类型，即确定第一节点的第一事件是哪一种节点事件(节点事件包括fault事件、standby事件和normal事件)。示例性的，结合上述表1，若控制节点检测到第一节点的状态为故障状态，则控制节点向管理节点发送与该故障状态对应的fault事件；若控制节点检测到第一节点的状态为启动恢复状态，控制节点向管理节点发送与该启动恢复状态对应的standby事件；若控制节点检测到第一节点的状态为正常状态，控制节点向管理节点发送与该正常状态对应的normal事件。可选的，本发明实施例中，上述控制节点将第一节点的第一节点事件发送给业务管理系统中的所有管理节点(通常，业务管理系统中有多个管理节点，其中，包括一个主管理节点和多个备管理节点)时，控制节点可以依次向各个管理节点发送第一节点的第一节点事件，该控制节点还可以同时向各个管理节点发送第一节点的第一节点事件，本发明实施例不作具体限定。s103、所有管理节点接收控制节点发送的第一节点的第一节点事件。本发明实施例中，所有管理节点接收到控制节点发送的第一节点的第一节点事件之后，如果业务管理系统中的主管理节点处于正常状态，那么可以继续执行下述s104-s108：需要说明的是，本发明实施例中，下述实施例提及的主管理节点均指的旧主管理节点。s104、主管理节点将第一节点的第一节点事件发送给业务节点。本发明实施例中，业务管理系统中的所有管理节点(包括主管理节点和备管理节点)接收控制节点发送的第一节点的第一节点事件之后，由负责管理第一节点的节点事件的主管理节点(主管理节点)将该第一节点事件发送给业务节点。s105、业务节点接收主管理节点发送的第一节点的第一节点事件。s106、业务节点处理第一节点的第一节点事件。本发明实施例中，业务节点可以处理任务节点的节点事件，从而可以调整业务管理系统中的各个任务节点的工作模式(例如将某一个任务节点下线或者上线等)，以保证业务管理系统顺利地处理用户的业务。本发明实施例中，上述业务节点接收主管理节点发送的第一节点的第一节点事件之后，业务节点可以处理该第一节点事件，业务节点处理第一节点的第一节点事件包括：处理第一节点的fault事件，处理第一节点的standby事件，以及处理第一节点的normal事件。具体的，业务节点处理第一节点的fault事件具体可以包括业务节点将该第一节点下线，并将该第一节点上的业务迁移到其他处于正常状态的任务节点上，如此可以保证业务处理不被中断；业务节点处理第一节点的standby事件具体可以包括业务节点将原来在该节点上运行的部分业务迁移回该第一节点，待该第一节点恢复正常状态后，该第一节点可以处理已迁移回到该第一节点的业务，如此可以保证各个任务节点之间的负载平衡；业务节点处理第一节点的normal事件具体可以包括业务节点将该第一节点加入到正常节点的列表中，如此可以标记出该第一节点可以正常处理业务，以使得该下一次到达该第一节点的业务可以被该第一节点成功地处理。s107、业务节点更新该业务节点记录的第一节点的状态。本发明实施例中，业务节点处理完某一个任务节点的节点事件之后，业务节点可以将该业务节点当前处理的该任务节点的节点事件对应的该任务节点的状态记录在该业务节点中，在业务节点处理完该任务节点的下一次节点事件之后，该业务节点可以用与该业务节点处理的下一次节点事件的类型所对应的该任务节点的状态替换该业务节点当前记录的该任务节点的状态，即业务节点可以更新该业务节点记录的任务节点的状态。本发明实施例中，业务节点更新该业务节点记录的第一节点的状态，如此，可以根据业务节点记录的第一节点的状态获知该业务节点上一次处理的第一节点的节点事件对应的第一节点的状态，或者可以获知该业务节点上一次处理的第一节点的节点事件的类型。s108、业务节点向主管理节点发送用于指示第一节点的第一节点事件处理完成的第一通知消息。本发明实施例中，业务节点处理完第一节点的第一节点事件之后，该业务节点可以向主管理节点发送用于指示第一节点的第一节点事件处理完成的第一通知消息，如此，主管理节点可以根据该第一通知消息获知业务节点已经完成了第一节点的第一节点事件的处理。需要说明的是，本发明实施例可以不限定s107与s108的执行顺序。即本发明实施例可以先执行s107，后执行s108；也可以先执行s108，后执行s107；还可以同时执行s107和s108。s109、主管理节点接收业务节点发送的第一通知消息。s110、主管理节点根据其接收的第一通知消息中的第一节点的状态信息，更新该主管理节点记录的第一节点的状态。其中，上述业务节点发送给主管理节点的第一通知消息中携带有第一节点的状态信息，该第一节点的状态信息可以指示第一节点的状态。本发明实施例中，主管理节点接收到业务节点发送的通知消息之后，该主管理节点可以将该第一通知消息中第一节点的状态信息指示的第一节点的状态记录在该主管理节点中，在主管理节点接收到业务节点发送的用于指示处理完成第一节点的下一次节点事件的第一通知消息时，主管理节点可以用其接收的第一通知消息中第一节点的状态信息所指示的第一节点的状态替换该主管理节点当前记录的第一节点的状态，即主管理节点可以更新该主管理节点记录的第一节点的状态。可选的，本发明实施例中，主管理节点更新完该主管理节点中记录的第一节点状态之后，该主管理节点还可以通知其他备管理节点第一节点的状态，以使得其他备管理节点更新各自记录的第一节点的状态。综上可知，本发明实施例中，业务管理系统中的所有管理节点可以更新该所有管理节点中记录的第一节点的状态，如此，所有管理节点接收到第一节点的下一次节点事件时，该所有管理节点可以获知该所有管理节点接收的第一节点的上一次节点事件对应的第一节点的状态，或者可以获知该所有管理节点接收的第一节点的上一次节点事件的类型。本发明实施例中，主管理节点根据其接收的通知消息中的第一节点的状态信息，更新该主管理节点记录的第一节点的状态，至此，表明业务管理系统成功地完成了第一节点的第一节点事件的处理，从而可以根据对该第一节点的第一节点事件的处理结果重新将用户的业务分配到不同的任务节点上(例如，将第一节点下线的情况下，将原本需要在第一节点上处理的业务迁移到其他正常的任务节点上)，如此，能够保证业务管理系统正常地工作。可选的，本发明实施例中，结合图4，在上述s104之前，本发明实施例提供的恢复节点事件的方法还可以包括s104a：s104a、主管理节点对第一节点的第一节点事件做预处理。本发明实施例中，上述主管理节点对其接收到的第一节点的第一节点事件做预处理可以包括主管理节点对该主管理节点上的节点事件(该主管理节点上可能有多个节点事件)排序或者做一些其他的准备工作。(例如，合并节点事件或者删除节点事件，合并节点事件指的是可以将某一个节点的连续几次相同的节点事件合并，处理一次该节点事件即可；删除节点事件指的是假如主管理节点接收到某一个节点的fault事件时，该主管理节点的缓存队列中有还未处理的该节点的normal事件或standby事件，那么该主管理节点删除normal事件或standby事件，处理fault事件即可)等。示例性的，主管理节点接收第一节点的第一节点事件之后，主管理节点可以对该第一节点的第一节点事件和该主管理节点接收的其他任务节点的节点事件排序，从而业务节点可以根据主管理节点对节点事件的排列顺序处理节点事件。具体的，可以根据各个节点事件的处理优先级，对各个节点事件排序，假设业务管理系统中主管理节点可以管理5个任务节点(这5个任务节点可以分别记为第一节点、第二节点、第三节点、第四节点和第五节点)，主管理节点接收到的这5个任务节点的5个节点事件(这5个节点事件可以分别记为节点事件1、节点事件2、节点事件3、节点事件4和节点事件5)，主管理节点可以按照这5个节点事件的处理优先级对这5个节点事件进行排序，假设第一节点的节点事件1的优先级最高(即业务节点可以优先处理节点事件1)，则主管理节点可以将节点事件1排在第一位，可以使得业务节点首先处理该节点事件1，如表2所示，为上述节点事件与节点事件的优先级之间的对应关系的示例。表2节点事件节点事件的优先级节点事件11节点事件22节点事件33节点事件44节点事件55可选的，本发明实施例中，节点事件的优先级可以用一个数值表示，如表2所示，该优先级的数值越小表示节点事件的优先级越高，当然，在实际应用中，还可能存在优先级的数值越大，优先级越高的实现方式，具体可以根据实际使用需求确定，本发明实施例不作限定。本发明实施例中，在上述业务管理系统处理第一节点的第一节点事件的过程中，如果业务管理系统中的主管理节点发生故障，那么该主管理节点无法再继续处理第一节点的节点事件，而且业务管理系统在执行上述s104-s110中的某一个步骤时，主管理节点发生故障，那么该第一节点的第一节点事件可能未处理完，如此，可能导致该第一节点事件被遗漏，而第一节点的节点事件(例如)被遗漏可能会导致业务管理系统无法正常工作。本发明实施例中，在主管理节点发生故障时，可以从多个备管理节点中选择一个备管理节点作为新主管理节点，然后由这个新主管理节点代替之前的主管理节点(即旧主管理节点)完成第一节点后续的节点事件的接收、处理和发送等，如此可以保证业务管理系统正常地工作，并且新主管理节点可以确定是否恢复可能被遗漏的节点事件。结合图4，如图5所示，在执行上述s104-s110中的任意一个步骤时，主管理节点发生故障，可以执行下述s111-s114:s111、多个备管理节点参与选择第一主管理节点。可选的，本发明实施例中，当业务管理系统中的主管理节点发生故障时，可以采用下述a1-a3三种方法中的任意一种方法从多个备管理节点中选择一个备管理节点作为新主管理节点(即第一主管理节点)，下述实施例中第一主管理节点均表示新主管理节点。a1、将多个备管理节点中优先级最高的一个备管理节点作为第一主管理节点。本发明实施例中，可以为多个备管理节点设置优先级，当主管理节点发生故障时，在重新选择主管理节点的过程中，可以将多个备管理节点中优先级最高的一个备管理节点作为第一主管理节点。需要说明的是，本发明实施例中，多个备管理节点的优先级可以与上述节点事件的优先级类似，对于多个备管理节点的优先级的描述可以参见上述对节点事件的优先级的相关描述，此处不再赘述。a2、采用投票选举的方法，将多个备管理节点中得票票数最多个一个备管理节点作为第一主管理节点。本发明实施例中，当主管理节点发生故障时，在重新选择主管理节点的过程中，多个备管理节点之间可以互相投票，并且统计各个备管理节点的得票票数，将多个备管理节点中投票票数最多的一个管理节点作为第一主管理节点。示例性的，假设业务管理系统中有5个管理节点(分别记为第一管理节点、第二管理节点、第三管理节点、第四管理节点和第五管理节点)，其中，第一管理节点为主管理节点，其余的4个管理节点(即第二管理节点、第三管理节点、第四管理节点和第五管理节点)为备管理节点，从4个备管理节点中选择新主管理节点时，假设这4个备管理节点中的每一个备管理节点有1次投票的机会可以向这个4个管理节点投票(包括该备管理节点，即该备管理节点也可以给该备管理节点自身投票，例如第二管理节点可以给该第二管理节点本身投票)，该4个备管理节点之间投票结束后，如果投票结果如表3所示，那么由表3可以看出，第三管理节点得票票数最多，因此将第三管理节点作为第一主管理节点。表3管理节点得票票数第二管理节点0第三管理节点2第四管理节点1第五管理节点1a3、通过随机选择，将多个备管理节点中的任意一个备管理节点作为第一主管理节点。本发明实施例中，当主管理节点发生故障时，在重新选择主管理节点的过程中，可以将多个备管理节点中的任意一个管理节点作为第一主管理节点。需要说明的是，本发明实施例中，在上述a2的方法中，如果多个备管理节点中得票票数最多的管理节点有至少两个(即有至少两个备管理节点的得票票数相同，且票数最多)时，可以采用a3的方法，从得票票数最多的至少两个备管理节点中任意选择一个备管理作为第一主管理节点。示例性的，若上述表3中的4个管理节点的得票票数均相同时，即均得到1票，则从这4个管理节点中任意选择一个管理节点作为第一主管理节点，例如可以选择第二管理节点作为第一主管理节点；若第三管理节点与第五管理节点均得到2票，第二管理节点与第四管理节点均得到0票，则可以选择第三管理节点或者第五管理节点作为第一主管理节点，例如，可以选择第五管理节点作为第一主管理节点。上述两种假设的4个管理节点投票的结果仅为示例性的列举，事实上，还可以包括其他投票结果，本发明实施例不再一一列举。s112、第一备管理节点确定该第一备管理节点为第一主管理节点。本发明实施例中，通过上述a1、a2或a3三种方法中任意一种方法，若第一备管理节点的优先级最高，则第一备管理节点确定该第一备管理节点为第一主管理节点；或者，若第一备管理节点的得票票数最多，则第一备管理节点确定该第一备管理节点为第一主管理节点；又或者，若随机选择的管理节点为第一备管理节点，则第一备管理节点确定该第一备管理节点为第一主管理节点。s113、第一备管理节点向控制节点发送用于指示第一备管理节点为第一主管理节点第二通知消息。s114、控制节点接收第一备管理节点发送的第二通知消息。本发明实施例中，上述从多个备管理节点中选择出新主管理节点之后，该新主管理节点(即第一主管理节点)可以向控制节点发送第二通知消息，该第二通知消息中包括第一主管理节点的信息(即包括第一备管理节点的信息)，如此，控制节点可以根据该第二通知消息获知业务管理系统中的主管理节点发生故障，并且该业务管理系统中的第一备管理节点作为第一主管理节点代替主管理节点完成后续的新节点事件的处理。本发明实施例中，在业务管理系统中的主管理节点(即上述的旧主管理节点)发生故障，并且在还未选择出新主管理节点(即上述的第一主管理节点)的阶段，可能会存在旧主管理节点接收的节点事件未处理完，而新主管理节点又无法获知该节点事件是否被处理完的情况，从而可能会导致该节点事件被遗漏，而节点事件被遗漏可能会导致业务管理系统无法正常工作。示例性的，若fault事件(例如第一节点的fault事件)被遗漏，说明业务节点未处理完该fault事件，即业务节点未将第一节点下线，并将该第一节点上的业务迁移到其他正常的任务节点上，则用户的业务在未来可能会继续被分配到该第一节点上，而第一节点已经故障，无法再处理业务，从而导致业务处理失败，影响用户的业务正常运行。若standby事件(例如第一节点的standby事件)被遗漏，说明业务节点未处理完该standby事件，即业务节点未将第一节点上线，并且未将原先由该第一节点处理的业务迁移回该第一节点上，则该第一节点无法启动恢复，也无法处理业务，如此，可能会浪费第一节点的资源，并且可能会导致业务管理系统中各个任务节点的负载不平衡。若normal事件(例如第一节点的normal事件)被遗漏，由于业务节点处理normal事件不涉及第一节点的下线或上线，也不涉及业务的迁移，因此当normal事件被遗漏时不会影响任务节点处理业务，即不会影响业务管理系统正常工作。综上可知，由于业务管理系统中的fault事件和standby事件被遗漏时可能会对业务管理系统造成不利的影响，因此在业务管理系统中防止节点事件(特别是fault事件和standby事件)被遗漏是非常重要的。本发明实施例中，主管理节点发生故障之后，业务管理系统处理第一节点的第二节点事件(即在上述第一节点的第一节点事件之后，第一节点的下一次节点事件)，并且在处理该第一节点的第二节点事件的过程中，确定是否恢复第一节点的第一节点事件(即上述的主管理节点发生故障时，业务管理系统中正在处理的节点事件)，如图6所示，在确定出新主管理节点之后，本发明实施例提供的恢复节点事件的方法可以包括：s201、控制节点获取第一节点的状态。s202、控制节点根据第一节点的状态，向所有管理节点发送第一节点的第二节点事件。其中，第一节点的第二节点事件中携带有第一主管理节点的信息。本发明实施例中，在旧主管理节点发生故障，并确定出新主管理节点之后，控制节点向所有管理节点发送第一节点的第二节点事件时，控制节点可以将其接收的第二通知消息中第一主管理节点的信息携带在该第二节点事件中发送给所有管理节点，从而所有管理节点可以获知，业务管理系统中的新主管理节点是哪一个管理节点。需要说明的是，本发明实施例中，第一节点的状态与第一节点的节点事件的类型具有一一对应的关系，对于根据第一节点的状态确定第一节点的第二节点事件的类型的方法，可以参见上述s102中对于根据第一节点的状态确定第一节点的第一节点事件之间的类型的相关描述，此处不再赘述。s203、所有管理节点接收控制节点发送的第一节点的第二节点事件。需要说明的是，本发明实施例中，对于上述s201-s203的其他描述具体可以参见上述s101-s103的相关描述，此处不再赘述。s204、旧主管理节点根据第一节点的第二节点事件中携带的第一主管理节点的信息确定切换主管理节点。其中，旧主管理节点为上述s101-s110中所述的主管理节点。本发明实施例中，旧主管理节点接收到控制节点发送第一节点的第二节点事件时，若该第二节点事件中携带的第一主管理节点的信息与该旧主管理节点的信息不同时，旧主管理节点可以确定需要切换主管理节点，从而第一主管理节点将其工作状态调整为主管理节点的工作状态，该旧主管理节点将其工作状态调整为备管理节点的工作状态，待该旧主管理节点恢复正常后，该旧主管理节点可以作为备管理节点参与重新选择主管理节点。s205、第一主管理节点获取第一节点的第一状态。其中，第一状态为第一主管理节点记录的第一节点的状态或者为控制节点当前发送的第一节点的状态。本发明实施例中，第一主管理节点可以获取第一节点的第一状态，具体的，第一主管理节点获取第一节点的第一状态可以包括：第一主管理节点获取第一主管理节点记录的第一节点的状态，该第一主管理节点记录的第一节点的状态是业务管理系统中上一次成功处理第一节点的节点事件后(即业务节点处理完第一节点的节点事件，并且旧主管理节点接收到业务节点发送的用于指示处理完成第一节点的节点事件的通知消息之后，业务管理系统中的所有管理节点完成第一节点的状态的更新后)，该第一主管理节点记录的；或者第一主管理节点获取第一节点的第一状态可以包括：第一主管理节点获取控制节点当前发送的第一节点的状态，控制节点当前发送的第一节点的状态为控制节点当前获取的第一节点的状态，也就是当前第一节点的实时状态。需要说明的是，本发明实施例中，上述业务管理系统中上一次成功处理的第一节点的节点事件可能是上述第一节点的第一节点事件，也可能是第一节点的第一节点事件之前的一个节点事件。具体的，如果在旧主管理节点发生故障时，业务管理系统正好已经处理完第一节点的第一节点事件，那么业务管理系统中上一次成功处理的第一节点的节点事件为第一节点的第一节点事件；如果在旧主管理节点发生故障时，业务管理系统还未处理完第一节点的第一节点事件，那么业务管理系统中上一次成功处理的第一节点的节点事件为第一节点的第一节点事件之前的一个节点事件。s206、第一主管理节点获取第一节点的第二状态。本发明实施例中，第一主管理节点获取第一节点的第二状态具体可以为第一主管理节点从业务节点处获取业务节点记录的第一节点的状态，该第二状态为业务节点上一次成功处理完第一节点的节点事件后记录的。需要说明的是，本发明实施例中，上述业务节点上一次成功处理的第一节点的节点事件可能是上述第一节点的第一节点事件，也可能是第一节点的第一节点事件之前的一个节点事件。具体的，如果在旧主管理节点发生故障时，业务节点正好已经处理完第一节点的第一节点事件，并且更新了该业务节点记录的第一节点的状态，那么业务节点上一次成功处理的第一节点的节点事件为第一节点的第一节点事件；如果在旧主管理节点发生故障时，业务节点还未处理完第一节点的第一节点事件，或者业务节点处理完了第一节点的第一节点事件，但是业务节点还未更新该业务节点记录的第一节点的状态，那么业务节点上一次成功处理的第一节点的节点事件为第一节点的第一节点事件之前的一个节点事件。s207、第一主管理节点根据第一状态和第二状态，确定是否恢复第一节点的第一节点事件。本发明实施例中，在主管理节点发生故障的情况下，如果第一节点的fault事件和第一节点的standby事件被遗漏，可能会给业务管理系统造成不利的影响，因此在第一主管理节点代替旧主管理节点之后，第一主管理节点可以确定是否恢复第一节点的第一节点事件，该第一主管理节点确定是否恢复第一节点的第一节点事件包括第一主管理节点确定是否恢复第一节点的fault事件和第一主管理节点确定是否恢复第一节点的standby事件。本发明实施例提供的恢复节点事件的方法，在旧主管理节点发生故障时，第一主管理节点可以作为新的主管理节点代替旧主管理节点处理第一节点的节点事件，第一主管理节点获取该第一主管理节点记录的或者控制节点当前发送的第一节点的状态(例如第一状态)，并且该第一主管理节点获取业务节点记录的第一节点的状态(例如第二状态)，然后第一主管理节点根据其获取的第一节点的第一状态和第一节点的第二状态，确定是否恢复第一节点的节点事件。本发明实施例提供的恢复节点事件的方法，一方面，由于通常情况下，第一主管理节点记录的第一节点的状态(即上述第一状态)为旧主管理节点上一次成功处理节点事件后记录的第一节点的状态，控制节点当前发送的第一节点的状态(即上述第一状态)为当前第一节点的实时状态，业务节点记录的第一节点的状态(例如上述第二状态)为业务节点上一次成功处理完节点事件后记录的第一节点的状态，因此第一主管理节点根据第一主管理节点记录的第一节点的状态和第一主管理节点获取的业务节点记录的第一节点的状态，或者根据控制节点当前发送的第一节点的状态和第一主管理节点获取的业务节点记录的第一节点的状态，能够准确地确定第一主管理节点作为主管理节点之前第一节点的节点事件是否已被成功处理，从而可以准确地确定是否需要恢复第一节点的节点事件，如此可以防止节点事件被遗漏；另一方面，由于本发明实施例提供的恢复节点事件的方法无需保存业务节点最近多次处理的节点事件，因此不但能够避免保存大量数据对业务管理的性能产生的影响，而且能够避免复杂的节点事件的处理机制。如此，本申请提供的恢复节点事件的方法，能够在防止节点事件被遗漏的情况下，使得节点事件不对业务管理系统的性能产生影响、且简化了节点事件的处理机制。结合图6，本发明实施例中，上述s206具体可以通过s206a-s206d实现：s206a、第一主管理节点向业务节点发送用于请求该业务节点中记录的第一节点的状态的请求消息。s206b、业务节点接收第一主管理节点发送的请求消息。s206c、业务节点向第一主管理节点发送包括第一节点的状态的响应消息。s206d、第一主管理节点接收业务节点发送的响应消息。本发明实施例中，通过上述s206a-s206d，第一主管理节点接收到业务节点发送的上述请求消息的响应消息之后，第一主管理节点可以从该响应消息中获取第一节点的状态(即第一节点的第二状态)。下述实施例将分别详细地介绍恢复第一节点的fault事件和第一节点的standby事件的方法。本发明实施例中，恢复节点事件可以包括恢复fault事件和standby事件，上述s207可以包括s2071和s2072：s2071、第一主管理节点根据第一主管理节点记录的第一节点的状态和第二状态，确定是否恢复第一节点的fault事件。本发明实施例中，上述第一状态为第一主管理节点记录的第一节点的状态时，第一主管理节点可以根据该第一状态和上述第一主管理节点获取的第一节点的第二状态确定是否恢复第一节点的fault事件。本发明实施例中，在下述s2071a的情况下，第一主管理节点确定恢复fault事件：s2071a、在第一节点的第一状态为正常状态、启动恢复状态或故障状态，第一节点的第二状态为故障状态的情况下，第一主管理节点确定恢复fault事件。本发明实施例中，上述第一主管理节点获取的第一节点的第一状态可以为正常状态、启动恢复状态或故障状态，第一主管理节点获取的第一节点的第二状态可以为正常状态、启动恢复状态或故障状态。结合如下所示的表4，以表4中的9种情况对上述根据第一节点的第一状态和第一节点的第二状态确定是否恢复fault事件进行说明。表4第一状态第二状态判断结果第1种正常状态故障状态y第2种启动恢复状态故障状态y第3种故障状态故障状态y第4种正常状态启动恢复状态n第5种启动恢复状态启动恢复状态n第6种故障状态启动恢复状态n第7种正常状态正常状态n第8种启动恢复状态正常状态n第9种故障状态正常状态不存在这种情况第1种：第一节点的第一状态为正常状态，第一节点的第二状态为故障状态时，第一主管理节点确定要恢复fault事件。本发明实施例中，第一状态为正常状态，第二状态为故障状态，可以说明业务管理系统上一次成功处理的节点事件为normal事件，在旧主管理节点发生故障时，业务节点处理的是fault事件，并且业务节点已经将该fault事件处理完，但业务节点还未向第一主管理节点发送通知消息，表明业务管理系统未完成该fault事件的处理，在这种情况下，第一主管理节点确定要恢复fault事件。第2种：第一节点的第一状态为启动恢复状态，第一节点的第二状态为故障状态时，第一主管理节点确定要恢复fault事件。本发明实施例中，第一状态为启动恢复状态，第二状态为故障状态，可以说明业务管理系统上一次成功处理的节点事件为standby事件，在旧主管理节点发生故障时，业务节点处理的是fault事件，并且业务节点已经将该fault事件处理完，但该业务节点还未向第一主管理节点发送通知消息，表明业务管理系统未完成该fault事件的处理，在这种情况下，第一主管理节点确定要恢复fault事件。第3种：第一节点的第一状态为故障状态，第一节点的第二状态为故障状态时，第一主管理节点确定要恢复fault事件。本发明实施例中，第一状态为故障状态，第二状态为故障状态，可以说明在旧主管理节点发生故障时，业务节点已经将该fault事件处理完，并且第一主管理节点接收到业务节点发送的通知消息并根据该通知消息更新了第一主管理节点中记录的第一节点的状态，表明业务管理系统未完成该fault事件的处理，在这种情况下，第一主管理节点确定要恢复fault事件。需要说明的是，本发明实施例中，第一主管理节点从业务节点处获取该业务节点中记录的第一节点的状态(即第一节点的第二状态)的过程中，若第一主管理节点在预设时间段内未收到第一主管理节点发送的响应消息(即第一主管理节点获取业务节点中记录的第一节点的状态失败)，则第一主管理节点将默认该第一节点的第二状态为故障状态，可以看出，上述第1种至第3种情况也包含了第一主管理节点获取第一节点的第二状态失败情况，在第一主管理节点获取第一节点的第二状态失败时，第一主管理节点无法确定业务管理系统上一次处理的节点事件是否被处理完成，为了保证fault事件不被遗漏，第一主管理节点确定要恢复fault事件。第4种：第一节点的第一状态为正常状态，第一节点的第二状态为启动恢复状态时，第一主管理节点确定无需恢复fault事件。本发明实施例中，第一状态为正常状态，第二状态为启动恢复状态，可以说明业务管理系统上一次成功处理的节点事件为normal事件，并且第一节点在短时间内重新启动了(表示业务管理系统要处理standby事件)，在旧主管理节点发生故障时，业务节点已经将该standby事件处理完，但业务节点还未向第一主管理节点发送通知消息，表明在旧主管理节点发生故障时，业务管理系统中并不存在fault事件，在这种情况下，第一主管理节点确定无需恢复fault事件。第5种：第一节点的第一状态为启动恢复状态，第一节点的第二状态为启动恢复状态时，第一主管理节点确定无需恢复fault事件。本发明实施例中，第一状态为启动恢复状态，第二状态为启动恢复状态，可以说明在旧主管理节点发生故障时，业务节点已经将standby事件处理完，并且第一主管理节点接收到业务节点发送的通知消息并根据该通知消息更新了第一主管理节点中记录的第一节点的状态，表明在第一主管理节点故障时，业务管理系统中并不存在fault事件，在这种情况下，第一主管理节点确定无需恢复fault事件。第6种：第一节点的第一状态为故障状态，第一节点的第二状态为启动恢复状态时，第一主管理节点确定无需恢复fault事件。本发明实施例中，第一状态为故障状态，第二状态为启动恢复状态，可以说明业务管理系统上一次成功处理的节点事件为fault事件，并且第一节点的故障已解除(表示业务管理系统要处理standby事件)，在旧主管理节点发生故障时，业务节点已经将该standby事件处理完，但业务节点还未向第一主管理节点发送的通知消息，表明在第一主管理节点故障时，业务管理系统中并不存在fault事件，在这种情况下，第一主管理节点确定无需恢复fault事件。第7种：第一节点的第一状态为正常状态，第一节点的第二状态为正常状态时，第一主管理节点确定无需恢复fault事件。本发明实施例中，第一状态为正常状态，第二状态为正常状态，可以说明在旧主管理节点发生故障时，业务节点已经将normal事件处理完，并且第一主管理节点接收到业务节点发送的通知消息并根据该通知消息更新了第一主管理节点中记录的第一节点的状态，表明在第一主管理节点故障时，业务管理系统中并不存在fault事件，在这种情况下，第一主管理节点确定无需恢复fault事件。第8种：第一节点的第一状态为启动恢复状态，第一节点的第二状态为正常状态时，第一主管理节点确定无需恢复fault事件。本发明实施例中，第一状态为启动恢复状态，第二状态为正常状态，可以说明业务管理系统上一次成功处理的节点事件为standby事件，并且第一节点在启动中，且恢复为正常状态(标识业务管理系统要处理normal事件)，在旧主管理节点故障时，业务节点已经将该normal事件处理完，但业务节点还未向第一主管理节点发送通知消息，表明在第一主管理节点故障时，业务管理系统中并不存在fault事件，在这种情况下，第一主管理节点确定无需恢复fault事件。第9种：第一节点的第一状态为故障状态，第一节点的第二状态为正常状态。本发明实施例中，第一节点的第一状态为故障状态，第一节点的第二状态为正常状态，可以说明旧主管理节点上一次成功处理的事件是fault事件，而第一节点的第二状态为正常状态，可见，第一节点从故障状态变为正常状态，但实际上，由于在第一节点由故障状态恢复到正常状态的过程中，必须由故障状态先变为启动恢复状态，再由启动恢复状态变为正常状态，不可能直接由故障状态变为启动恢复状态(上述实施例已经论述过)，因此，第一节点的第一状态为故障状态，且第一节点的第二状态为正常状态的情况是不存在的，即并不涉及恢复fault事件。综合上述9种情况的分析可以得到上述s2071a结论：即在第一节点的第一状态为正常状态、启动恢复状态或故障状态，第一节点的第二状态为故障状态的情况下，第一主管理节点确定恢复fault事件。在第一主管理节点确定是否恢复第一节点的fault事件时，可以根据第一节点的第一状态和第一节点的第二状态确定是否恢复第一节点的fault事件。s2072、第一主管理节点根据控制节点当前发送的第一节点的状态和第二状态，确定是否恢复第一节点的standby事件。本发明实施例中，上述第一状态为控制节点发送给第一主管理节点的第一节点的状态时，第一主管理节点可以根据该第一状态和上述第一主管理节点获取的第一节点的第二状态确定是否恢复第一节点的standby事件。本发明实施例中，在下述s2072a的情况下，第一主管理节点确定恢复standby事件：s2072a、在第一节点的第一状态为正常状态，第一节点的第二状态为启动恢复状态、故障状态或空状态的情况下，第一主管理节点确定恢复standby事件。需要说明的是，本发明实施例中，第一主管理节点获取的业务节点记录的第一节点的状态还可以包括空状态，第一节点的状态为空状态表示该第一节点为新加入到业务管理系统中的一个任务节点，业务节点还未记录该第一节点的状态。本发明实施例中，上述第一主管理节点获取的第一节点的第一状态可以为正常状态、启动恢复状态或故障状态，第一主管理节点获取的第一节点的第二状态可以为正常状态、启动恢复状态、故障状态或空状态。结合如下表5，以表5中的12种情况对上述根据第一节点的第一状态和第一节点的第二状态确定是否恢复standby事件进行说明。表5第二状态第一状态判断结果第1种故障状态正常状态y第2种启动恢复状态正常状态y第3种正常状态正常状态n第4种空状态正常状态y第5种故障状态启动恢复状态n第6种启动恢复状态启动恢复状态n第7种正常状态启动恢复状态n第8种空状态启动恢复状态n第9种故障状态故障状态n第10种启动恢复状态故障状态n第11种正常状态故障状态n第12种空状态故障状态n第1种：第一节点的第二状态为故障状态，第一节点的第一状态为正常状态时，第一主管理节点确定要恢复standby事件。本发明实施例中，第二状态为故障状态，第一状态为正常状态，可以说明业务管理系统上一次成功处理的节点事件为fault事件，而第一节点当前的实时状态为正常状态，由于第一节点从故障状态变为正常状态的过程中，必须由故障状态先变为启动恢复状态，再由启动恢复状态变为正常状态，因此表明在旧主管理节点故障时，业务管理系统中正在处理standby事件，并且未完成standby事件的处理，在这种情况下，第一主管理节点确定要恢复standby事件。第2种：第一节点的第二状态为启动恢复状态，第一节点的第一状态为正常状态时，第一主管理节点确定要恢复standby事件。本发明实施例中，第二状态为启动恢复状态，第一状态为正常状态，说明业务管理系统上一次处理的是standby事件，在旧主管理节点发生故障时，业务节点已经将该standby事件处理完，但是业务节点还未向第一主管理节点发送通知消息，表明业务管理系统未完成standby事件的处理，在这种情况下，第一主管理节点要恢复standby事件。第3种：第一节点的第二状态为正常状态，第一节点的第一状态为正常状态时，第一主管理节点确定无需恢复standby事件。本发明实施例中，第二状态为正常状态，第一状态为正常状态，可以说明在旧主管理节点发生故障时，业务管理系统已经成功处理第一节点的normal事件，表明在旧主发生故障时，业务管理系统中并不存在standby事件，在这种情况下，第一主管理节点确定无需恢复standby事件。第4种：第一节点的第二状态为空状态，第一节点的第一状态为正常状态时，第一主管理节点确定要恢复standby事件。本发明实施例中，第二状态为空状态，第一状态为正常状态，由第一节点的第二状态可以获知第一节点为新加入到业务管理系统中的任务节点，该业务管理系统还未处理该第一节点的节点事件，因此第一节点的第二状态为空状态(业务节点中没有记录该第一节点的状态)，而第一节点当前的实时状态为正常状态，表明在旧主管理节点发生故障时，业务节点正在处理第一节点的standby事件，并且该业务节点未完成该standby事件的处理，在这种情况下，第一主管理节点确定要恢复节点事件。第5种：第一节点的第二状态为故障状态，第一节点的第一状态为启动恢复状态时，第一主管理节点确定无需恢复standby事件。本发明实施例中，第二状态为故障状态，第一状态为启动恢复状态，可以说明业务管理系统上一次成功处理的节点事件为fault事件，并且第一节点的故障已解除处于启动恢复的过程，而第一节点当前的实时状态(即第一状态)为启动恢复状态，即业务管理系统中的控制节点当前发送给第一主管理节点的节点事件为standby事件，表明在旧主管理节点故障时，业务管理系统中并不存在standby事件，在这种情况下，第一主管理节点确定无需恢复standby事件。第6种：第一节点的第二状态为启动恢复状态，第一节点的第一状态为启动恢复状态时，第一主管理节点确定无需恢复standby事件。本发明实施例中，第二状态为启动恢复状态，第一状态为启动恢复状态，由于第一节点当前的实时状态(及第一状态)为启动恢复状态，即业务管理系统中的控制节点当前发送给第一主管理节点的节点事件为standby事件，表明在旧主管理节点故障时，业务管理系统中并不存在standby事件，在这种情况下，第一主管理节点确定无需恢复standby事件。第7种：第一节点的第二状态为正常状态，第一节点的第一状态为启动恢复状态时，第一主管理节点确定无需恢复standby事件。本发明实施例中，第二状态为正常状态，第一状态为启动恢复状态，由于第一节点当前的实时状态(及第一状态)为启动恢复状态，即业务管理系统中的控制节点当前发送给第一主管理节点的节点事件为standby事件，表明在旧主管理节点故障时，业务管理系统中并不存在standby事件，在这种情况下，第一主管理节点确定无需恢复standby事件。第8种：第一节点的第二状态为空状态，第一节点的第一状态为启动恢复状态时，第一主管理节点确定无需恢复standby事件。本发明实施例中，第二状态为空状态，第一状态为启动恢复状态，由于第一节点当前的实时状态(及第一状态)为启动恢复状态，即业务管理系统中的控制节点当前发送给第一主管理节点的节点事件为standby事件，表明在旧主管理节点故障时，业务管理系统中并不存在standby事件，在这种情况下，第一主管理节点确定无需恢复standby事件。第9种：第一节点的第二状态为故障状态，第一节点的第一状态为故障状态时，第一主管理节点确定无需恢复standby事件。本发明实施例中，第二状态为故障状态，第一状态为故障状态，可以说明第一节点仍然处于故障状态，并未恢复，业务管理系统中处理的是fault事件，表明在旧主管理节点故障时，业务管理系统中并不存在standby事件，在这种情况下，第一主管理节点确定无需恢复standby事件。第10种：第一节点的第二状态为启动恢复状态，第一节点的第一状态为故障状态时，第一主管理节点确定无需恢复standby事件。本发明实施例中，第二状态为启动恢复状态，第一状态为故障状态，可以表明在旧主管理节点发生故障时，业务管理系统正在处理第一节点standby事件，并且第一节点启动过程中发生故障(即无法正常启动了)，在这种情况下，第一主管理节点无需再补充第一节点的standby事件，而是处理第一节点的fault事件。第11种：第一节点的第二状态为正常状态，第一节点的第一状态为故障状态时，第一主管理节点确定无需恢复standby事件。本发明实施例中，第二状态为正常状态，第一状态为故障状态，可以表明在旧主管理节点发生故障时，业务管理系统正在处理第一节点normal事件，并且第一节点发生故障，在这种情况下，业务管理系统中并不存在standby事件，第一主管理节点确定无需恢复standby事件，而是处理第一节点的fault事件。第12种：第一节点的第二状态为空状态，第一节点的第一状态为故障状态时，第一主管理节点确定无需恢复standby事件。本发明实施例中，第二状态为空状态，第一状态为故障状态，由第一节点的第二状态可以获知第一节点为新加入到业务管理系统中的任务节点，该业务管理系统还未处理该第一节点的节点事件，因此第一节点的第二状态为空状态(业务节点中没有记录该第一节点的状态)，而第一节点当前的实时状态为故障状态，表明在旧主管理节点发生故障时，第一节点正在加入该业务管理系统，并且在加入的过程中发生故障，在这种情况下，业务管理系统中并不存在standby事件，第一主管理节点确定无需恢复standby事件，而是处理第一节点的fault事件。综合上述12种情况的分析可以得到上述s2072a结论：即在第一节点的第一状态为正常状态，第一节点的第二状态为启动恢复状态、故障状态或空状态的情况下，第一主管理节点确定恢复standby事件。在第一主管理节点确定是否恢复第一节点的standby事件时，可以根据第一节点的第一状态和第一节点的第二状态确定是否恢复第一节点的standby事件。需要说明的是，本发明实施例可以不限定s2071与s2072的执行顺序。即本发明实施例可以先执行s2071，后执行s2072；也可以先执行s2072，后执行s2071；还可以同时执行s2071和s2072。本发明实施例中，上述第一主管理节点确定要恢复第一节点的第一节点节点事件之后，第一主管理节点可以将第一节点的第一节点事件发送给业务节点，以完成该第一节点的第一节点事件的恢复(即业务管理系统重新再处理一遍该第一节点的第一节点事件)。具体的，对于恢复第一节点的第一节点事件的过程的详细描述可以参见上述s104-s110的相关描述，此处不再赘述。可以理解的是，本发明实施例中，在恢复节点事件的过程中，无需设置缓冲队列记录旧主管理节点至少最近3次的处理节点事件的情况，如此，能够在防止节点事件被遗漏的情况下，使得节点事件不对业务管理系统的性能产生影响、且简化了节点事件的处理机制。需要说明的是，本发明实施例中，在业务管理系统中的旧主管理节点发生故障，并且第一主管理节点作为主管理节点代替旧主管理节点之后，一方面，第一主管理节点可以将本次接收的第一节点的节点事件(即第一节点的新节点事件)发送给业务节点，由业务节点处理本次第一节点的节点事件；另一方面，第一主管理节点可以确定是否需要恢复上一次接收的第一节点的节点事件(即确定旧主管理故障时，业务管理系统和总是否存在节点事件被遗漏的现象)，并且在第一主管理节点确定需要恢复节点事件的情况下，恢复第一节点的节点事件。上述主要从各个网元之间交互的角度对本发明实施例提供的方案进行了介绍。可以理解的是，各个网元，例如管理节点、业务节点等为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本发明实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。本发明实施例可以根据上述方法示例对管理节点、业务节点等进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。在采用对应各个功能划分各个功能模块的情况下，图7示出了上述实施例中所涉及的管理节点的一种可能的结构示意图，该管理节点可以为业务管理系统中的主管理节点(包括旧主管理节点(上述实施例中提及的主管理节点)和新主管理节点(即第一主管理节点))，如图7所示，该管理节点可以包括：获取模块30和确定模块31。获取模块30可以用于支持上述管理节点执行上述方法实施例中的s205和s206(包括s206a和s206d)；确定模块31可以用于支持管理节点执行上述方法实施例中的s112、s204、s207(包括s2071(包括s2071a)和s2072(包括s2072a))。可选的，如图7所示，该第一主管理节点还可以包括接收模块32、发送模块33、预处理模块34和更新模块35。接收模块32可以用于支持第一主管理节点执行上述方法实施例中的s103、s109和s203；发送模块33可以用于支持管理节点执行上述方法实施例中的s104和s113；预处理模块34可以支持管理节点支持上述方法实施例中的s104a；更新模块35可以支持管理节点支持上述方法实施例中的s110。其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。在采用集成的单元的情况下，图8示出了上述实施例中所涉及的管理节点(包括旧主管理节点(上述实施例中提及的主管理节点)和新主管理节点(即第一主管理节点))的一种可能的结构示意图。如图8所示，该管理节点可以包括：处理模块40和通信模块41。处理模块40可以用于对管理节点的动作进行控制管理，例如，处理模块40可以用于支持管理节点执行上述方法实施例中的s104a、s110、s112、s204、s205、s206(包括s206a和s206d)、s207(包括s2071(包括s2071a)和s2072(包括s2072a))，和/或用于本文所描述的技术的其它过程。通信模块61可以用于支持基站与其他网络实体的通信，例如通信模块41可以用于支持管理节点执行上述方法实施例中的s103、s104、s109、s113和s203。可选的，如图8所示，该基站还可以包括存储模块42，用于存储管理节点的程序代码和数据。其中，处理模块40可以是处理器或控制器(例如可以是上述如图3所示的处理器20)，例如可以是cpu、通用处理器、dsp、asic、fpga或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本发明实施例公开内容所描述的各种示例性的逻辑方框、模块和电路。上述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等等。通信模块41可以是收发器、收发电路或通信接口等(例如可以是上述如图3所示的通信接口22)。存储模块42可以是存储器(例如可以是上述如图3所示的存储器21)。当处理模块40为处理器，通信模块41为收发器，存储模块42为存储器时，处理器、收发器和存储器可以通过总线连接。总线可以是外设部件互连标准(peripheralcomponentinterconnect,pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture,eisa)总线等。总线可以分为地址总线、数据总线、控制总线等。在采用对应各个功能划分各个功能模块的情况下，图9示出了上述实施例中所涉及的业务节点的一种可能的结构示意图，如图9所示，该业务节点可以包括：接收模块50、处理模块51、发送模块52和更新模块53。接收模块50可以用于支持业务节点执行上述方法实施例中的s105；处理模块51可以用于支持业务节点执行上述方法实施例中的s106；发送模块52可以用于支持业务节点执行上述方法实施例中的s108；更新模块53可以用于支持业务节点执行上述方法实施例中的s107。其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。在采用集成的单元的情况下，图10示出了上述实施例中所涉及的业务节点的一种可能的结构示意图。如图10所示，该业务节点可以包括：处理模块60和通信模块61。处理模块60可以用于对业务节点的动作进行控制管理，例如，处理模块60可以用于支持业务节点执行上述方法实施例中的s106和s107，和/或用于本文所描述的技术的其它过程。通信模块61可以用于支持业务节点与其他网络实体的通信，例如通信模块61可以用于支持业务节点执行上述方法实施例中的s105和s108。可选的，如图10所示，该业务节点还可以包括存储模块62，用于存储终端的程序代码和数据。其中，处理模块60可以是处理器或控制器，例如可以是cpu、通用处理器、dsp、asic、fpga或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本发明实施例公开内容所描述的各种示例性的逻辑方框、模块和电路。上述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等等。通信模块61可以是收发器、收发电路或通信接口等。存储模块62可以是存储器。当处理模块60为处理器，通信模块61为收发器，存储模块62为存储器时，处理器、收发器和存储器可以通过总线连接。总线可以是pci总线或eisa总线等。总线可以分为地址总线、数据总线、控制总线等。本发明实施例中，控制节点也可以采用对应各个功能划分各个功能模块或者采用集成单元实现，具体的，各个功能模块或集成单元可以执行上述方法实施例中控制节点所执行的各个方法步骤，此处不再赘述。在上述实施例中，可以全部或部分地通过软件程序、硬件、固件或者其任意组合来实现。当使用软件程序实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机指令时，全部或部分地产生按照本发明实施例中的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digitalsubscriberline,dsl))方式或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包括一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如，软盘、磁盘、磁带)、光介质(例如，数字视频光盘(digitalvideodisc,dvd))、或者半导体介质(例如固态硬盘(solidstatedrives,ssd))等。通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。当前第1页12