CN112256454B - 消息延时处理方法和系统 - Google Patents

Abstract

本申请提供了一种消息延时处理方法，所述方法包括：向服务器集群中的多个分区发送多个消息；获取所述服务器集群的消息发送情况，所述消息发送情况包括各个分区的响应延时情况；及当所述多个分区中的目标分区的响应延时情况符合熔断条件，则对所述目标分区进行熔断。在本申请中，可以根据各个分区的响应延时情况，主动地对不符合要的分区进行熔断操作，避免后续延时问题。

Description

消息延时处理方法和系统

技术领域

本申请实施例涉及计算机技术领域，尤其涉及一种消息延时处理方法、系统、计算机设备及计算机可读存储介质。

背景技术

当前的流式消息延时处理系统一般由消息延时处理层(如网关)、数据缓冲层、数据分发层(controller)和数据存储终端构成。当数据源有数据上报时，所述数据源会将上报数据经由消息延时处理层、所述数据缓冲层、所述数据分发层最终流入到所述数据存储终端。

随着用户数量的急速增长，数据量也随之急速增长。例如，每天可能产生PB级别的数据量，数据缓冲层为处理这些消息，可能需要上千台服务器，上万个Topic(主题)。在现有技术中，将大量数据发送到数据缓冲层过程中，可能会产生较为严重的延时，尤其在数据缓冲层处于高负载状态时。上述延时会导致数据发送效率低下。

发明内容

本申请实施例的目的是提供一种消息延时处理方法、系统、计算机设备及计算机可读存储介质，可以用于解决以下问题：延时导致的数据发送效率低下的问题。

本申请实施例的一个方面提供了一种消息延时处理方法，所述方法包括：向服务器集群中的多个分区发送多个消息；获取所述服务器集群的消息发送情况，所述消息发送情况包括各个分区的响应延时情况；及当所述多个分区中的目标分区的响应延时情况符合熔断条件，则对所述目标分区进行熔断。

可选的，获取所述服务器集群的消息发送情况，包括：基于时间滑动窗口的方式，获取当前时间窗口内所述服务器集群的所述消息发送情况。

可选的，所述消息发送情况包括：在所述当前时间窗口内是否存在响应时间超过第一阈值的一个或多个超时消息；所述方法还包括：当在所述当前时间窗口内存在所述一个或多个超时消息，则将所述一个或多个超时消息中的至少部分超时消息重新发送到所述服务器集群中的其他分区中；其中，所述其他分区与各个超时消息的原发送分区是不同的分区。

可选的，所述至少部分超时消息的数量在第一预定范围之内；或所述至少部分超时消息的数量和消息总数量之比在第二预定范围之内，所述消息总数量是指在所述当前时间窗口内发送给所述服务器集群的消息的总数量。

可选的，所述响应延时情况包括：在所述当前时间窗口内，所述服务器集群中的各个分区的延时比例；当所述多个分区中的目标分区的响应延时情况符合熔断条件，则对所述目标分区进行熔断：将延时比例高于第二阈值的分区作为所述目标分区，并对所述目标分区进行熔断以暂停消息发送。

可选的，所述延时比例为第一消息数量和第二消息数量之比；所述第一消息数量为：在所述当前时间窗口内，被发送到所述相应分区且响应时间超过第三阈值的消息的数量；所述第二消息数量为：在所述当前时间窗口内，被发送到所述相应分区的消息的总数量。

可选的，还包括以预设频率获取所述第三阈值：实时获取所述服务器集群的响应延时分位线；及计算所述响应延时分位线和预设容忍因子之乘积，将乘积结果设定为所述第三阈值。

可选的，当所述目标分区处于熔断状态时，所述方法还包括：S1：将其中一批次消息作为当前批次消息发送给所述目标分区，基于这批次消息的发送成功率判断是否发送下一批次消息，这批次消息的初始数据为第一批次消息；S2：当这批次消息的发送成功率达标，则将所述下一批次消息作为所述当前批次消息并重复执行S1；所述下一批次消息的消息数量大于所这批次消息的消息数量；S3：当这批次消息的发送成功率不达标，则间隔预定时间将所述下一批次消息作为所述当前批次消息并重复执行S1；所述下一批次消息的消息数量等于所述第一批次消息的消息数量；循环执行上述操作以逐步恢复向所述目标分区发送消息，直至所述当前批次消息的数量大于或等于预定数量。

可选的，还包括：获取分布式服务协调组件提供的分区黑名单，所述分区黑名单包括所述服务器集群中的多个不可写入分区；及根据所述分区黑名单确定所述多个分区，所述多个分区为所述服务器集群中除所述多个不可写入分区之外的至少部分分区。

可选的，所述分区黑名单是由所述服务器集群根据所述各个分区的实时情况生成并上报给所述分布式服务协调组件的。

可选的，所述消息发送情况还包括将消息发送到所述服务器集群的消息发送成功率，所述方法还包括：根据所述消息发送成功率，动态确定切换比例；及根据所述切换比例，切换待发送到所述服务器集群的多个待发送消息中的部分消息的发送地，以将该部分消息的发送地由所述服务器集群切换到到其他服务器集群。

本申请实施例的再一个方面提供了一种消息延时处理系统，所述系统包括：发送模块，用于向服务器集群中的多个分区发送多个消息；获取模块，用于获取所述服务器集群的消息发送情况，所述消息发送情况包括各个分区的响应延时情况；及处理模块，用于当所述多个分区中的目标分区的响应延时情况符合熔断条件，则对所述目标分区进行熔断。

本申请实施例的再一个方面提供了一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，上述处理器执行上述计算机程序时用于实现如上任一项所述的消息延时处理方法的步骤。

本申请实施例的又一个方面提供了一种计算机可读存储介质，其上存储有计算机程序，上述计算机程序被处理器执行时用于实现如上任一项所述的消息延时处理方法的步骤。

本申请实施例提供的消息延时处理方法、系统、计算机设备及计算机可读存储介质具有以下优势：可以实时地获取服务器集群中的各个分区的响应延时情况，根据各个分区的响应延时情况，主动地对不符合要的分区进行熔断操作，避免后续延时问题。

附图说明

图1示意性示出了流式数据传输链路的链路图；

图2示意性示出了根据本申请实施例一的流式数据分发系统的环境示意图；

图3示意性示根据本申请实施例一的消息延时处理方法的流程图；

图4示意性示根据本申请实施例二的消息延时处理方法的流程图；

图5为图4中步骤S404的子流程图；

图6～10示意性示出了根据本申请实施例二的消息延时处理方法的新增流程图；

图11示意性示出了根据本申请实施例三的消息延时处理系统的框图；以及

图12示意性示出了根据本申请实施例四的适于实现消息延时处理方法的计算机设备的硬件架构示意图。

具体实施方式

为了使本申请实施例的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

下文将提供多个实施例，下文提供的各个实施例可以用于实现本申请。在本申请的描述中，需要理解的是，步骤前的数字标号并不标识执行步骤的前后顺序，仅用于方便描述本申请及区别每一步骤，因此不能理解为对本申请的限制。

以下为本申请涉及到的术语解释：

流标识(LogId)，可以通过三段式语义(如，部门+项目+业务)进行定义，以便可以快速锁定数据所属的范畴，同时，所述流标识还可以定义有其他附属信息，如，创建者信息等。数据流可以定义有schema(数据库的组织与结构)，如字段、类型、必填与否等信息。schema可以用于所述数据流的分析和评估操作。根据定义的schema，所述数据流的元数据信息中可以被发送相应的字段值，如业务场景等，不同业务场景可以配置不同的SLA(Service-Level Agreement，服务等级协议)质量保障。需要说明的是，这些字段值可以被用户或管理发送和修改的。

Topic(主题)，将消息分类，每一类的消息称之为一个主题(Topic)。通过Topic可以对同一类的数据进行管理。同一类的数据使用同一个Topic可以在处理数据时更加高效。

Producer，发布消息的对象称之为主题生产者(Kafka topic producer)。

Consumer，订阅消息并处理发布的消息的对象称之为主题消费者(consumers)。

服务器集群，包括多个服务器，用于存储大量消息。集群中的每个服务器为一个代理(Broker)。消费者可以订阅一个或多个主题，从Broker拉数据，并消费这些消息。

Partition(分区)，为Topic物理上的分组。一个Topic通常可以分为多个partion，每个partion是一个有序的队列。partion中每条消息都会被分配一个有序的标识。Producer在向服务器集群发送消息时，可以发送到指定的分区中，也可以通过指定均衡策略来将消息发送到不同的分区中，或将消息随机的发送到不同的分区中。

ioutil，为发出I/O请求所用的时间占总时间的百分比，用于表示磁盘等的繁忙程度。

Lag，为消息堆积量。Partition所留存的消息与消费掉的消息之间的差值即为消息堆积量。

avg lag，Partition的消息堆积量的平均值。

抖动(延时)，写入到服务器集群中的不同消息的响应时间，有些消息的响应时间存在延时(抖动)。

图1示意性示出了根据本申请实施例的流式数据传输链路，所述的流式数据传输链路在于提供流式的消息延时处理服务，如用于实时流和离线流两大场景的数据收集和分发。实时流场景，对应于秒级别的数据时效性，主要用于将数据发送到kafka、hbase等数据库中。离线流场景，对应于小时级别或天级别的数据时效性，主要用于将数据发送到HDFS、hive等数据库中。所述流式消息延时处理系统可以由下几部分组成：数据源1、网络路由层2、数据缓冲层3、数据分发层4、数据存储层5等。

所述数据源1可以是内部数据源，也可以连接外部数据源的数据接口。所述数据源1中可以有多种格式的数据，例如，APP和Web的上报数据是HTTP(HyperText TransferProtocol，超文本传输协议)格式的数据，服务端的内部通信数据是RPC(Remote ProcedureCall，远程过程调用)格式的数据。如图1所示，所述数据源1的数据可以是通过一个或多个边缘节点接收的移动终端上报的日志数据等，也可以是数据库、数据协同系统、日志代理等各个系统或设备提供的数据。

所述网络路由层2，可以通过一个或多个网关节点实现，用于将数据源1提供的数据转发到数据缓冲层3。所述网络路由层2被配置连接于数据源1，并可以适应各种不同的业务场景和数据协议，例如，被配置用于兼容解析HTTP(HyperText Transfer Protocol，超文本传输协议)协议的APP和Web数据，和GRPC协议的内部通信数据。

所述数据缓冲层3，可以通过消息分发订阅系统或上述系统集群实现。在一些实施例中，数据缓冲层3可以由多套kafka cluster(kafka集群)组成，起到数据削峰填谷的作用。不同重要性、优先级、数据吞吐量的数据，可以被分流到不同的kafka cluster中，以保障不同类型数据的价值，避免系统故障影响整体数据。所述数据缓冲层3的数据可以是网络路由层2提供的数据，亦可以是数据源1直接提供的数据

所述数据分发层4，可以由流式数据分发系统(由多个流量分发节点Collector构成)实现，用于内容转换和分发存储，即保障数据从数据缓冲层3获取并发送到数据存储层5中对应的存储终端。具体的，所述数据分发层4用于数据的分发落地，支持的分发场景包括HDFS(Hadoop Distributed File System，Hadoop分布式文件系统)、Kafka、Hbase、ES(Elasticsearch)等，而在分发的过程中，由于不同存储终端的数据落地时效性要求可能不同，例如，HDFS的数据发送是按天进行任务的计算和应用，Kafka的数据发送一般是按秒进行任务的计算和应用，通常用于诸如实时推荐、实时计算等场景中。针对数据不同场景的分发要求，数据分发层4可以根据存储终端进行服务分组管理。例如，线上会划分为KafkaCollector组、HDFS Collector组等。不同Collector组会从数据缓冲层3获取相应主题(topic)的数据并分发至下游。

所述数据存储层5，用于存储数据，可以由不同形式的数据库构成，所述数据库可以是HDFS、ES、Hive、Kafka和Hbase等。

即，所述流式数据传输链路的数据流向如下：数据源1→网络路由层2→数据缓冲层3→数据分发层4→数据存储层5。通过所述流式数据传输链路，数据源中的数据可以被传输到目标终端。具体如下：数据源可以输出以LogId为流标识的数据流，通过HTTP、RPC等协议将这些数据上报给边缘节点，并依次经过网关路由层2、数据缓冲层3、数据分发层4，并最终进入到数据存储层5中的存储终端中。

在将数据发送到数据缓冲层3的过程中，由于机器负载高、机器故障或日常抖动等因素，可能会产生不可预估的响应延时(即，抖动)。现有的数据发送逻辑为：(1)数据缓冲层3在每条消息发送成功并返回响应之后，再发送下一条消息；(2)数据缓冲层3在每批消息发送成功并返回响应之后，再发送下一批消息。当极少数消息响应延时，则会导致下一条或下一批消息一直处于等待中，受长尾效应严重影响，极大降低发送效率。本申请旨在出现响应延时时，如何保证数据发送效率。

实施例一

图2示意性示出了本申请的消息延时处理方法的运行环境图，其可以具有如下组合部分：

客户端30，为运行在服务器中的应用程序，用于将数据源1中的消息发送到服务器集群。所述消息延时处理方法，可以以代码形式作为该客户端30的一部分或插件。可知，本实施例所述的消息延时处理方法的执行主体为运行所述客户端30的设备。

服务器集群31，如Kafka集群，用于存储消息。

其他服务器集群32，为与服务器集群31不同的集群，可以为服务器集群31的备用集群。

集群管理组件，如Kafka guradian，可以收集服务器集群的运行信息等。

分布式服务协调组件，如Zookeeper，用于分布式架构的消息传递等业务。

图3示意性示出了根据本申请实施例一的消息处理方法的流程图。

如图3所示，该消息延时处理方法可以包括步骤S300～步骤S304，其中：

步骤S300，向服务器集群31中的多个分区发送多个消息。

客户端30可以根据各个消息的属性、标识等，将各个消息发送到相应Topic下的其中一个分区中。所述多个消息，可能被发送到所述服务器集群31中的一个或多个分区中。

客户端30在发送所述多个消息时，可能是逐个发送，也可能是逐批发送。以客户端30逐批发送消息给分区A为例，客户端30每批1000个消息发送到分区A中。

步骤S302，获取所述服务器集群的消息发送情况，所述消息发送情况包括各个分区的响应延时情况。

服务器集群31中的某个或某些分区，可能产生响应延时，尤其在机器故障或高负载情形下。

以集群服务器31和分区A为例，所述消息发送情况可以包括多种，诸如：

情况1：服务器集群31和分区A均正常；

情况2：服务器集群31正常，但是分区A出现较为严重的响应延时；

情况3：服务器集群31和分区A均出现较为严重的响应延时。

步骤S304，当所述多个分区中的目标分区的响应延时情况符合熔断条件，则对所述目标分区进行熔断。

作为示例，当出现情况2或3时，可以对所述目标分区(如，分区A)进行熔断。

所述熔断条件，可以被预先设置或动态调整，如可以为用于表示响应延时程度的容忍范围。

所述熔断，用于限制客户端30的消息发送，例如，客户端30暂停向分区A发送消息。

本申请实施例一所述的消息延时处理方法，具有以下优势：可以实时地获取服务器集群中的各个分区的响应延时情况，根据各个分区的响应延时情况，主动地对不符合要的分区进行熔断操作，以将后续消息转存到其他分区中，避免延时问题。

实施例二

图4示意性示出了根据本申请实施例二的消息处理方法的流程图。

如图4所示，该消息延时处理方法可以包括步骤S400～步骤S404，其中：

步骤S400，向服务器集群中的多个分区发送多个消息。

客户端30可以根据各个消息的属性、标识等，将各个消息发送到相应Topic下的其中一个分区中。所述多个消息，可能被发送到所述服务器集群31中的一个或多个分区中。

客户端30在发送所述多个消息时，可能是逐个发送，也可能是逐批发送。以客户端30逐批发送消息给分区A为例，客户端30每批1000个消息发送到分区A中。

步骤S402，基于时间滑动窗口的方式，获取当前时间窗口内所述服务器集群的所述消息发送情况，所述消息发送情况包括所述多个分区中的各个分区的响应延时情况。

基于时间滑动窗口的方式，可以更加高效和精细地获取所述消息发送情况。

服务器集群31中的某个或某些分区，可能产生响应延时，尤其在机器故障或高负载情形下。

以集群服务器31和分区A为例，所述消息发送情况可以包括多种，诸如：

情况1：服务器集群31和分区A均正常；

情况2：服务器集群31正常，但是分区A出现较为严重的响应延时；

情况3：服务器集群31和分区A均出现较为严重的响应延时。

步骤S404，当所述多个分区中的目标分区的响应延时情况符合熔断条件，则对所述目标分区进行熔断。

作为示例，当出现情况2或3时，可以对所述目标分区(如，分区A)进行熔断。

客户端级别动态治理机制-熔断示例：

作为示例，所述响应延时情况，可以包括：在所述当前时间窗口内，服务器集群31中的各个分区的延时比例。如图5所示，所述步骤S404可以包括步骤S500：将延时比例高于第二阈值的分区作为所述目标分区，并对所述目标分区进行熔断以暂停消息发送。在本实施例中，将第二阈值作为触发熔断机制的熔断条件。

作为示例，所述延时比例为第一消息数量和第二消息数量之比；所述第一消息数量为：在所述当前时间窗口内，被发送到所述相应分区且响应时间超过第三阈值的消息的数量；所述第二消息数量为：在所述当前时间窗口内，被发送到所述相应分区的消息的总数量。例如，在2020年10月28日AM 9:00～AM9:05期间，客户端30向某个分区(如分区A)发送了10000个消息，其中有91000个消息的响应时间超过1秒(第三阈值)，则在该当前时间窗口(即，2020年10月28日AM 9:00～AM 9:05期间)，分区A的延时比例为0.91，即：91000/10000＝0.91。

需要说明是，第三阈值可以预先设定的，也可以是动态调整的。以动态调整为例：如图6所示，所述消息延时处理方法还包括以预设频率获取所述第三阈值，具体包括步骤S600～S602。其中，步骤S600，实时获取服务器集群31的响应延时分位线；步骤S602，计算所述响应延时分位线和预设容忍因子之乘积，将乘积结果设定为所述第三阈值。

所述响应延时分位线，又可以称之为TP(Top Percentile)线。示例性的，所述响应延时分位线可以为90线。以90线为例，假设在2020年10月28日AM 8:55～AM 9:00期间，分区A对应有10000个响应时间，从小到大排序之后，第9000个响应时间的值就是这组响应时间的TP95值，表示至少有90％的数字是小于或者等于这个值。在2020年10月28日AM 9:00～AM9:05期间，客户端30可以将在2020年10月28日AM 8:55～AM 9:00期间产生的90线为评价分区A的响应延时分位线。由于响应延时分位线是根据实时情况动态变化的，因此，所述第三阈值亦是根据实时情况动态变化的。另外，所述预设容忍因子可以为1.2～1.3之间的取值。

客户端级别动态治理机制-分区切换(Failover)示例：

在示例性的实施例中，所述消息发送情况，可以包括：在所述当前时间窗口内是否存在响应时间超过第一阈值的一个或多个超时消息。如图7所示，所述消息延时处理方法还包括步骤S700：当在所述当前时间窗口内存在所述一个或多个超时消息，则将所述一个或多个超时消息中的至少部分超时消息重新发送到所述服务器集群中的其他分区中；其中，所述其他分区与各个超时消息的原发送分区是不同的分区。作为示例，所述至少部分超时消息的数量在第一预定范围之内；或所述至少部分超时消息的数量和消息总数量之比在第二预定范围之内，所述消息总数量是指在所述当前时间窗口内发送给所述服务器集群的消息的总数量。

以分区A为例：客户端30将10000个消息发送到分区A中，并监测有响应超时的10个消息(下称，超时消息)。此时有两种方案：(1)继续等待，直至接收到所有消息的响应，再发送下一批消息(此为申请人了解的先前做法)；(2)将该10个响应超时的消息重复发送的其他分区中。在本实施例中，采用了方案(2)，从而可以快速将10个响应超时的消息写入到服务器集群31中，并快速地安排下一批消息的发送。

申请人发现，上述方案(2)仍有改进空间。上述方案(2)有如下问题：客户端30仍然要等待“将该10个响应超时的消息重复发送的其他分区中”的额外时间。在本实施例中，为了尽量避免该额外时间，可以通过第一预定范围或第二预定范围控制重复发送超时消息的数量。以第二预定范围为例，可以将所述第二预定范围的上限设置为0.01％。例如，如果这10000个消息中有10超时消息，但只能有1个超时消息被重新发送到服务器集群31中的其他分区，其他9个超时消息不能被重复发送服务器集群31中的其他分区，而被发送到其他服务器集群32中。

通过上述做法，可以将额外时间压缩到无限趋近于0。

在示例性的实施例中，所述第二预定范围可以设置为0，即不允许超时消息重发。

集群切换(Failover)示例：

在示例性的实施例中，所述消息发送情况还包括将消息发送到服务器集群31的消息发送成功率。如图8所示，所述消息延时处理方法还包括步骤S800～步骤S802。其中，步骤S800：根据所述消息发送成功率，动态确定切换比例；步骤S802，根据所述切换比例，切换待发送到所述服务器集群的多个待发送消息中的部分消息的发送地，以将该部分消息的发送地由所述服务器集群切换到到其他服务器集群。

所述多个待发送消息可以是从未发送给服务器集群31的消息，也可以是从未发送给服务器集群31的消息以及已经发送给服务器集群但发送失败(超时)的消息。

消息发送到服务器集群31的消息发送成功率和切换比例之间可以具有映射关系。例如，将消息发送到服务器集群31的消息发送成功率为50％，则将切换比例确定为80％。当将消息发送到服务器集群31的消息发送成功率为50％，说明服务器集群31处于不稳定(高延时)状态，因此需要降低服务器集群31的数据压力，将准备给服务器集群31的多个待发送消息的80％分流到其他服务器集群32中。

分区黑名单示例：

如图9所示，所述消息延时处理方法还包括步骤S900～步骤S902。其中，步骤S900，获取分布式服务协调组件提供的分区黑名单，所述分区黑名单包括所述服务器集群中的多个不可写入分区；步骤S902，根据所述分区黑名单确定所述多个分区，所述多个分区为所述服务器集群中除所述多个不可写入分区之外的至少部分分区。所述分区黑名单是由所述服务器集群31根据所述各个分区的实时情况生成并上报给所述分布式服务协调组件(如，Zookeeper)的。通过实时或定时更新的分区黑名单，协助客户端30及时避免将消息发送给有问题的分区，确保写入效率。

其中，所述分区黑名单的分区黑名单规则是可以通过人工配置的。作为示例，所述分区黑名单规则可以设置以下条件：ioutil＞70％，lag＞10M且该avg lag大于预设值。

客户端级别动态治理机制-恢复示例：

当所述目标分区处于熔断状态时，如图10所示，所述消息延时处理方法还包括以下恢复过程。

S1000：将其中一批次消息作为当前批次消息发送给所述目标分区，基于这批次消息的发送成功率判断是否发送下一批次消息，这批次消息的初始数据为第一批次消息；

S1002：判断这批次消息的发送成功率是否达标；

S1004：当这批次消息的发送成功率达标，则将所述下一批次消息作为所述当前批次消息并重复执行S1000；所述下一批次消息的消息数量大于所这批次消息的消息数量；

S1006：当这批次消息的发送成功率不达标，则间隔预定时间将所述下一批次消息作为所述当前批次消息并重复执行S1000；所述下一批次消息的消息数量等于所述第一批次消息的消息数量；

循环执行上述操作S1000至S1006直至以逐步恢复向所述目标分区发送消息，直至所述当前批次消息的数量大于或等于预定数量。所述预定数量可以是客户端30在所述目标分区处于非熔断状态时预计每次要发送的消息的数量，也意味着自动解除了对所述目标分区的熔断设定。

以分区A为例，当分区A处于熔断状态之后，对该分区A可能有多种处理方式，例如以下几种处理方式：(1)等待分区A恢复正常之后，由服务器集群31或Zookeeper通知客户端30，恢复向分区A发送消息；(2)间隔预定时间之后，客户端30自动恢复向分区A发送消息。但是以上两种方式均存在一种的问题：方式(1)，需要服务器集群31自己的检测和Zookeeper的消息通知，即需要其他组件或设备的额外协助，效率慢。方式(2)，不一定能保证间隔预定时间后，分区A恢复正常。

为此，本实施例提出了客户端级别动态治理方案，客户端30在不需要额外协助的情况下，通过逐步试探的方式，自行评估和确定是否要恢复向分区A发送消息。

例如，在分区A处于熔断状态之后，客户端30做如下操作：

(1)向分区A发送5个消息(第一批消息)，并判断第一批消息的发送成功率(延时比例)是否达标；

(2)如果第一批消息的发送成功率(延时比例)达标，则向分区A发送10个消息(第二批消息)，并判断第二批消息的发送成功率(延时比例)是否达标。如果第一批消息的发送成功率(延时比例)不达标，则间隔预定时间回到步骤(1)。

(3)如果第二批消息的发送成功率(延时比例)达标，则向分区A发送20个消息(第三批消息)，并判断第三批消息的发送成功率(延时比例)是否达标。如果第二批消息的发送成功率(延时比例)达标，则间隔预定时间回到步骤(1)。

(4)如果第三批消息的发送成功率(延时比例)达标，则向分区A发送40个消息(第四批消息)，并判断第四批消息的发送成功率(延时比例)是否达标。如果第三批消息的发送成功率(延时比例)达标，则间隔预定时间回到步骤(1)。

依次类推，直到发送预设数据量的消息且发送成功率(延时比例)达标，则将分区A恢复为非熔断状态。

本申请实施例二所述的消息延时处理方法，具有以下优势：

第一、熔断机制。可以实时地获取服务器集群中的各个分区的响应延时情况，根据各个分区的响应延时情况，主动地对不符合要的分区进行熔断操作，避免延时问题。

第二、分区切换机制。可以及时将超时消息重发到进服务器集群的其他分区中，以及时存储该超时消息，避免因这个(些)超时消息导致迟迟不能发送下一批消息。

例如，当客户端30发送1000个消息时，如果其中999个消息均在1秒钟之内发送完毕，1个消息出现响应延迟，需要3秒发送完毕，则意味着下一批消息的发送需要等待3秒中，极大的降低了数据吞吐速度。在本实施例中，将这个响应延迟的1个消息重发到其他分区，则可以缩短这个消息的响应时间，从而意味着下一批消息的发送需要等待时间减少，从而极大的降低了数据吞吐速度。

第三、集群切换机制。当发送给服务器集群31的消息的发送成功率不高时，及时切换到其他服务器集群。基于动态的切换比例进行切换，提高消息发送效率和设备利用率。

第四、分区黑名单机制。客户端30可以通过实时或定时更新的分区黑名单，及时避免将消息发送给有问题的分区，确保写入效率。

第五、客户端级别的恢复机制。客户端30可以在不需要额外协助的情况下，通过逐步试探的方式，自行评估和确定是否要恢复向处于熔断状态的分区发送消息。

实施例三

图11示出了根据本申请实施例三的消息延时处理系统的框图，该消息延时处理系统可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例中各程序模块的功能。如图11所示，所述消息延时处理系统1100可以包括以下组成部分：

发送模块1110，用于向服务器集群中的多个分区发送多个消息；

获取模块1120，用于获取所述服务器集群的消息发送情况，所述消息发送情况包括各个分区的响应延时情况；及

处理模块1130，用于当所述多个分区中的目标分区的响应延时情况符合熔断条件，则对所述目标分区进行熔断。

在示例性的实施例中，发送模块1110，还用于：基于时间滑动窗口的方式，获取当前时间窗口内所述服务器集群的所述消息发送情况。

在示例性的实施例中，所述消息发送情况包括：在所述当前时间窗口内是否存在响应时间超过第一阈值的一个或多个超时消息。所述消息延时处理系统1100可以包括重发模块(未图示)，用于：当在所述当前时间窗口内存在所述一个或多个超时消息，则将所述一个或多个超时消息中的至少部分超时消息重新发送到所述服务器集群中的其他分区中；其中，所述其他分区与各个超时消息的原发送分区是不同的分区。

在示例性的实施例中，所述至少部分超时消息的数量在第一预定范围之内；或所述至少部分超时消息的数量和消息总数量之比在第二预定范围之内，所述消息总数量是指在所述当前时间窗口内发送给所述服务器集群的消息的总数量。

在示例性的实施例中，所述响应延时情况包括：在所述当前时间窗口内，所述服务器集群中的各个分区的延时比例；所述处理模块1130，还用于：将延时比例高于第二阈值的分区作为所述目标分区，并对所述目标分区进行熔断以暂停消息发送。

在示例性的实施例中，所述延时比例为第一消息数量和第二消息数量之比；所述第一消息数量为：在所述当前时间窗口内，被发送到所述相应分区且响应时间超过第三阈值的消息的数量；所述第二消息数量为：在所述当前时间窗口内，被发送到所述相应分区的消息的总数量。

在示例性的实施例中，所述消息延时处理系统1100可以包括阈值获取模块(未图示)，用于：以预设频率获取所述第三阈值：实时获取所述服务器集群的响应延时分位线；及计算所述响应延时分位线和预设容忍因子之乘积，将乘积结果设定为所述第三阈值。

在示例性的实施例中，所述消息延时处理系统1100可以包括恢复模块(未图示)，用于：当所述目标分区处于熔断状态时：S1：将其中一批次消息作为当前批次消息发送给所述目标分区，基于这批次消息的发送成功率判断是否发送下一批次消息，这批次消息的初始数据为第一批次消息；S2：当这批次消息的发送成功率达标，则将所述下一批次消息作为所述当前批次消息并重复执行S1；所述下一批次消息的消息数量大于所这批次消息的消息数量；S3：当这批次消息的发送成功率不达标，则间隔预定时间将所述下一批次消息作为所述当前批次消息并重复执行S1；所述下一批次消息的消息数量等于所述第一批次消息的消息数量；循环执行上述操作以逐步恢复向所述目标分区发送消息，直至所述当前批次消息的数量大于或等于预定数量。

在示例性的实施例中，所述消息延时处理系统1100可以包括黑名单获取模块(未图示)，用于：获取分布式服务协调组件提供的分区黑名单，所述分区黑名单包括所述服务器集群中的多个不可写入分区；及根据所述分区黑名单确定所述多个分区，所述多个分区为所述服务器集群中除所述多个不可写入分区之外的至少部分分区。

在示例性的实施例中，所述分区黑名单是由所述服务器集群根据所述各个分区的实时情况生成并上报给所述分布式服务协调组件的。

在示例性的实施例中，所述消息发送情况还包括将消息发送到所述服务器集群的消息发送成功率。所述消息延时处理系统1100可以包括切换模块(未图示)，用于：根据所述消息发送成功率，动态确定切换比例；及根据所述切换比例，切换待发送到所述服务器集群的多个待发送消息中的部分消息的发送地，以将该部分消息的发送地由所述服务器集群切换到到其他服务器集群。

实施例四

图12示意性示出了根据本申请实施例四的适于实现消息延时处理方法的计算机设备的硬件架构示意图。本实施例中，计算机设备可以内置或运行客户端30。并且，所述计算机设备1200其是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。例如，可以是工作站、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务器，或者多个服务器所组成的服务器集群)等。如图12所示，计算机设备1200至少包括但不限于：可通过系统总线相互通信链接存储器1210、处理器1220、网络接口1230。其中：

存储器1210至少包括一种类型的计算机可读存储介质，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器1210可以是计算机设备1200的内部存储模块，例如该计算机设备1200的硬盘或内存。在另一些实施例中，存储器1210也可以是计算机设备1200的外部存储设备，例如该计算机设备1200上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，存储器1210还可以既包括计算机设备1200的内部存储模块也包括其外部存储设备。本实施例中，存储器1210通常用于存储安装于计算机设备1200的操作系统和各类应用软件，例如消息延时处理方法的程序代码等。此外，存储器1210还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器1220在一些实施例中可以是中央处理器(Central Processing Unit，简称为CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器1220通常用于控制计算机设备1200的总体操作，例如执行与计算机设备1200进行数据交互或者通信相关的控制和处理等。本实施例中，处理器1220用于运行存储器1210中存储的程序代码或者处理数据。

网络接口1230可包括无线网络接口或有线网络接口，该网络接口1230通常用于在计算机设备1200与其他计算机设备之间建立通信连接。例如，网络接口1230用于通过网络将计算机设备1200与外部终端相连，在计算机设备1200与外部终端之间的建立消息延时处理通道和通信连接等。网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(Global System of Mobile communication，简称为GSM)、宽带码分多址(WidebandCode Division Multiple Access，简称为WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。需要指出的是，图12仅示出了具有部件1210-1230的计算机设备，但是应理解的是，并不要求实施所有示出的部件，可以替代的实施更多或者更少的部件。在本实施例中，存储于存储器1210中的消息延时处理方法还可以被分割为一个或者多个程序模块，并由一个或多个处理器(本实施例为处理器1220)所执行，以完成本申请。

实施例五

本实施例还提供一种计算机可读存储介质，计算机可读存储介质其上存储有计算机程序，计算机程序被处理器执行时实现实施例中的消息延时处理方法的步骤。

本实施例中，计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，计算机可读存储介质可以是计算机设备的内部存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，计算机可读存储介质也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中，计算机可读存储介质通常用于存储安装于计算机设备的操作系统和各类应用软件，例如实施例中的消息延时处理方法的程序代码等。此外，计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。以上实施例可以用于幂等系统，也可以用于非幂等系统。以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (14)

1.一种消息延时处理方法，其特征在于，用于流式数据传输链路中的数据缓冲层，所述方法包括：

向所述数据缓冲层的kafka服务器集群中的多个分区发送多个消息，以将所述多个消息写入到所述kafka服务器集群；

获取所述kafka服务器集群的消息发送情况，所述消息发送情况包括各个分区的响应延时情况；及

当所述多个分区中的目标分区的响应延时情况符合熔断条件，则对所述目标分区进行熔断，并将至少部分超时消息重新发送到所述kafka服务器集群中的其他分区；

其中，所述目标分区为延时比例高于第二阈值的分区。

2.根据权利要求1所述的消息延时处理方法，其特征在于，获取所述kafka服务器集群的消息发送情况，包括：

基于时间滑动窗口的方式，获取当前时间窗口内所述kafka服务器集群的所述消息发送情况。

3.根据权利要求2所述的消息延时处理方法，其特征在于，所述消息发送情况包括：在所述当前时间窗口内是否存在响应时间超过第一阈值的一个或多个超时消息；所述方法还包括：

当在所述当前时间窗口内存在所述一个或多个超时消息，则将所述一个或多个超时消息中的至少部分超时消息重新发送到所述kafka服务器集群中的其他分区中；

其中，所述其他分区与各个超时消息的原发送分区是不同的分区。

4.根据权利要求3所述的消息延时处理方法，其特征在于，

所述至少部分超时消息的数量在第一预定范围之内；或

所述至少部分超时消息的数量和消息总数量之比在第二预定范围之内，所述消息总数量是指在所述当前时间窗口内发送给所述kafka服务器集群的消息的总数量。

5.根据权利要求2所述的消息延时处理方法，其特征在于，所述响应延时情况包括：在所述当前时间窗口内，所述kafka服务器集群中的各个分区的延时比例；当所述多个分区中的目标分区的响应延时情况符合熔断条件，则对所述目标分区进行熔断：

将延时比例高于第二阈值的分区作为所述目标分区，并对所述目标分区进行熔断以暂停消息发送。

6.根据权利要求5所述的消息延时处理方法，其特征在于，

所述延时比例为第一消息数量和第二消息数量之比；

所述第一消息数量为：在所述当前时间窗口内，被发送到相应分区且响应时间超过第三阈值的消息的数量；

所述第二消息数量为：在所述当前时间窗口内，被发送到所述相应分区的消息的总数量。

7.根据权利要求6所述的消息延时处理方法，其特征在于，还包括以预设频率获取所述第三阈值：

实时获取所述kafka服务器集群的响应延时分位线；及

计算所述响应延时分位线和预设容忍因子之乘积，将乘积结果设定为所述第三阈值。

8.根据权利要求1至7任意一项所述的消息延时处理方法，其特征在于，当所述目标分区处于熔断状态时，所述方法还包括：

S1：将其中一批次消息作为当前批次消息发送给所述目标分区，基于这批次消息的发送成功率判断是否发送下一批次消息，这批次消息的初始数据为第一批次消息；

S2：当这批次消息的发送成功率达标，则将所述下一批次消息作为所述当前批次消息并重复执行S1；所述下一批次消息的消息数量大于所这批次消息的消息数量；

S3：当这批次消息的发送成功率不达标，则间隔预定时间将所述下一批次消息作为所述当前批次消息并重复执行S1；所述下一批次消息的消息数量等于所述第一批次消息的消息数量；

循环执行上述操作以逐步恢复向所述目标分区发送消息，直至所述当前批次消息的数量大于或等于预定数量。

9.根据权利要求8所述的消息延时处理方法，其特征在于，还包括：

获取分布式服务协调组件提供的分区黑名单，所述分区黑名单包括所述kafka服务器集群中的多个不可写入分区；及

根据所述分区黑名单确定所述多个分区，所述多个分区为所述kafka服务器集群中除所述多个不可写入分区之外的至少部分分区。

10.根据权利要求9所述的消息延时处理方法，其特征在于，所述分区黑名单是由所述kafka服务器集群根据所述各个分区的实时情况生成并上报给所述分布式服务协调组件的。

11.根据权利要求1至7任意一项所述的消息延时处理方法，其特征在于，所述消息发送情况还包括将消息发送到所述kafka服务器集群的消息发送成功率，所述方法还包括：

根据所述消息发送成功率，动态确定切换比例；及

根据所述切换比例，切换待发送到所述kafka服务器集群的多个待发送消息中的部分消息的发送地，以将该部分消息的发送地由所述kafka服务器集群切换到到其他服务器集群。

12.一种消息延时处理系统，其特征在于，用于流式数据传输链路中的数据缓冲层，所述系统包括：

发送模块，用于向所述数据缓冲层的kafka服务器集群中的多个分区发送多个消息，以将所述多个消息写入到所述kafka服务器集群；

获取模块，用于获取所述kafka服务器集群的消息发送情况，所述消息发送情况包括各个分区的响应延时情况；及

处理模块，用于当所述多个分区中的目标分区的响应延时情况符合熔断条件，则对所述目标分区进行熔断，并将至少部分超时消息重新发送到所述kafka服务器集群中的其他分区；

其中，所述目标分区为延时比例高于第二阈值的分区。

13.一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时用于实现权利要求1至11任一项所述消息延时处理方法的步骤。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时用于实现权利要求1至11任一项所述消息延时处理方法的步骤。

Images