CN116264535A - 消息故障处理方法、装置、计算设备及计算机存储介质 - Google Patents

Abstract

本申请实施例公开了一种消息故障处理方法、装置、计算设备及计算机存储介质，其中，该方法包括：获取消息发送故障的故障频率，并对生产端进行心跳检测得到心跳检测结果；根据故障频率和心跳检测结果，确定消息发送故障对应的故障类型；根据故障类型，执行与故障类型对应的故障处理策略，以消除消息发送故障。该方案为生产端增加了心跳检测机制，充分结合消息发送故障的故障频率和心跳检测结果来有效识别该消息发送故障对应的故障类型，针对不同故障类型，通过执行不同的故障处理策略来消除消息发送故障，能够在保证消息顺序的前提下提高失败消息重试成功的概率，而且实现了生产端的业务和消费端的业务对集群的故障无感知，不影响上下游业务。

Description

消息故障处理方法、装置、计算设备及计算机存储介质

技术领域

本申请实施例涉及互联网技术领域，具体涉及一种消息故障处理方法、装置、计算设备及计算机存储介质。

背景技术

消息队列经常处于复杂的分布式系统中，在网络波动、服务宕机、程序异常等因素的影响下，很可能出现消息发送失败的问题。对于发送失败的消息，现有技术通常采用定时循环的方式进行重试。以flume为例，flume为一种数据采集工具，flume采集数据的架构包括数据源、通道以及sink组件，其中，数据源可以从日志文件、网络端口、kafka集群等多种数据源采集数据，封装并写入通道。数据成功写入到通道中后，sink组件会从通道中主动拉去数据写入到HDFS、HBase、Hive、ES等多种大数据组件中。其中，通道为一个被动存储器，负责暂存数据。flume的通道包括memory通道等，memory通道使用内存缓存数据，吞吐率极高。

然而，当需要实时处理大量消息时，反复重试产生的失败消息可能会阻塞正常的批处理。当flume使用memory通道模式sink kafka进行重试时，大规模的重试将导致memory通道发生阻塞，影响flume资源写入，造成上游业务出现异常。

发明内容

鉴于上述问题，本申请提出了一种消息故障处理方法、装置、计算设备及计算机存储介质，用于解决以下问题：现有的消息故障处理方式可能会阻塞正常的批处理，造成上游业务出现异常的问题。

根据本申请实施例的一个方面，提供了一种消息故障处理方法，包括：

获取消息发送故障的故障频率，并对生产端进行心跳检测得到心跳检测结果；

根据故障频率和心跳检测结果，确定消息发送故障对应的故障类型；

根据故障类型，执行与故障类型对应的故障处理策略，以消除消息发送故障。

进一步地，对生产端进行心跳检测得到心跳检测结果进一步包括：

通过心跳检测线程对生产端进行心跳检测，获取生产端在会话中的心跳应答结果；

根据心跳应答结果，确定心跳检测结果。

进一步地，根据心跳应答结果，确定心跳检测结果进一步包括：

若心跳应答结果为会话中包含有心跳应答信息，则确定心跳检测结果为会话正常；

若心跳应答结果为会话中未包含有心跳应答信息，则确定心跳检测结果为会话异常。

进一步地，故障类型包括：短时间故障类型和长时间故障类型；

根据故障频率和心跳检测结果，确定消息发送故障对应的故障类型进一步包括：

若故障频率小于预设频率阈值且心跳检测结果为会话正常，则确定消息发送故障对应的故障类型为短时间故障类型；

若故障频率大于或等于预设频率阈值且心跳检测结果为会话异常，则确定消息发送故障对应的故障类型为长时间故障类型。

进一步地，在确定消息发送故障对应的故障类型为短时间故障类型之后，该方法还包括：根据故障频率，确定消息发送故障所属的短时间故障类型的子类型；

根据故障类型，执行与故障类型对应的故障处理策略，以消除消息发送故障进一步包括：

若子类型为网络抖动故障子类型，则为发生消息发送故障的消息组选择处于正常工作状态的分区，向分区发送消息组；

若子类型为领导者节点选举子类型，则将发生消息发送故障的消息存储至生产端的本地缓存中，待领导者节点选取结束后，将本地缓存中存储的发生消息发送故障的消息进行重新发送。

进一步地，根据故障类型，执行与故障类型对应的故障处理策略，以消除消息发送故障进一步包括：

若故障类型为长时间故障类型，则将当前工作分区由主用主题对应的分区切换为备用主题对应的分区，使生产端使用备用主题对应的分区发送消息，消费端使用备用主题对应的分区接收消息。

进一步地，在将当前工作分区由主用主题对应的分区切换为备用主题对应的分区，使生产端使用备用主题对应的分区发送消息，消费端使用备用主题对应的分区接收消息之后，该方法还包括：

通过定时任务检测会话是否恢复正常；

若会话恢复正常，则将当前工作分区由备用主题对应的分区恢复为主用主题对应的分区，使生产端使用主用主题对应的分区发送消息，消费端使用主用主题对应的分区接收消息。

根据本申请实施例的另一方面，提供了一种消息故障处理装置，包括：

检测模块，用于获取消息发送故障的故障频率，并对生产端进行心跳检测得到心跳检测结果；

类型确定模块，用于根据故障频率和心跳检测结果，确定消息发送故障对应的故障类型；

故障处理模块，用于根据故障类型，执行与故障类型对应的故障处理策略，以消除消息发送故障。

根据本申请实施例的又一方面，提供了一种计算设备，包括：处理器、存储器、通信接口和通信总线，处理器、存储器和通信接口通过通信总线完成相互间的通信；

存储器用于存放至少一可执行指令，可执行指令使处理器执行上述消息故障处理方法对应的操作。

根据本申请实施例的再一方面，提供了一种计算机存储介质，存储介质中存储有至少一可执行指令，可执行指令使处理器执行如上述消息故障处理方法对应的操作。

根据本申请实施例提供的消息故障处理方法、装置、计算设备及计算机存储介质，针对集群的消息发送故障，为生产端增加了心跳检测机制，充分结合消息发送故障的故障频率和心跳检测结果来有效识别该消息发送故障对应的故障类型，并且，设置了故障类型与故障处理策略之间的对应关系，针对不同故障类型，通过执行不同的故障处理策略来消除消息发送故障，不仅能够在保证消息顺序的前提下提高失败消息重试成功的概率，而且实现了生产端的业务和消费端的业务对集群的故障无感知，不影响上下游业务。

上述说明仅是本申请实施例技术方案的概述，为了能够更清楚了解本申请实施例的技术手段，而可依照说明书的内容予以实施，并且为了让本申请实施例的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请实施例的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请实施例的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本申请一个实施例的消息故障处理方法的流程示意图；

图2示出了根据本申请另一个实施例的消息故障处理方法的流程示意图；

图3示出了根据本申请一个实施例的消息故障处理装置的结构框图；

图4示出了根据本申请一个实施例的一种计算设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了根据本申请一个实施例的消息故障处理方法的流程示意图，如图1所示，该方法包括如下步骤：

步骤S101，获取消息发送故障的故障频率，并对生产端进行心跳检测得到心跳检测结果。

步骤S102，根据故障频率和心跳检测结果，确定消息发送故障对应的故障类型。

步骤S103，根据故障类型，执行与故障类型对应的故障处理策略，以消除消息发送故障。

根据本申请实施例提供的消息故障处理方法，针对集群的消息发送故障，为生产端增加了心跳检测机制，充分结合消息发送故障的故障频率和心跳检测结果来有效识别该消息发送故障对应的故障类型，并且，设置了故障类型与故障处理策略之间的对应关系，针对不同故障类型，通过执行不同的故障处理策略来消除消息发送故障，不仅能够在保证消息顺序的前提下提高失败消息重试成功的概率，而且实现了生产端的业务和消费端的业务对集群的故障无感知，不影响上下游业务。

图2示出了根据本申请另一个实施例的消息故障处理方法的流程示意图，如图2所示，该方法包括如下步骤：

步骤S201，获取消息发送故障的故障频率，并对生产端进行心跳检测得到心跳检测结果。

当集群发生消息发送故障时，获取集群中消息发送故障的故障频率。以集群为kafka集群为例，kafka集群常见的故障为单节点磁盘故障、主题(topic)对应的分区(parititon)无可用的领导者节点(leader)，从而导致生产端发送消息时无法成功发送至该分区。为了能够精准地确定消息发送故障对应的故障类型，需要获取消息发送故障的故障频率。

在现有的kafka中，通常仅对消费端(consumer)设置有心跳检测机制，在本实施例中，对生产端(producer)也启用心跳检测机制，而不是使用生产端的发送失败次数来判断，有效地避免了消息发送频率不同而带来的分析不准确的问题。在本实施例中，通过结合故障频率和生产端的心跳检测结果来确定消息发送故障对应的故障类型，那么在步骤S201中还需获取生产端的心跳检测结果。

具体地，通过心跳检测线程对生产端进行心跳检测，获取生产端在会话(session)中的心跳应答结果；根据心跳应答结果，确定心跳检测结果。其中，若心跳应答结果为会话中包含有心跳应答信息，则确定心跳检测结果为会话正常；若心跳应答结果为会话中未包含有心跳应答信息，则确定心跳检测结果为会话异常。例如，固定时间发送心跳检测线程，在一个session中可以包含有多次心跳应答，如果在一个session中完成一次心跳应答，则认为连接正常，即会话正常。

步骤S202，根据故障频率和心跳检测结果，确定消息发送故障对应的故障类型。若故障类型为短时间故障类型，则执行步骤S203；若故障类型为长时间故障类型，则执行步骤S206。

在本实施例中，可以按照消息发送故障存在的时长，将故障类型划分为短时间故障类型和长时间故障类型；短时间故障类型和长时间故障类型是根据消息发送故障的持续故障时长而划分的类型。其中，若消息发送故障的持续故障时长小于预设时长，则将这类消息发送故障划分为短时间故障类型；若消息发送故障的持续故障时长大于或等于预设时长，则将这类消息发送故障划分为长时间故障类型。

具体地，短时间故障的情况可包括：

(1)某个生产端所在节点和某个分区的领导者节点之间的网络抖动严重而导致一段时间内该生产端往此分区发送消息失败；

(2)集群内单个领导者节点选举可能会造成所有生产端发送到这个分区的消息在一段时间内发送失败；

(3)集群内领导者节点由于重启累计导致的领导者节点分布不满足负载均衡的条件，通过手动或自动触发领导者节点重新分配，这种情况也可能会导致短时间内集群对外不可用。

长时间故障的情况可包括：为保证消息的可靠性并兼顾集群的性能，通常使用两个副本，然而在实际的生产环境中，由于运维巡检不到位，导致单节服务故障修复不及时，导致一个分区所在的两个副本所在的两个节点均故障，就可能会出现在很长时间内此分区无可用的领导者节点，即leader id等于-1，表示还没有成功选举出leader。

对于短时间故障情况，使用无限重试，虽然可以缓解短时间内的发送故障，但是会影响写入业务。对于长时间故障情况，运维人员如果不能及时发现和修复，会使故障保持较长的一段时间，很难在发生故障后及时修复故障。并且，使用无限重试方式，无法很好地解决问题，反而对生产业务和消费业务都可能造成很大的不利影响。

虽然单个分区无法正常使用，集群整体依然正常，如flume仅用memory通道模式向kafka中写数据的业务场景，就可能会造成flume的memory通道阻塞，进而影响上游业务，造成上游业务出现异常。

短时间故障通常只会对生产端的业务有所影响，但对消费端的业务影响并不大。长时间故障很有可能是分区所在节点都发生故障，对生产端的业务和消费端的业务都会有很大的不利影响。针对短时间故障类型和长时间故障类型，本实施例提供了不同的故障处理策略，实现了生产端的业务和消费端的业务对集群的故障无感知，不影响kafka上下游业务。

在本实施例中，通过结合故障频率和生产端的心跳检测结果来确定消息发送故障对应的故障类型。若故障频率小于预设频率阈值且心跳检测结果为会话正常，则确定消息发送故障对应的故障类型为短时间故障类型；若故障频率大于或等于预设频率阈值且心跳检测结果为会话异常，则确定消息发送故障对应的故障类型为长时间故障类型。具体地，如果会话正常，但频繁地出现发送消息失败的情况，则认为属于短时间故障类型；如果会话不正常，并且还一直出现发送消息失败的情况，则认为属于长时间故障类型。

步骤S203，根据故障频率，确定消息发送故障所属的短时间故障类型的子类型。若子类型为网络抖动故障子类型，则执行步骤S204；若子类型为领导者节点选举子类型，则执行步骤S205。

在实际场景中，还可以根据故障原因对短时间故障类型进一步划分成多个子类型，具体地，短时间故障类型包括：网络抖动故障子类型和领导者节点选举子类型。

其中，需要配置kafka的重试次数不为0，一般可将重试次数设置为3～5次，如果在重试次数内发送成功，说明是轻微的网络抖动，无需启动短时间故障类型对应的故障处理策略，避免了频繁启动短时间故障类型对应的故障处理策略。如果在重试次数内没有发送成功，说明不是轻微的网络抖动，需要启动短时间故障类型对应的故障处理策略。

如果是严重的网络抖动造成的发送失败，对应的情况是短时间内频繁间歇地发送失败，但是消费端到对应分区kafka的broker(消息代理端)的网络可能是正常的。如果是领导者节点选举导致的发送失败，对应的情况是短时间内一直发送失败，此情况下消费端也是无法正常消费的。那么可根据上述情况设置预设幅度范围，若故障频率的变化幅度符合预设幅度范围，说明在短时间内频繁间歇地发送失败，则确定消息发送故障所属的短时间故障类型的子类型为网络抖动故障子类型；若故障频率的变化幅度不符合预设幅度范围，说明在短时间内一直发送失败，则确定消息发送故障所属的短时间故障类型的子类型为领导者节点选举子类型。

步骤S204，为发生消息发送故障的消息组选择处于正常工作状态的分区，向分区发送消息组。

由于消息是按照消息组(batch)发送的，若子类型为网络抖动故障子类型，那么针对发送失败的消息组，可以采用轮询等方式选择一个发送正常的分区发送出去。而不是将消息组拆开然后使每条消息重新发送，因此不影响整体的发送吞吐。

步骤S205，将发生消息发送故障的消息存储至生产端的本地缓存中，待领导者节点选取结束后，将本地缓存中存储的发生消息发送故障的消息进行重新发送。

若子类型为领导者节点选举子类型，可以将消息暂存在第三方存储中。由于是短时间内的发送失败，不会有太多发送失败的消息。为了不添加系统的组件，在本实施例中使用生产端所在的本地磁盘作为第三方存储来暂存发送失败的消息，有效地避免了增加系统和运维的复杂度。选举完成后直到有消息发送成功，单独开启一个生产端将磁盘缓存的消息发送到对应的分区中。

针对短时间故障类型，通过采用上述两种故障处理策略，可以有效地解决单节点故障导致的集群对外服务故障。

步骤S206，将当前工作分区由主用主题对应的分区切换为备用主题对应的分区，使生产端使用备用主题对应的分区发送消息，消费端使用备用主题对应的分区接收消息。

对于长时间故障情况，运维人员如果不能及时发现和修复，会使故障保持较长的一段时间，如果仍然使用短时间故障类型对应的故障处理策略，在故障恢复后，由于之前很长一段时间内消息累积，可能会造成kafka的这个分区的数据相对偏多，即造成负载不均衡。如果kafka的下游是Spark Streaming或者Flink实时计算系统，消费kafka就会导致实时计算系统出现数据倾斜，影响整体的计算速度。

一般单节点故障导致分区不可写，也对应这分区不可读。为了提高消费的吞吐量，可设置消费端的数量等于topic分区的数量。有一个分区不可以消费，也就对应着有一个消费端消费不到数据。例如，每个消费端的吞吐是20M/s，5个分区整体吞吐就是100M/s，如果一个消费端消费不到数据，整体吞吐也就相应下降20M/s，整体吞吐也就变成了80M/s。如果使用Sender发送失败触发重试机制，发送的吞吐不会受太大影响，但是消费的吞吐有很大影响，持续一段时间很有可能造成消息挤压。

若故障类型为长时间故障类型，采用双topic分区切换机制来应对。在使用topic:topic-1开启生产后，后端自动创建一个topic:topic-1-temp作为topic-1的备用主题，topic-1-temp和topic-1的分区数相同，每个topic对应的分区所在broker都不相同，以此来保证切换后分区不会在落到故障节点。

在故障类型为长时间故障类型的情况下，生产端开启双topic分区机制，将故障分区流量迁移至备用topic对应的分区，生产端、broker、消费端都需要做对应的切换，能够保证集群分区的负载均衡，不对下游业务造成影响。具体地，将发送至topic-1(即主用主题)的分区号为n的分区的消息发送至topic-1-temp(即备用主题)的分区号为n的分区。生产端会缓存每个分区上次发送成功的offset(偏移量)。生产端通知kafka broker发送至topic-1-temp的分区号为n的分区的消息的offset，生产端缓存每个分区上次发送成功的offset为end offset(结束偏移量)。kafka broker成功收到消息后会通知对应消费端开始消费topic-1-temp的分区号为n的分区中的消息。本实施例实现了将当前工作分区由主用主题对应的分区切换为备用主题对应的分区，使生产端使用备用主题对应的分区发送消息，消费端使用备用主题对应的分区接收消息。

步骤S207，通过定时任务检测会话是否恢复正常；若是，则执行步骤S208；若否，则继续执行步骤S207。

步骤S208，将当前工作分区由备用主题对应的分区恢复为主用主题对应的分区，使生产端使用主用主题对应的分区发送消息，消费端使用主用主题对应的分区接收消息。

在双topic分区切换机制后，kafka broker开启一个定时线程，每隔固定时间测一次topic-1的分区号为n的分区是否可以正常使用。如果检测到故障分区可以正常使用，则从topic-1-temp的分区号为n的分区中同步数据，同步完成后通知生产端和消费端切换至topic-1的分区号为n的分区进行生产和消费。对于后续来消费主用主题的消费端无感知。

根据本申请实施例提供的消息故障处理方法，针对集群的消息发送故障，为生产端增加了心跳检测机制，有效地避免了消息发送频率不同而带来的分析不准确的问题；充分结合消息发送故障的故障频率和心跳检测结果来有效识别该消息发送故障对应的故障类型，设置了故障类型与故障处理策略之间的对应关系，针对不同故障类型，通过执行不同的故障处理策略来消除消息发送故障，并且还将短时间故障类型进一步细分为网络抖动故障子类型和领导者节点选举子类型，针对不同的短时间故障子类型执行不同的故障处理策略，有效地解决了单节点故障导致的集群对外服务故障；该方案不仅能够在保证消息顺序的前提下提高失败消息重试成功的概率，而且实现了生产端的业务和消费端的业务对集群的故障无感知，不影响上下游业务。

图3示出了根据本申请一个实施例的消息故障处理装置的结构框图，如图3所示，该装置包括：检测模块310、类型确定模块320以及故障处理模块330。

检测模块310用于：获取消息发送故障的故障频率，并对生产端进行心跳检测得到心跳检测结果。

类型确定模块320用于：根据故障频率和心跳检测结果，确定消息发送故障对应的故障类型。

故障处理模块330用于：根据故障类型，执行与故障类型对应的故障处理策略，以消除消息发送故障。

可选地，检测模块310进一步用于：通过心跳检测线程对生产端进行心跳检测，获取生产端在会话中的心跳应答结果；根据心跳应答结果，确定心跳检测结果。

可选地，检测模块310进一步用于：若心跳应答结果为会话中包含有心跳应答信息，则确定心跳检测结果为会话正常；若心跳应答结果为会话中未包含有心跳应答信息，则确定心跳检测结果为会话异常。

可选地，故障类型包括：短时间故障类型和长时间故障类型。类型确定模块320进一步用于：若故障频率小于预设频率阈值且心跳检测结果为会话正常，则确定消息发送故障对应的故障类型为短时间故障类型；若故障频率大于或等于预设频率阈值且心跳检测结果为会话异常，则确定消息发送故障对应的故障类型为长时间故障类型。

可选地，类型确定模块320进一步用于：根据故障频率，确定消息发送故障所属的短时间故障类型的子类型。可选地，故障处理模块330进一步用于：若子类型为网络抖动故障子类型，则为发生消息发送故障的消息组选择处于正常工作状态的分区，向分区发送消息组；若子类型为领导者节点选举子类型，则将发生消息发送故障的消息存储至生产端的本地缓存中，待领导者节点选取结束后，将本地缓存中存储的发生消息发送故障的消息进行重新发送。

可选地，故障处理模块330进一步用于：若故障类型为长时间故障类型，则将当前工作分区由主用主题对应的分区切换为备用主题对应的分区，使生产端使用备用主题对应的分区发送消息，消费端使用备用主题对应的分区接收消息。

可选地，故障处理模块330进一步用于：通过定时任务检测会话是否恢复正常；若会话恢复正常，则将当前工作分区由备用主题对应的分区恢复为主用主题对应的分区，使生产端使用主用主题对应的分区发送消息，消费端使用主用主题对应的分区接收消息。

以上各模块的描述参照方法实施例中对应的描述，在此不再赘述。

根据本申请实施例提供的消息故障处理装置，针对集群的消息发送故障，为生产端增加了心跳检测机制，有效地避免了消息发送频率不同而带来的分析不准确的问题；充分结合消息发送故障的故障频率和心跳检测结果来有效识别该消息发送故障对应的故障类型，设置了故障类型与故障处理策略之间的对应关系，针对不同故障类型，通过执行不同的故障处理策略来消除消息发送故障，并且还将短时间故障类型进一步细分为网络抖动故障子类型和领导者节点选举子类型，针对不同的短时间故障子类型执行不同的故障处理策略，有效地解决了单节点故障导致的集群对外服务故障；该方案不仅能够在保证消息顺序的前提下提高失败消息重试成功的概率，而且实现了生产端的业务和消费端的业务对集群的故障无感知，不影响上下游业务。

本申请实施例还提供了一种非易失性计算机存储介质，计算机存储介质存储有至少一可执行指令，可执行指令可执行上述任意方法实施例中的消息故障处理方法。

图4示出了根据本申请实施例的一种计算设备的结构示意图，本申请实施例的具体实施例并不对计算设备的具体实现做限定。

如图4所示，该计算设备可以包括：处理器(processor)402、通信接口(Communications Interface)404、存储器(memory)406、以及通信总线408。

其中：

处理器402、通信接口404、以及存储器406通过通信总线408完成相互间的通信。

通信接口404，用于与其它设备比如客户端或其它服务器等的网元通信。

处理器402，用于执行程序410，具体可以执行上述消息故障处理方法实施例中的相关步骤。

具体地，程序410可以包括程序代码，该程序代码包括计算机操作指令。

处理器402可能是中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。计算设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器406，用于存放程序410。存储器406可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序410具体可以用于使得处理器402执行上述任意方法实施例中的消息故障处理方法。程序410中各步骤的具体实现可以参见上述消息故障处理实施例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本申请实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请实施例的内容，并且上面对特定语言所做的描述是为了披露本申请实施例的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本申请实施例的示例性实施例的描述中，本申请实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请实施例要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请实施例的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请实施例的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本申请实施例的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本申请实施例中的一些或者全部部件的一些或者全部功能。本申请实施例还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请实施例的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本申请实施例进行说明而不是对本申请实施例进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请实施例可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (10)

1.一种消息故障处理方法，其特征在于，包括：

获取消息发送故障的故障频率，并对生产端进行心跳检测得到心跳检测结果；

根据所述故障频率和所述心跳检测结果，确定所述消息发送故障对应的故障类型；

根据所述故障类型，执行与所述故障类型对应的故障处理策略，以消除所述消息发送故障。

2.根据权利要求1所述的方法，其特征在于，所述对生产端进行心跳检测得到心跳检测结果进一步包括：

通过心跳检测线程对所述生产端进行心跳检测，获取所述生产端在会话中的心跳应答结果；

根据所述心跳应答结果，确定所述心跳检测结果。

3.根据权利要求2所述的方法，其特征在于，所述根据所述心跳应答结果，确定所述心跳检测结果进一步包括：

若所述心跳应答结果为所述会话中包含有心跳应答信息，则确定所述心跳检测结果为会话正常；

若所述心跳应答结果为所述会话中未包含有心跳应答信息，则确定所述心跳检测结果为会话异常。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述故障类型包括：短时间故障类型和长时间故障类型；

所述根据所述故障频率和所述心跳检测结果，确定所述消息发送故障对应的故障类型进一步包括：

若所述故障频率小于预设频率阈值且所述心跳检测结果为会话正常，则确定所述消息发送故障对应的故障类型为短时间故障类型；

若所述故障频率大于或等于预设频率阈值且所述心跳检测结果为会话异常，则确定所述消息发送故障对应的故障类型为长时间故障类型。

5.根据权利要求4所述的方法，其特征在于，在所述确定所述消息发送故障对应的故障类型为短时间故障类型之后，所述方法还包括：根据所述故障频率，确定所述消息发送故障所属的短时间故障类型的子类型；

所述根据所述故障类型，执行与所述故障类型对应的故障处理策略，以消除所述消息发送故障进一步包括：

若所述子类型为网络抖动故障子类型，则为发生所述消息发送故障的消息组选择处于正常工作状态的分区，向所述分区发送所述消息组；

若所述子类型为领导者节点选举子类型，则将发生所述消息发送故障的消息存储至所述生产端的本地缓存中，待领导者节点选取结束后，将所述本地缓存中存储的发生所述消息发送故障的消息进行重新发送。

6.根据权利要求4所述的方法，其特征在于，所述根据所述故障类型，执行与所述故障类型对应的故障处理策略，以消除所述消息发送故障进一步包括：

若所述故障类型为长时间故障类型，则将当前工作分区由主用主题对应的分区切换为备用主题对应的分区，使所述生产端使用所述备用主题对应的分区发送消息，消费端使用备用主题对应的分区接收消息。

7.根据权利要求6所述的方法，其特征在于，在所述将当前工作分区由主用主题对应的分区切换为备用主题对应的分区，使所述生产端使用所述备用主题对应的分区发送消息，消费端使用备用主题对应的分区接收消息之后，所述方法还包括：

通过定时任务检测会话是否恢复正常；

若会话恢复正常，则将所述当前工作分区由备用主题对应的分区恢复为主用主题对应的分区，使所述生产端使用所述主用主题对应的分区发送消息，消费端使用主用主题对应的分区接收消息。

8.一种消息故障处理装置，其特征在于，包括：

检测模块，用于获取消息发送故障的故障频率，并对生产端进行心跳检测得到心跳检测结果；

类型确定模块，用于根据所述故障频率和所述心跳检测结果，确定所述消息发送故障对应的故障类型；

故障处理模块，用于根据所述故障类型，执行与所述故障类型对应的故障处理策略，以消除所述消息发送故障。

9.一种计算设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-7中任一项所述的消息故障处理方法对应的操作。

10.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求1-7中任一项所述的消息故障处理方法对应的操作。

Images