CN109445942A - 一种心跳消息的处理方法及装置 - Google Patents

Abstract

本申请公开了一种心跳消息的处理方法及装置，包括：检测待检测消息中是否包含预先针对于心跳消息设置的类型标识，若待检测消息中包含该类型标识，则利用正在处理业务的业务线程对该待检测消息进行实时处理，而若待检测消息中不包含该类型标识，则将该待检测消息放入需要等待处理的消息队列中，以便于在该消息队列中的其它消息被处理完之后，由与该待检测消息对应的线程来处理该待检测消息。可见，通过复用第一节点上用于处理业务的业务线程来处理心跳消息，从而无需在第一节点上设置专门的线程单独用于处理其它节点发送的心跳消息，这就避免了因为设置单独用于处理心跳消息的线程而造成第一节点的操作系统的资源浪费。

Description

一种心跳消息的处理方法及装置

技术领域

本申请涉及消息处理技术领域，特别是涉及一种心跳消息的处理方法及装置。

背景技术

在分布式集群中，各个节点之间为了感知其它节点的状态，通常都会相互发送心跳消息来通告自己的存活状态。例如，分布式集群中的第一节点通常会以一定的时间间隔向第二节点发送心跳信息，若第二节点在连续的一段时间内能够接收并检测到第一节点的心跳消息，则第二节点可以确认第一节点处于存活状态，而若第二节点在连续的一段时间内，一直没有接收到第二节点的心跳信息，则第二节点就会认为第一节点已经失效。类似的，第二节点也会以一定的时间间隔向第一节点发送心跳信息，以向第一节点通告自己的存活状态。

现有的检测心跳消息的方案中，通常是在每个节点中增加一个单独的线程来专门处理其它节点发送的心跳消息，但是，该线程在处理相邻两个心跳消息的过程中，可能会存在较长的时间段处于闲置状态，这就使得在每个节点上仅因为需要处理心跳消息而单独开启一个线程，会对该节点的操作系统造成一定的资源浪费。

发明内容

本申请实施例提供了一种心跳消息的处理方法及装置，以避免设置单独的线程来处理心跳消息对该第一节点的操作系统造成资源浪费。

第一方面，本申请实施例提供了一种心跳消息的处理方法，所述方法包括：

第一节点检测待检测消息中是否包含预先针对于心跳消息设置的类型标识；

第一节点若确定所述待检测消息中包含所述类型标识，则确定所述待检测消息为心跳消息，并利用业务线程对所述心跳消息进行实时处理；

第一节点若确定所述待检测消息中不包含所述类型标识，则将所述待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理。

在一些可能的实施方式中，所述方法还包括：

第一节点查询所述待检测消息是否为允许被快速分发的消息；

则所述第一节点若确定所述待检测消息中包含所述类型标识，则确定所述待检测消息为心跳消息，并利用业务线程对所述心跳消息进行实时处理，包括：

第一节点若确定所述待检测消息中包含所述类型标识，且所述待检测消息为允许被快速分发的消息，则确定所述待检测消息为心跳消息，并利用业务线程对所述心跳消息进行实时处理。

在一些可能的实施方式中，所述第一节点若确定所述待检测消息中不包含所述类型标识，则将所述待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理，包括：

第一节点若确定所述待检测消息中不包含所述类型标识，和/或，第一节点若确定所述待检测消息并非为允许被快速分发的消息，则将所述待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理。

在一些可能的实施方式中，所述类型标识位于所述心跳消息所包含的能够表征消息类型的字段中。

在一些可能的实施方式中，所述待检测消息为第二节点向所述第一节点发送的消息，或，所述待检测消息为所述第一节点向所述第一节点发送的消息。

第二方面，本申请实施例还提供了一种心跳消息的处理装置，所述装置应用于第一节点，所述装置包括：

检测单元，用于检测待检测消息中是否包含预先针对于心跳消息设置的类型标识；

实时处理单元，用于若确定所述待检测消息中包含所述类型标识，则确定所述待检测消息为心跳消息，并利用业务线程对所述心跳消息进行实时处理；

消息放置单元，用于确定所述待检测消息中不包含所述类型标识，则将所述待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理。

在一些可能的实施方式中，所述装置还包括：

查询单元，用于查询所述待检测消息是否为允许被快速分发的消息；

则所述实时处理单元，具体用于若确定所述待检测消息中包含所述类型标识，且所述待检测消息为允许被快速分发的消息，则确定所述待检测消息为心跳消息，并利用业务线程对所述心跳消息进行实时处理。

在一些可能的实施方式中，所述消息放置单元，具体用于，若确定所述待检测消息中不包含所述类型标识，和/或，第一节点若确定所述待检测消息并非为允许被快速分发的消息，则将所述待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理。

在一些可能的实施方式中，所述类型标识位于所述心跳消息所包含的能够表征消息类型的字段中。

在一些可能的实施方式中，所述待检测消息为第二节点向所述第一节点发送的消息，或，所述待检测消息为所述第一节点向所述第一节点发送的消息。

在本申请实施例的上述实现方式中，通过复用第一节点上处理业务的线程来处理该第一节点接收到的第二节点等其它节点发送的心跳消息，以避免对该第一节点的操作系统所造成的资源浪费。具体的，第一节点可以检测待检测消息中是否包含预先针对于心跳消息设置的类型标识，可以理解，若待检测消息中包含该类型标识，表明该待检测消息为其它节点所发送的心跳消息，则第一节点可以利用正在处理业务的业务线程对该待检测消息进行实时处理，也即对心跳消息进行实时处理，而若待检测消息中不包含该类型标识，表明该待检测消息并非是其它节点发送的心跳消息，则第一节点可以将该待检测消息放入需要等待处理的消息队列中，以便于在该消息队列中的其它消息被处理完之后，由与该待检测消息对应的线程来处理该待检测消息。可见，在第一节点处理其它节点发送的心跳消息的过程中，是通过复用第一节点上用于处理业务的业务线程来处理心跳消息，从而无需在第一节点上设置专门的线程单独用于处理其它节点发送的心跳消息，这就避免了因为设置单独用于处理心跳消息的线程而造成第一节点的操作系统的资源浪费；而且，在处理心跳消息时，并未是将其放入等待被处理的消息队列中，而是直接对该心跳消息进行实时处理，这样就可以避免由于消息队列中等待被处理的消息较多而造成心跳消息的延后处理，从而可以避免该心跳消息等待被处理的时间过长而造成第一节点误以为发送该心跳消息的节点已经失效的问题，即可以避免第一节点对其它节点的存活状态造成误判。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本申请实施例中一应用场景示意图；

图2为本申请实施例中一种心跳消息的处理方法的流程示意图；

图3为本申请实施例中另一种心跳消息的处理方法的流程示意图；

图4为本申请实施例中一种心跳消息的处理装置的结构示意图。

具体实施方式

在分布式集群中，各个节点之间通常会相互发送心跳消息，以告知其它节点自己的存活状态。如，第二节点可以周期性的向第一节点发送心跳消息，第一节点若能接收并且检测出第二节点的心跳消息，则可以确定该第二节点当前处于存活状态，而若第一节点连续一段时间内均没有接收到第二节点的心跳消息，则第一节点可以确定第二节点当前时刻已经处于失效状态，则第一节点可以结束与第二节点之间的业务；类似的，第一节点也可以周期性向第二节点发送心跳信息，以向第二节点告知自身的存活状态。而现有的技术方案中，通常是在第一节点上设置专门的线程来处理其它节点(如第二节点)发送的心跳消息，但是，由于第二节点发送心跳消息的周期时长相对较长，而第一节点上的线程处理一个心跳消息所需的耗时通常较短，因此，第一节点在处理完第二节点发送的第一心跳消息后，可能会闲置较长的时间再去处理第二节点发送的第二心跳消息，其中，第一心跳消息与第二心跳消息为第二节点发送的两个相邻的心跳消息。这就使得该第一节点通常是处于闲置状态，这就使得为第一节点设置单独的线程来处理心跳消息，会对该第一节点的操作系统造成较大的资源浪费。

为了解决上述技术问题，本申请提供了一种心跳消息的处理方法，通过复用第一节点上处理业务的线程来处理该第一节点接收到的第二节点等其它节点发送的心跳消息，以避免对该第一节点的操作系统所造成的资源浪费。具体的，第一节点可以检测待检测消息中是否包含预先针对于心跳消息设置的类型标识，可以理解，若待检测消息中包含该类型标识，表明该待检测消息为其它节点所发送的心跳消息，则第一节点可以利用正在处理业务的业务线程对该待检测消息进行实时处理，也即对心跳消息进行实时处理，而若待检测消息中不包含该类型标识，表明该待检测消息并非是其它节点发送的心跳消息，则第一节点可以将该待检测消息放入需要等待处理的消息队列中，以便于在该消息队列中的其它消息被处理完之后，由与该待检测消息对应的线程来处理该待检测消息。

可见，在第一节点处理其它节点发送的心跳消息的过程中，是通过复用第一节点上用于处理业务的业务线程来处理心跳消息，从而无需在第一节点上设置专门的线程单独用于处理其它节点发送的心跳消息，这就避免了因为设置单独用于处理心跳消息的线程而造成第一节点的操作系统的资源浪费；而且，在处理心跳消息时，并未是将其放入等待被处理的消息队列中，而是直接对该心跳消息进行实时处理，这样就可以避免由于消息队列中等待被处理的消息较多而造成心跳消息的延后处理，从而可以避免该心跳消息等待被处理的时间过长而造成第一节点误以为发送该心跳消息的节点已经失效的问题，即可以避免第一节点对其它节点的存活状态造成误判。

作为一种示例，本申请实施例可以应用至如图1所示的示例性应用场景。在该应用场景中，分布式集群中可以包括节点1、节点2等多个节点，节点1、节点2等多个节点相互之间可以周期性的发送自身的心跳消息，该心跳消息中可以包含能够表征其为心跳消息的类型标识。节点1接收到节点2发送的消息后，可以检测该消息中是否包含心跳消息的类型标识，若通过检测确定节点2发送的消息中包含心跳消息的类型标识，即确定该消息为心跳消息，则节点1可以直接对该消息进行实时处理，若通过检测确定节点2发送的消息中不包含心跳消息的类型标识，即确定该消息并非是心跳消息，则节点1可以将该消息置入待处理的消息队列中，以等待与该消息对应的线程对该消息进行处理。同样，节点2对于节点1发送的消息也可以进行类似的检测与处理。

可以理解的是，上述场景仅是本申请实施例提供的一个场景示例，本申请实施例并不限于此场景。比如，在一些场景中，节点1也可以自己生成相应的消息并将该消息发送给自己，也即，节点1所检测的消息中也可以包含节点1自己向自己发送的消息；或者是，节点1与节点2属于其它网络架构中的节点，而可以不仅仅限定于为分布式集群中的节点等。

为使本申请的上述目的、特征和优点能够更加明显易懂，下面将结合附图对本申请实施例中的各种非限定性实施方式进行示例性说明。显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

参阅图2，图2示出了本申请实施例中一种心跳消息的处理方法的流程示意图，该方法具体可以包括：

S201：第一节点检测待检测信息中是否包含预先针对于心跳消息设置的类型标识。

实际应用中，其它节点向第一节点发送的消息中不仅仅可以是心跳消息，也可以其它业务消息，例如，可以是其它节点向第一节点发送的有关于某一用户的身份认证消息等。也就是说，第一节点所处理的消息，既可能是其它节点发送的心跳消息，也可能不是其它节点发送的心跳消息。本实施例中，为了便于将心跳消息与其它消息进行区分，可以预先针对于心跳信息设置相应的类型标识，该类型标识表征了包含该类型标识的消息为心跳消息。相应的，第一节点在处理待检测消息(即接收到的消息)时，可以检测该待检测消息中是否包含心跳信息的类型标识，若包含，则可以确定该待检测消息为心跳消息，而若不包含，则可以确定该待检测消息并非为心跳消息。

在一些可能的实施方式中，针对于心跳消息设置的类型标识，具体可以位于该心跳信息中的特定字段，该特定字段可以对该消息的类型进行标识。具体实现时，可以对心跳消息中某些特定字段的字段值进行修改，使得修改后的字段值可以表征为该消息为心跳消息。

上述实施方式中，针对于心跳消息而设置的类型标识位于原始的心跳消息中，而在另一些可能的实施方式中，该心跳消息也可以是在原始的心跳消息的基础上附加类型标识而得到的，而无需对原始的心跳信息中的字段进行修改。具体的，其它节点在生成原始的心跳消息后，可以以添加标签等形式为该心跳消息附加类型标识，使得其它节点向第一节点发送的心跳消息为原始的心跳消息附加类型标识而得到的消息。

值得注意的是，第一节点所接收到的消息中，并不仅仅可以是其它节点向第一节点发送的消息，也可以是由第一节点自己向自己发送的消息。即，在一些应用场景中，第一节点也可以在产生消息后，将该消息发送给自己以进行相应的消息处理。

S202：第一节点若确定该待检测消息中包含心跳消息的类型标识，则确定该待检测消息为心跳消息，并利用业务线程对该心跳消息进行实时处理。

值得注意的是，第一节点若在待检测消息中检测出心跳消息的类型标识，则可以确定其所接收到的待检测消息，为第二节点等其它节点发送的心跳消息，此时，第一节点是复用处理业务的业务线程来处理该待检测消息。可以理解，由于是复用业务线程来处理心跳消息，因此，业务线程在处理两个相邻的心跳消息的间隙，可以处理与业务相关的消息，从而无需预先在第一节点上设置专门用于处理心跳消息的线程来处理心跳消息，这样就可以避免所增加的线程在处理相邻两个心跳消息之间的时间间隙处于闲置状态，进而可以避免因为增加线程而造成第一节点的操作系统的资源浪费。

另外，还需说明的是，第一节点上的业务线程在确定该待检测消息为心跳消息时，是对该心跳消息进行实时处理，因此，第一节点并非是按照一般的消息处理逻辑将其放置在消息队列中以使得业务线程对消息队列中的消息依次进行处理，而是优先对该心跳消息进行处理。这样，即使第一节点在接收到该心跳消息之前已经接收到其它与业务相关的消息，该第一节点上的业务线程也可以是优先处理该心跳消息而后处理与业务相关的消息。可以理解，当第一节点上的业务较为繁忙，业务逻辑较多时，位于消息队列中等待被处理的消息可能也会较多，若将心跳消息置入该消息队列中，则业务线程会耗费较多的时间处理排在该心跳消息之前的其它消息后，再去处理该心跳消息，这就使得该心跳消息需要等待较长的时间才能被处理，从而可能会导致该心跳消息等待被处理的等待时间过长而使得第一节点认为发送该心跳消息的节点因为失效而没有向第一节点发送心跳消息，从而会使得第一节点对其它节点的存活状态造成误判。因此，本实施例中，第一节点在确定出待检测消息为心跳消息后，通过实时对该心跳消息进行处理，可以以避免由于心跳消息等待被处理的等待时间过长而导致第一节点对发送该心跳消息的节点的存活状态造成误判。

S203：第一节点若确定该待检测消息中不包含心跳消息的类型标识，则将该待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理。

可以理解，若第一节点确定待检测消息中不包含心跳消息的类型标识，表明该待检测消息并非是其它节点向第一节点发送的心跳消息，则第一节点可以不用对该待检测消息进行优先处理，而可以执行正常的消息处理逻辑来将该待检测消息置入待处理的消息队列中，以便于第一节点上相应的线程来处理置于该消息队列中的待检测消息。

本实施例中，第一节点可以检测待检测消息中是否包含预先针对于心跳消息设置的类型标识，若待检测消息中包含该类型标识，表明该待检测消息为其它节点所发送的心跳消息，则第一节点可以利用正在处理业务的业务线程对该待检测消息进行实时处理，也即对心跳消息进行实时处理，而若待检测消息中不包含该类型标识，表明该待检测消息并非是其它节点发送的心跳消息，则第一节点可以将该待检测消息放入需要等待处理的消息队列中，以便于在该消息队列中的其它消息被处理完之后，由与该待检测消息对应的线程来处理该待检测消息。可见，在第一节点处理其它节点发送的心跳消息的过程中，是通过复用第一节点上用于处理业务的业务线程来处理心跳消息，从而无需在第一节点上设置专门的线程单独用于处理其它节点发送的心跳消息，这就避免了因为设置单独用于处理心跳消息的线程而造成第一节点的操作系统的资源浪费；而且，在处理心跳消息时，并未是将其放入等待被处理的消息队列中，而是直接对该心跳消息进行实时处理，这样就可以避免由于消息队列中等待被处理的消息较多而造成心跳消息的延后处理，从而可以避免该心跳消息等待被处理的时间过长而造成第一节点误以为发送该心跳消息的节点已经失效的问题，即可以避免第一节点对其它节点的存活状态造成误判。

上述实施例中，第一节点在判断待检测消息为心跳消息后，直接对该心跳消息进行实时处理，而实际应用中，由于第一节点在心跳消息的处理周期内的任意时刻，只要能够成功检测并处理其它节点发送的心跳消息，则第一节点均会认为该节点处于存活状态。举例来说，若第一节点在处理完第二节点发送的第一心跳消息后，能够在接下来的处理周期1秒内成功检测并且处理第二节点发送的第二心跳消息，则第一节点可以认为第二节点为存活状态，而若第一节点在接下来的处理周期1秒内没有成功检测并且处理第二节点的心跳消息，则第一节点会认为第二节点已经失效。也就是说，在一些可能的应用场景中，第一节点在确定出待检测消息为心跳消息后，在不影响第一节点对发送该心跳消息的节点的存活状态作出正确判断的情况下，也可以对部分心跳消息不进行实时处理。基于此，本申请实施例还提供了另一种心跳消息的处理方法。具体的，参见图3，图3示出了本申请实施例中另一种心跳消息的处理方法的流程示意图，该方法包括：

S301：第一节点检测待检测信息中是否包含预先针对于心跳消息设置的类型标识。

S302：第一节点查询该待检测消息是否为允许被快速分发的消息。

本实施例中，允许被快速分发的消息，即为被有效处理的消息。通常情况下，第一节点所接收到的消息，会被置入至消息队列中等待第一节点上相应的线程来依次处理该消息队列中的消息，而若该消息为允许被快速分发的消息，则可以由第一节点上相应的线程优先对该消息进行处理，而无需等待消息队列中的消息被处理完后再对该消息进行处理。

在一种示例性的实施方式中，第一节点可以利用接口来该待检测消息是否为允许被快速分发的消息。比如，可以在第一节点所在的集群中设置消息基类，并针对于该消息基类设置与之对应的接口，所设置的接口可以用于查询该消息基类中的消息是否为允许被快速分发的消息。这样，该集群中的第一节点的消息类可以继承该消息基类，同时，第一节点用于查询待检测消息是否为允许被快速分发的消息的接口，可以继承消息基类所提供的接口。当第一节点接收到待检测消息时，可以利用该接口对该待检测消息的类型进行查询，及查询该待检测消息是否为允许被快速分发的消息。

由于通常情况下，第一节点所接收到的消息中可能多数消息并非为心跳消息，则对于第一节点上用于查询待检测消息的类型的接口，其默认的返回值通常可以是“False”，即返回值为“假”，即该消息可以按照以往的处理逻辑不变(比如可以是将其置入消息队列中等待相应的线程依次对消息队列中的消息进行处理)。当待检测消息为允许被快速分发的消息时，则可以重写该接口，使得该接口所返回的值为“True”，即返回值为“真”，此时，可以确定该待检测消息为允许被快速分发的消息。

S303：第一节点若确定该待检测消息中包含心跳消息的类型标识，且该待检测消息为允许被快速分发的消息，则确定该待检测消息为心跳消息，并利用业务线程对该心跳消息进行实时处理。

本实施例中，即使确定出带检测消息为心跳消息，也并非一定需要对该心跳消息进行实时处理。比如，当第一节点上的业务不繁忙时，消息队列中所缓存的消息通常数量较少，因此，即使将心跳消息置入消息队列中，但是因为消息队列缓存的消息数量少，所以该心跳消息等待被处理的时间较短，也即，该心跳消息可以在短时间内被快速处理，从而不会影响第一节点对发送该心跳消息的其它节点的存活状态的判断。此时，该待检测消息可以为不允许被快速分发的消息，可以无需对该待检测消息进行实时处理。

当然，若确定待检测消息为心跳消息，并且通过查询可以确定该待检测消息又为允许被快速分发的消息时，可以不将其置入消息队列中等待被处理，以避免该待检测消息由于等待被处理的时间过长而导致第一节点对发送该待检测消息的节点的存活状态造成误判，即可以对该待检测消息进行实时处理。

S304：第一节点若确定该待检测消息中不包含心跳消息的类型标识，和/或，该待检测消息不为允许被快速分发的消息，则将该待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理。

本实施例中，第一节点所确定该待检测消息中不包含心跳消息的类型标识，则表明该待检测消息不是心跳消息，可以将其置入待处理的消息队列中的等待被处理；或者是，第一节点即使确定该待检测消息为心跳消息，但是该待检测消息并非为允许被快速分发的消息，该待检测消息也不满足实时处理的条件，则可以按照正常的消息处理逻辑将其置入消息队列中等待被处理。

此外，本申请实施例还提供了一种心跳消息的处理装置。参见图4，图4示出了本申请实施例中一种心跳消息的处理装置的结构示意图，该装置400应用于第一节点，该装置400具体可以包括：

检测单元401，用于检测待检测消息中是否包含预先针对于心跳消息设置的类型标识；

实时处理单元402，用于若确定所述待检测消息中包含所述类型标识，则确定所述待检测消息为心跳消息，并利用业务线程对所述心跳消息进行实时处理；

消息放置单元403，用于确定所述待检测消息中不包含所述类型标识，则将所述待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理。

在一些可能的实施方式中，所述装置400还包括：

查询单元，用于查询所述待检测消息是否为允许被快速分发的消息；

则所述实时处理单元402，具体用于若确定所述待检测消息中包含所述类型标识，且所述待检测消息为允许被快速分发的消息，则确定所述待检测消息为心跳消息，并利用业务线程对所述心跳消息进行实时处理。

在一些可能的实施方式中，所述消息放置单元403，具体用于，若确定所述待检测消息中不包含所述类型标识，和/或，第一节点若确定所述待检测消息并非为允许被快速分发的消息，则将所述待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理。

在一些可能的实施方式中，所述类型标识位于所述心跳消息所包含的能够表征消息类型的字段中。

在一些可能的实施方式中，所述待检测消息为第二节点向所述第一节点发送的消息，或，所述待检测消息为所述第一节点向所述第一节点发送的消息。

本实施例中，在第一节点处理其它节点发送的心跳消息的过程中，是通过复用第一节点上用于处理业务的业务线程来处理心跳消息，从而无需在第一节点上设置专门的线程单独用于处理其它节点发送的心跳消息，这就避免了因为设置单独用于处理心跳消息的线程而造成第一节点的操作系统的资源浪费；而且，在处理心跳消息时，并未是将其放入等待被处理的消息队列中，而是直接对该心跳消息进行实时处理，这样就可以避免由于消息队列中等待被处理的消息较多而造成心跳消息的延后处理，从而可以避免该心跳消息等待被处理的时间过长而造成第一节点误以为发送该心跳消息的节点已经失效的问题，即可以避免第一节点对其它节点的存活状态造成误判。

本申请实施例中提到的“第一节点”、“第一心跳消息”等名称中的“第一”只是用来做名字标识，并不代表顺序上的第一。该规则同样适用于“第二”等。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到上述实施例方法中的全部或部分步骤可借助软件加通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如只读存储器(英文：read-onlymemory，ROM)/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者诸如路由器等网络通信设备)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本申请示例性的实施方式，并非用于限定本申请的保护范围。

Claims (10)

1.一种心跳消息的处理方法，其特征在于，所述方法包括：

第一节点检测待检测消息中是否包含预先针对于心跳消息设置的类型标识；

第一节点若确定所述待检测消息中包含所述类型标识，则确定所述待检测消息为心跳消息，并利用业务线程对所述心跳消息进行实时处理；

第一节点若确定所述待检测消息中不包含所述类型标识，则将所述待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

第一节点查询所述待检测消息是否为允许被快速分发的消息；

则所述第一节点若确定所述待检测消息中包含所述类型标识，则确定所述待检测消息为心跳消息，并利用业务线程对所述心跳消息进行实时处理，包括：

第一节点若确定所述待检测消息中包含所述类型标识，且所述待检测消息为允许被快速分发的消息，则确定所述待检测消息为心跳消息，并利用业务线程对所述心跳消息进行实时处理。

3.根据权利要求2所述的方法，其特征在于，所述第一节点若确定所述待检测消息中不包含所述类型标识，则将所述待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理，包括：

第一节点若确定所述待检测消息中不包含所述类型标识，和/或，第一节点若确定所述待检测消息并非为允许被快速分发的消息，则将所述待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理。

4.根据权利要求1至3任一项所述的方法，其特征在于，所述类型标识位于所述心跳消息所包含的能够表征消息类型的字段中。

5.根据权利要求1所述的方法，其特征在于，所述待检测消息为第二节点向所述第一节点发送的消息，或，所述待检测消息为所述第一节点向所述第一节点发送的消息。

6.一种心跳消息的处理装置，其特征在于，所述装置应用于第一节点，所述装置包括：

检测单元，用于检测待检测消息中是否包含预先针对于心跳消息设置的类型标识；

实时处理单元，用于若确定所述待检测消息中包含所述类型标识，则确定所述待检测消息为心跳消息，并利用业务线程对所述心跳消息进行实时处理；

消息放置单元，用于确定所述待检测消息中不包含所述类型标识，则将所述待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括：

查询单元，用于查询所述待检测消息是否为允许被快速分发的消息；

则所述实时处理单元，具体用于若确定所述待检测消息中包含所述类型标识，且所述待检测消息为允许被快速分发的消息，则确定所述待检测消息为心跳消息，并利用业务线程对所述心跳消息进行实时处理。

8.根据权利要求7所述的装置，其特征在于，所述消息放置单元，具体用于，若确定所述待检测消息中不包含所述类型标识，和/或，第一节点若确定所述待检测消息并非为允许被快速分发的消息，则将所述待检测消息置入待处理的消息队列中，以等待对所述待检测消息进行处理。

9.根据权利要求6至8任一项所述的装置，其特征在于，所述类型标识位于所述心跳消息所包含的能够表征消息类型的字段中。

10.根据权利要求6所述的装置，其特征在于，所述待检测消息为第二节点向所述第一节点发送的消息，或，所述待检测消息为所述第一节点向所述第一节点发送的消息。