CN111818112B

CN111818112B - 一种基于Kafka系统的发送消息的方法和装置

Info

Publication number: CN111818112B
Application number: CN201910290584.3A
Authority: CN
Inventors: 杨名
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Group Sichuan Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Group Sichuan Co Ltd
Priority date: 2019-04-11
Filing date: 2019-04-11
Publication date: 2022-10-04
Anticipated expiration: 2039-04-11
Also published as: CN111818112A

Abstract

本发明公开了一种基于Kafka的发送消息的方法和装置，用以避免在发送消息的过程中出现重复发送或消息丢失的情况。本申请提供的方案包括：通过分区器将生产者Producer发送的消息分配至集群中至少一个服务器Broker中；通过监听器监听消息分配至至少一个服务器中的分配完成度；当分配完成度满足预设完成度标准时，指示消费者Consumer通过至少一个服务器读取消息。通过本申请提供的上述方案，基于Kafka系统，分区器能避免对生产者发送的同一条消息多次下发或漏发消息的情况。同时，监听器能避免下发的消息不完整的情况。只有在分配完成度满足预设完成度标准的情况下，指示消费者读取消息，保证消费者能读取到完整的信息。

Description

一种基于Kafka系统的发送消息的方法和装置

技术领域

本发明涉及分布式消息系统领域，尤其涉及一种基于Kafka系统的发送消息的方法和装置。

背景技术

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。流式数据多应用于web网站中，该数据包括页面访问量(PageView)、被查看内容方面的信息以及搜索情况等内容。

现有的Kafka消息分发机制中，是由分类器Topic获取生产者Producer的消息，并通过多个服务器Broker下发给消费者Consumer。但是，在现有的消息分发机制中，每条消息仅被传输一次，一旦有服务器出现宕机，则有可能出现消息丢失的情况。如果在消息丢失时重发该消息，消费者有可能重复接收消息。

如何避免在发送消息的过程中出现重复发送或消息丢失的情况，是本申请所要解决的技术问题。

发明内容

本申请实施例的目的是提供一种基于Kafka的发送消息的方法和装置，用以避免在发送消息的过程中出现重复发送或消息丢失的情况。

第一方面，提供了一种基于Kafka系统的消息发送方法，包括：

通过分区器将生产者Producer发送的消息分配至集群中至少一个服务器Broker中；

通过监听器监听所述消息分配至所述至少一个服务器中的分配完成度；

当所述分配完成度满足预设完成度标准时，指示消费者Consumer通过所述至少一个服务器读取所述消息。

第二方面，提供了一种基于Kafka系统的消息发送装置，包括：

分区器，将生产者Producer发送的分配至集群中的至少一个服务器Broker中；

监听器，通过监听器监听所述消息分配至所述至少一个服务器中的分配完成度；

指示器，当所述分配完成度满足预设完成度标准时，指示消费者Consumer通过所述至少一个服务器读取所述消息。

第三方面，提供了一种电子设备，包括处理器、存储器及存储在该存储器上并可在该处理器上运行的计算机程序，该计算机程序被该处理器执行时实现如第一方面该的方法的步骤。

第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质上存储计算机程序，该计算机程序被处理器执行时实现如第一方面该的方法的步骤。

在本申请实施例中，基于Kafka系统，通过分区器将生产者发送的消息下发至集群中的至少一个服务器中，该分区器能避免对生产者发送的同一条消息多次下发或漏发消息的情况。同时，通过监听器监听消息的分配完成度，避免下发的消息不完整的情况。只有在分配完成度满足预设完成度标准的情况下，指示消费者读取消息，保证消费者能读取到完整的信息。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是Kafka系统逻辑结构示意图；

图2是本发明提供的一种基于Kafka的发送消息的方法的流程示意图之一；

图3是本发明提供的一种基于Kafka的发送消息的方法的流程示意图之三；

图4是本发明提供的一种基于Kafka的发送消息的方法的流程示意图之四；

图5是本发明提供的一种基于Kafka的发送消息的方法的流程示意图之五；

图6是本发明提供的一种基于Kafka的发送消息的方法的流程示意图之六；

图7是本发明提供的一种基于Kafka的发送消息的装置结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。本申请中附图编号仅用于区分方案中的各个步骤，不用于限定各个步骤的执行顺序，具体执行顺序以说明书中描述为准。

首先，对本方案中涉及的Kafka系统结构进行介绍。如图1所示，在Kafka系统中通常包括生产者Producer、服务器Broker、区块Partition、消费者Consumer。其中，服务器Broker和区块Partition也可以被称为服务集群，一个服务集群中可以包括多个服务器Broker，每个服务器Broker中可以包含多个区块Partition。

一个服务集群可以服务于多个生产者Producer，当生产者Producer向集群发布消息时，集群先将接收到的消息进行分类，每条消息可以被分为至少一个类别Topic，每个类别Topic包含一个或多个区块Partition。这些区块Partition可以被分别存储在多个服务器Broker中。

消费者Consumer可以读取区块Partition以获得生产者Producer发布的消息。实际上，消费者Consumer通常只需确定读取的类别Topic即可读取到确定的类别Topic的至少一个区块Partition，这些区块Partition通常存储在不同的服务器Broker中。

具体的，图1示出了一种Kafka系统逻辑结构，其中包括一个生产者Producer 0，三个服务器Broker 0、Broker 1、Broker 2，两个消费者Consumer 0、Consumer 1。每个服务器Broker中包括多个区块Partition，这些区块Partition来源于生产者Producer 0发布的消息，每个区块Partition均对应一种类别Topic。

例如，经过分类器分类，生产者Producer 0发布的消息的类型包括Topic 0和Topic 1。其中，类型Topic 0的区块包括Topic 0 Partition 0和Topic 0 Partition 1，类型Topic 1的区块包括Topic 1 Partition 0。

随后，Topic 0 Partition 0被分配存储在服务器Broker 0中，Topic 0Partition 1被分配存储在服务器Broker 1中，Topic 1 Partition 0被分配存储在服务器Broker 2中。对于存储在服务器Broker 0中的Topic 0 Partition 0，还通过建立备份区块的方式在服务器Broker 1和服务器Broker 2中进行了备份。同理，对于存储在服务器Broker 1中的Topic 0 Partition 1，在服务器Broker 0和服务器Broker 2进行了备份。对于存储在服务器Broker 2中的Topic 1 Partition 0，在服务器Broker 0和服务器Broker1进行了备份。需要说明的是，图中仅示出了一种Kafka结构，实际上，Kafka集群中可以有更多或更少数量的服务器Broker，也可以有更多或更少数量的备份区块。

随后，在消费者读取消息时，通过集群中的服务器Broker直接读取数据。通常情况下，消费者可以通过申请读取目标类别Topic区块的方式读取到具有目标类别Topic的区块。例如，消费者Consumer 0确定读取的目标类别为Topic 0，则消费者读取到的区块包括存储于服务器Broker 0中的Topic 0 Partition 0以及存储于服务器Broker 1中的Topic0 Partition 1。消费者Consumer 1确定读取的目标类别为Topic 1，则消费者读取到的区块包括存储于服务器Broker 2中的Topic 1 Partition 0。

另外，一个服务集群可以服务于多个消费者Consumer，多个消费者Consumer可以划分至多个消费者群组Consumer Group用以实现对消费者Consumer的分类。其中，每个消费者群组可以订阅一种或多种类别Topic的消息。

在实际应用过程中，一旦存储消息的服务器Broker宕机，则宕机的服务器Broker中的区块Partition有可能丢失，进而有可能导致消费者Consumer读取到的消息不完整。如果采用重发机制，在服务器Broker宕机时重新下发生产者Consumer发布的消息，则有可能导致消费者Consumer读取到重复的消息。

针对现有技术中存在的问题，本申请提供一种基于Kafka系统的消息发送方法，如图2所示，本申请提供的方案包括以下步骤：

S11：通过分区器将生产者Producer发送的消息分配至集群中至少一个服务器Broker中；

S12：通过监听器监听所述消息分配至所述至少一个服务器中的分配完成度；

S13：当所述分配完成度满足预设完成度标准时，指示消费者Consumer通过所述至少一个服务器读取所述消息。

在本申请上述步骤S11之前，可以先由分类器对消费者Producer发布的消息进行分类。随后，在本申请步骤S11中，由分区器将经过分类的消息下发至集群中的至少一个服务器Broker中。

另外，对于经过分类器分类的消息，还可执行消息校验，消息校验具体可以包括：分区数、副本因子、Topic类别名字中是否含有非法字符、机架信息等。完成以上消息校验之后，先确定集群中可用的服务器Broker列表，基于可用服务器Broker列表进行之后的消息分配。

本申请中的分区器可以与生产者Producer相对应，一个生产者Producer发布的消息可以固定的通过一个分区器进行分配。当一个集群服务于多个生产者Producer时，集群中可以包括与生产者Producer一一对应的多个分区器。

较优的，本申请提供的方案将消息尽可能均衡地分配至可用的服务器Broker中，均衡分配消息的方式可以有多种，下面通过举例的方式进行说明。

例如，首先确定一个服务器Broker，当集群中包含多个分区器时，用轮询的方式分配每一个分区器中的消息。具体的，在向一个服务器Broker分配了一个区块Partition之后，可以采用增量右移的方式分配其他的区块。

另外，还可以基于分类得到的消息的类别Topic，对一种类别Topic下的所有区块Partition进行排序，调用该类别Topic对应的元数据Metadata，根据服务器中的类别Topic、Key，利用Key Serializer得到序列化Key(Serialized Key)；根据Record中类别Topic、Value，利用Value Serializer得到序列化Value(Serialized Value)。

当一个集群中有新的分区器加入或者有分区器离开，可以通过区块Partition均衡的方式对区块Partition进行调整，以保证区块Partition均匀地保存在多个服务器Broker中。本申请提供的上述方案能提升类别Topic的并发消费能力。

本申请中的监听器ChangeListener可以用于监听集群中的动作。例如，监听器可以用于更新分区器的缓存信息，缓存信息可以包括集群中当前所有的类别Topic列表、新增的类别Topic的分配缓存等。另外，监听器还可以用于在随后创建区块对象及备份区块对象，并确定领导区块Leader及备份区块列表ISR(in-sync Replica)。

监听器可以根据监听到的内容确定所述消息分配至所述至少一个服务器中的分配完成度。较优的，可以在消息被完全分配完成之后，指示消费者Consumer通过服务器Broker读取消息。具体的，监听器可以监听分配结果的反馈信息，反馈信息可以包括BatchIsFull、NewBatchCreated等。根据监听到的分配结果的反馈信息，监听器可以确定消息分配完成度，进而确定消息是否已经被完全分配。在消息被完全分配之后，可以指示消费者读取消息。

通过本申请提供的上述方案，基于Kafka系统，通过分区器将生产者发送的消息下发至集群中的至少一个服务器中，该分区器能避免对生产者发送的同一条消息多次下发或漏发消息的情况。同时，通过监听器监听消息的分配完成度，避免下发的消息不完整的情况。只有在分配完成度满足预设完成度标准的情况下，指示消费者读取消息，保证消费者能读取到完整的信息。

基于上述实施例提供的方案，较优的，如图3所示，上述步骤S11，包括以下步骤：

S111：通过分类器对所述消息执行分类，确定所述消息对应的至少一个类别Topic；

S112：根据所述消息对应的的至少一个类别，通过所述分区器将所述消息划分为至少一个消息区块；

S113：将所述至少一个消息区块分配至所述集群中的至少一个服务器中；

S114：将所述消息区块备份到至少一个与所述消息区块关联的备份区块中。

其中，所述消息区块可以为上述区块Partition，本申请提供的方案对消息区块进行备份，将备份的消息区块副本分散地存储在集群中的至少一个服务器中。

具体的，分区器中保存有生产者Producer发布的消息的每个类别Topic，每个服务器Broker保存了当前服务器Broker中保存的分区Partition的每个类别Topic。当生产者Producer发布了新消息时，可以结合分区器保存的类别Topic列表和集群中服务器Broker中保存的类别Topic列表确定新增的消息类别Topic。假设新增消息类别Topic名称为Test。

具体的，假设分区器中保存的类别Topic列表为A，服务器中保存的类别Topic列表为B，则新增的至少一个消息类别Topic可以通过A-B得到。在确定新增消息类别Topic为“Test”之后，对分区器保存的消息类别Topic列表进行更新，将Test添加至列表中。

随后，对集群中所有分区器排序，第i个分区器记为Ci。计算序列化后的key、value及其offset、size所占大小serializedSize。根据区块Partition索引号对区块Partitions进行排序，假设得到的排序结果为：P0，P1，P2，P3。接着，计算出区块Partition倍数：M＝[P0,P1,P2,P3].size/(CG).size。分区器Ci对原来分配的区块Partition消费。将第i*N到(i+1)*N-1个区块Partition分配给分区器Ci；依次分配区块Partition：C0＝[P0,P1]，C1＝[P2,P3]，即Ci＝[P(i*N),P((i+1)*N-1)]。

在确定了以上分配方案之后，可以将该分配方案持久化到Zookeeper中，该Zookeeper是一个分布式的，开放源码的分布式应用程序协调服务。该Zookeeper中保存的分配方案可以随后被调用或查询。

基于上述实施例提供的方法，较优的，如图4所示，当所述分配完成度满足预设完成度标准时，还包括以下步骤：

S14：通过监听器监听所述消费者读取所述消息的读取完成度；

S15：当所述读取完成度满足预设读取完成度标准时，向所述生产者反馈与所述读取完成度相对应的信息。

本申请提供的分区器中，包括了多种数据结构用于记录当前集群的各种状态。较优的，一个分区器中包括一个分区状态机和一个副本状态机，用以记录各个区块的状态和状态流转。

上述分区状态机会注册至少一个zookeeper监听器，具体可以包括用以监听类型Topic相关信息的监听器TopicChangeListener。具体来说，该监听器可以用于监听服务器中类别节点的数据，一旦该类别节点的数据发生变化，监听器就会被触发。

在注册监听器之后，监听器可以用于监听消费者读取消息的完成度。如果监听器监听到消费者完全读取了消息，则可以向生产者Producer反馈与消费者完全读取了消息相对应的信息。另外，如果在消费者完全读取消息之前，有服务器Broker宕机，则监听器可以监听到消费者无法读取到完整的消息，此时，分区器可以对下发的消息执行回收并重下发。

在本实施例中，预设读取完成度标准可以包括消息完全被读取，在实际应用中，预设读取完成度标准也可以根据实际需求进行设定。

本申请提供的上述方案能通过监听器监听到消费者读取消息的完成度，在消费者读取消息满足预设读取完成度标准时，监听器向生产者反馈与上述读取完成度相对应的信息，以通知生产者上述消息已经成功发送至消费者，避免生产者重新下发相同的消息。

基于上述实施例提供的方案，较优的，当所述分配完成度在预设时间内未满足预设完成度标准时，还包括以下步骤：

通过所述分区器从所述至少一个服务器中回收所述消息，并将所述消息重新分配至所述集群中的至少一个服务器中。

在本申请实施例中，当分配完成度在预设时间内未满足预设完成度标准，则表明在分配消息的过程中，有服务器宕机，消息无法完整下发。此时，通过分区器从集群中的至少一个服务器中回收消息。具体的，在分区器中预先记录有消息下发位置，根据分区器中记录的下发位置对消息进行回收。避免不完整的消息被消费者读取。

在完成回收之后，基于当前可用的服务器重新分配消息。监听器可以持续监听消息分配完成度，当分配完成度满足预设完成度标准时可以指示消费者读取上述消息。

基于上述实施例提供的方法，较优的，如图5所示，上述步骤S114，包括：

S1141：基于所述消息区块创建与所述消息区块关联的至少一个备份区块；

S1142：确定所述至少一个备份区块中的领导区块Leader；

S1143：通过所述领导区块建立所述至少一个备份区块对应的备份区块列表ISR；

S1144：将所述消息区块备份到所述备份区块列表中包含的至少一个备份区块中。

首先，通过OnNewPartitionCreation创建消息区块描述。具体的，先创建区块对象，将创建的区块对象的状态设置为Newpartition。然后，根据分区器中预设的分配方案，为上述区块对象创建对应的备份区块对象。并且，将创建的备份区块的状态设置为NewReplica。

通过以上步骤创建了消息区块和与消息区块关联的备份区块。随后，确定所述至少一个备份区块中的领导区块Leader。具体的，可以通过选举的方式确定领导区块Leader。在实际执行过程中，可以直接将备份区块中的第一个备份区块确定为领导区块，并通过确定的领导区块建立与上述备份区块对应的备份区块列表ISR，该备份区块列表ISR可以存于领导区块Leader的缓存中。另外，在建立备份区块列表ISR之后，领导区块Leader还用于对备份区块列表ISR中的内容进行维护更新，保证备份区块列表ISR中的内容与集群中的情况相匹配。

上述备份区块列表ISR中包括与领导区块Leader相关联的多个跟随区块Follower。在实际应用过程中，由领导区块Leader确定相关联的多个跟随区块Follower的状态。如果有跟随区块Follower宕机或落后太多，领导区块Leader就会将该跟随区块Follower从备份区块列表ISR中剔除。通过领导区块Leader对备份区块列表ISR的维护，可以保证备份区块列表ISR中记录的跟随区块Follower都是正常可用的区块。

基于上述实施例提供的方案，较优的，如图6所示，在上述步骤S1144之后，还包括：

S1145：将所述领导区块和所述备份区块列表打包为同步文件；

S1146：通过所述分区器将所述同步文件下发至所述集群中至少一个服务器中。

在确定的领导区块Leader并建立备份区块列表ISR之后，还需要让集群中其他服务器Broker获知确定的领导区块Leader以及建立的备份区块列表ISR。

具体的，可以通过发送Updatemetadata Request的方式通知集群中的多个服务器Broker。首先，将领导区块Leader和备份区块列表ISR打包封装为一个map文件。然后为map中的每一项都构造一个Updatemetadata Reuqest对象并通过分区器发给所有可用的服务器Broker。

本申请提供的上述方案能保证集群中的服务器Broker能获知新确定的领导区块Leader以及备份区块列表ISR，保证集群中的信息基本同步。

通过以上步骤，集群中的区块Partition都已经确定了领导区块Leader和备份区块列表ISR，并将以上内容同步至集群中的服务器Broker上。随后，可以将备份区块的状态从NewReplica转换到OnlineReplica。转换为OnlineReplica状态之后，备份区块的内容可以被消费者读取。

基于上述实施例提供的方法，较优的，在通过分类器对生产者发送的消息执行分类，确定所述消息对应的至少一个类别之前，还包括：

当接收所述生产者发送的消息时，创建与所述生产者对应的分区器。

由于一个Kafka集群可以服务于多个生产者，为了提高数据吞吐量，本申请提供的实施方案在接收到生产者发送的消息时创建与生产者对应的分区器，以便通过创建的分区器对生产者发布的消息进行处理。

本申请提供的上述方案，能保证数据的可靠性，避免消息重复发送或漏发的情况，同时降低了集群内网络开销与内存、CPU等额外源开销，有效地平衡了系统的可用性和性能。另外，通过分区器索引信息可以快速定位Message和确定Response的最大大小。通过添加分区器存储，还可以大幅降低Index文件元数据占用空间大小。

为了解决现有技术中存在上述问题，如图7所示，本申请还提供一种基于Kafka系统的发送消息的装置70，包括：

分区器71，将生产者Producer发送的分配至集群中的至少一个服务器Broker中；

监听器72，通过监听器监听所述消息分配至所述至少一个服务器中的分配完成度；

指示器73，当所述分配完成度满足预设完成度标准时，指示消费者Consumer通过所述至少一个服务器读取所述消息。

基于上述实施例提供的装置，较优的，所述分区器用于：

对所述消息执行分类，确定所述消息对应的至少一个类别Topic；

根据所述消息对应的的至少一个类别，将所述消息划分为至少一个消息区块；

将所述至少一个消息区块分配至所述集群中的至少一个服务器中；

将所述消息区块备份到至少一个与所述消息区块关联的备份区块中。

基于上述实施例提供的装置，较优的，当所述分配完成度满足预设完成度标准时，所述监听器用于：

监听所述消费者读取所述消息的读取完成度；

当所述读取完成度满足预设读取完成度标准时，向所述生产者反馈与所述读取完成度相对应的信息。

基于上述实施例提供的装置，较优的，当所述分配完成度在预设时间内未满足预设完成度标准时，所述分区器还用于：

基于上述实施例提供的装置，较优的，所述分区器用于：

基于所述消息区块创建与所述消息区块关联的至少一个备份区块；

确定所述至少一个备份区块中的领导区块Leader；

通过所述领导区块建立所述至少一个备份区块对应的备份区块列表ISR；

将所述消息区块备份到所述备份区块列表中包含的至少一个备份区块中。

基于上述实施例提供的装置，较优的，所述分区器还用于：

将所述领导区块和所述备份区块列表打包为同步文件；

通过所述分区器将所述同步文件下发至所述集群中至少一个服务器中。

基于上述实施例提供的装置，较优的，所述装置还包括：

创建模块，当接收所述生产者发送的消息时，创建与所述生产者对应的分区器。

优选的，本发明实施例还提供一种电子设备，包括处理器，存储器，存储在存储器上并可在所述处理器上运行的计算机程序，该计算机程序被处理器执行时实现上述一种图像处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述一种图像处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本发明的保护之内。

Claims

1.一种基于Kafka系统的消息发送方法，其特征在于，包括：

当所述分配完成度满足预设完成度标准时，指示消费者Consumer通过所述至少一个服务器读取所述消息；

所述分配完成度满足预设完成度标准时，还包括：

通过监听器监听所述消费者读取所述消息的读取完成度；

2.如权利要求1所述的方法，其特征在于，通过分区器将生产者Producer发送的消息分配至集群中至少一个服务器Broker中，包括：

通过分类器对所述消息执行分类，确定所述消息对应的至少一个类别Topic；

根据所述消息对应的的至少一个类别，通过所述分区器将所述消息划分为至少一个消息区块；

3.如权利要求2所述的方法，其特征在于，当所述分配完成度在预设时间内未满足预设完成度标准时，还包括：

4.如权利要求2所述的方法，其特征在于，所述将所述消息区块备份到至少一个与所述消息区块关联的备份区块中，包括：

确定所述至少一个备份区块中的领导区块Leader；

5.如权利要求4所述的方法，其特征在于，在将所述消息区块备份到所述备份区块列表中包含的至少一个备份区块中之后，还包括：

将所述领导区块和所述备份区块列表打包为同步文件；

6.如权利要求1～5任一项所述的方法，其特征在于，在通过分类器对生产者发送的消息执行分类，确定所述消息对应的至少一个类别之前，还包括：

7.一种基于Kafka系统的发送消息的装置，其特征在于，包括：

指示器，当所述分配完成度满足预设完成度标准时，指示消费者Consumer通过所述至少一个服务器读取所述消息；

当所述分配完成度满足预设完成度标准时，所述监听器用于：

监听所述消费者读取所述消息的读取完成度；

8.一种电子设备，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至6中任一项所述的方法的步骤。

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