CN111163118B - 一种Kafka集群中的消息传输方法及装置 - Google Patents
一种Kafka集群中的消息传输方法及装置 Download PDFInfo
- Publication number
- CN111163118B CN111163118B CN201811319985.9A CN201811319985A CN111163118B CN 111163118 B CN111163118 B CN 111163118B CN 201811319985 A CN201811319985 A CN 201811319985A CN 111163118 B CN111163118 B CN 111163118B
- Authority
- CN
- China
- Prior art keywords
- message
- size
- fragment
- target
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0876—Network utilisation, e.g. volume of load or congestion level
- H04L43/0888—Throughput
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Environmental & Geological Engineering (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本发明实施例提供了一种Kafka集群中的消息传输方法及装置。本发明实施例在大尺寸消息的传输过程中,既能保证集群吞吐量不会大幅降低,还可以使得集群各节点负载更均衡,系统资源更加有效利用。另外,本发明实施例利用分区算法加速了大尺寸消息的还原速度,提高了处理响应时间;另外,偏移量保存在集群节点处,也保证了当订阅方系统崩溃恢复后可以无需再从最开始处重复消费消息,只需从当前消费位置开始处理消息,可以避免重复消费,同时也保证了数据一致性,也大大降低了时间成本。
Description
技术领域
本发明涉及分布式发布/订阅消息系统,具体而言,本发明涉及一种Kafka集群中的消息传输方法及装置。
背景技术
Kafka是由Apache软件基金会开发的一个开源消息处理平台,由Scala和Java编写。Kafka是一种高吞吐量的分布式发布/订阅消息系统,能够支撑海量数据的数据传递。在离线和实时的消息处理业务系统中,Kafka都有广泛的应用。Kafka将消息持久化到磁盘中,并对消息创建了备份保证了数据的安全。Kafka在保证了较高的处理速度的同时,又能保证数据处理的低延迟和数据的零丢失。Kafka的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台,其持久化层本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”,这使得它作为企业级基础设施来处理流式数据非常有价值。
为了便于在发布/订阅消息系统内传递过大的消息,现有技术提出了对消息进行切片的处理方案,即将大尺寸的消息切割为多个片段分别进行发布。
另外为了避免订阅方从宕机恢复后,从消息流重新开始接收消息的偏移量是未知的,现有技术还提供了一种支持传递过大的消息的方法,该方法包括以下步骤:
(1)确定提交消息代理集群的偏移量,其中所确定的偏移量基于一个或多个超大尺寸消息的一个或多个片段是否被缓冲;
(2)将所确定的偏移量提交消息代理集群。
如果订阅方宕机,则在订阅方系统恢复后,该方法就可以从消息代理集群中检索所确定的偏移量,并基于该偏移量继续订阅消息。
上述方法解决了订阅方宕机后消费的消息偏移量未知的问题,但没有考虑大尺寸消息切片后的数据的完整性和一致性问题,因此,亟需一种方案,能够保证大尺寸消息切片后的数据的完整性和一致性。
发明内容
本发明实施例要解决的技术问题是提供一种Kafka集群中的消息传输方法及装置,将同一消息的多个片段发布至目标节点的同一分区,保证了数据的完整性和一致性,并能够降低消息订阅的响应延迟。
为解决上述技术问题,本发明实施例提供的一种Kafka集群中的消息传输方法,包括:
获取待发布消息的大小和主题;
在所述待发布消息的大小超过预设尺寸的情况下,按照预设的分片基准值对所述待发布消息进行分割,得到所述待发布消息的多个消息片段,记录分割时间戳并为每个消息片段进行顺序编号;
从所述多个消息片段的编号中随机选择一个目标编号,根据所述分割时间戳和目标编号,组合得到每个所述消息片段的分区关键字;
在所述Kafka集群的目标节点的所述待发布消息的主题下的分区中,确定所述分区关键字对应的目标分区,将所述多个消息片段按照编号顺序发布至所述目标分区。
优选的,在获取待发布消息的大小和主题之前,所述方法还包括:
通过发布不同大小的消息,分别测试所述Kafka集群在不同大小的消息下的集群吞吐量;
根据集群吞吐量最大时的消息的大小,确定所述分片基准值。
优选的,在确定所述分区关键字对应的目标分区之前,所述方法还包括:
获取所述Kafka集群中的节点的系统资源的使用状态,所述系统资源包括CPU资源、内存资源和磁盘资源中的至少一种;
根据所述节点的系统资源的使用状态,计算所述节点的可用资源评分,并选择出可用资源评分最高的节点,作为所述待发布消息发布的目标节点。
优选的,所述系统资源包括CPU资源、内存资源和磁盘资源;计算所述节点的可用资源评分的步骤,包括:
获取预先设定的CPU资源、内存资源和磁盘资源各自的权重值;
根据所述权重值,对所述节点的CPU资源的空闲率指标、内存指标以及磁盘指标进行加权求和,得到所述节点的可用资源评分,其中,所述内存指标通过所述待发布消息的大小与所述内存的空余量的比值来表示,所述磁盘指标通过所述待发布消息的大小与所述磁盘的空余量的比值来表示。
优选的,确定所述分区关键字对应的目标分区的步骤,包括:
获取所述目标节点中所述待发布消息的主题所包含的分区数量;
利用所述目标分区关键字对所述分区数量进行取模运算,根据得到的余数确定所述分区关键字对应的目标分区。
优选的,在为每个消息片段进行顺序编号时,进一步对所述待发布消息的最后一个消息片段采用预先约定的结束编号。
本发明实施例还提供了另一种Kafka集群中的消息传输方法,包括:
从Kafka集群获取订阅的目标主题的消息;
根据获取到的消息是否含有消息片段编号,判断当前获取的消息是否为大尺寸消息的消息片段,其中,所述Kafka集群中,超过预设尺寸的大尺寸消息的所有消息片段均按分片顺序发布于同一节点中所述大尺寸消息的主题下的同一分区;
在当前获取的消息为消息片段时,继续订阅所述目标主题的消息直至获取到所述大尺寸消息的最后一个消息片段;
根据订阅到的所述大尺寸消息的所有消息片段,还原并消费所述大尺寸消息。
优选的,在获取订阅的目标主题的消息之后,所述方法还包括:
将获取到的消息的偏移量更新至所述消息所在的目标节点;
在重启订阅所述目标主题的消息时,从所述目标节点获取所述偏移量,并根据所述偏移量继续订阅并消费所述目标主题的消息。
本发明实施例还提供了一种Kafka集群中的消息传输装置,包括:
消息获取单元,用于获取待发布消息的大小和主题;
分片处理单元,用于在所述待发布消息的大小超过预设尺寸的情况下,按照预设的分片基准值对所述待发布消息进行分割,得到所述待发布消息的多个消息片段,记录分割时间戳并为每个消息片段进行顺序编号;
关键字组合单元,用于从所述多个消息片段的编号中随机选择一个目标编号,根据所述分割时间戳和目标编号,组合得到每个所述消息片段的分区关键字;
分片发布单元,用于在所述Kafka集群的目标节点的所述待发布消息的主题下的分区中,确定所述分区关键字对应的目标分区,将所述多个消息片段按照编号顺序发布至所述目标分区。
优选的,所述的消息传输装置还包括:
分片基准确定单元,用于通过发布不同大小的消息,分别测试所述Kafka集群在不同大小的消息下的集群吞吐量;根据集群吞吐量最大时的消息的大小,确定所述分片基准值。
优选的,所述的消息传输装置还包括:
目标节点确定单元,用于获取所述Kafka集群中的节点的系统资源的使用状态,所述系统资源包括CPU资源、内存资源和磁盘资源中的至少一种;根据所述节点的系统资源的使用状态,计算所述节点的可用资源评分,并选择出可用资源评分最高的节点,作为所述待发布消息发布的目标节点。
本发明实施例还提供了一种Kafka集群中的消息传输装置,包括:
消息获取单元,用于从Kafka集群的目标节点获取订阅的目标主题的消息;
消息片段判断单元,用于根据获取到的消息是否含有消息片段编号,判断当前获取的消息是否为大尺寸消息的消息片段,其中,所述Kafka集群中,超过预设尺寸的大尺寸消息的所有消息片段均按分片顺序发布于同一节点中所述大尺寸消息的主题下的同一分区;
消息片段处理单元,用于在当前获取的消息为消息片段时,继续订阅所述目标主题的消息直至获取到所述大尺寸消息的最后一个消息片段;
消息片段还原单元,用于根据订阅到的所述大尺寸消息的所有消息片段,还原并消费所述大尺寸消息。
优选的,所述消息传输装置还包括:
偏移量更新单元,用于将当前获取到的消息的偏移量更新至所述目标节点;
重启订阅单元,用于在重启订阅所述目标主题的消息时,从所述目标节点获取所述偏移量,并根据所述偏移量继续订阅并消费所述目标主题的消息
本发明实施例还提供了一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如上所述的Kafka集群中的消息传输方法的步骤。
与现有技术相比,本发明实施例提供的Kafka集群中的消息传输方法及装置,可以使得大尺寸消息在传输过程中,既能保证集群吞吐量不会大幅降低,还可以使得集群各节点负载更均衡,系统资源更加有效利用。另外,本发明实施例利用分区算法加速了大尺寸消息的还原速度,提高了处理响应时间;另外,偏移量保存在集群节点处,也保证了当订阅方系统崩溃恢复后可以无需再从最开始处重复消费消息,只需从当前消费位置开始处理消息,可以避免重复消费,同时也保证了数据一致性,也大大降低了时间成本。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对本发明实施例的描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例的Kafka集群中的消息传输方法的一种流程示意图;
图2为本发明实施例的Kafka集群中的消息传输方法的另一种流程示意图;
图3为本发明实施例的Kafka集群中的消息传输方法的又一种流程示意图;
图4为本发明实施例的Kafka集群中的消息传输装置一种结构示意图;
图5为本发明实施例的Kafka集群中的消息传输装置的另一结构示意图。
具体实施方式
为使本发明要解决的技术问题、技术方案和优点更加清楚,下面将结合附图及具体实施例进行详细描述。在下面的描述中,提供诸如具体的配置和组件的特定细节仅仅是为了帮助全面理解本发明的实施例。因此,本领域技术人员应该清楚,可以对这里描述的实施例进行各种改变和修改而不脱离本发明的范围和精神。另外,为了清楚和简洁,省略了对已知功能和构造的描述。
应理解,说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此,在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外,这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。
在本发明的各种实施例中,应理解,下述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。
请参照图1,本发明实施例提供的一种Kafka集群中的消息传输方法,可以应用于Kafka集群中的客户端,如图1所示,所述Kafka集群中的消息传输方法包括:
S101,获取待发布消息的大小和主题。
这里,Kafka集群通常包括有多个节点(Broker),客户端可以提供节点(Broker)与消息的生产者(Producer)/消费者(consumer)者间的应用程序接口(API),实现相关功能。在本发明实施例中,客户端可以获取消息生产者(Producer)生产的待发布消息,并确定所述待发布消息的大小(size)以及主题(topic)。
S102,在所述待发布消息的大小超过预设尺寸的情况下,按照预设的分片基准值对所述待发布消息进行分割,得到所述待发布消息的多个消息片段,记录分割时间戳并为每个消息片段进行顺序编号。
这里,客户端可以根据所述待发布消息的大小是否超过预设尺寸(例如,10M比特),来判断是否需要对其进行分片处理割。其中,在所述待发布消息的大小超过预设尺寸时,则需要分片处理,此时,按照分片基准值将其分割成多个消息片段。例如,在所述待发布消息的大小能够被所述分片基准值整除时,所述多个消息片段的大小均为所述分片基准值;而在不能整除时,则最后一个消息片段的大小将小于所述分片基准值,其他消息片段的大小均为所述分片基准值。在切割得到多个消息片段时,还进一步为这些消息片段进行顺序编号,例如,第1个消息片段编号为1,接下来的消息顺序加1的方式进行编号。当然,起始编号也可以是其他约定好的数值,本发明实施例对此不做具体限定。另外,为了便于消息消费者确定消息的最后一个消息片段,可以对最后一个消息片段采用预先约定的结束编号(如EOF)。
本发明实施例在进行分割处理时,还记录分割时间戳,该分割时间戳可以参考分割开始时间或分割完成时间等来确定,最终确定所述待发布消息的唯一一个分割时间戳。该分割时间戳的精度可以根据CPU处理速度等因素来设置,例如,设置为毫秒级。例如,假设24小时制计时的时间为2018年5月22日的15:41:22:080,可以记录分割时间戳为20180522154122080。
另外,上述S102中的分片基准值可以是一个经验值,也可以是在Kafka集群上线后对其进行测试所获得的数值。具体的,可以通过发布不同大小的消息,分别测试所述Kafka集群在不同大小的消息下的集群吞吐量;根据集群吞吐量最大时的消息的大小,确定所述分片基准值。例如,测试所述Kafka集群在消息大小为X1的情况下的集群吞吐量,获得一个测试结果;测试所述Kafka集群在消息大小为X2的情况下的集群吞吐量,获得另一个测试结果;以此类推,测试所述Kafka集群在消息大小为Xn的情况下的集群吞吐量,获得另一个测试结果;然后,选择最大集群吞吐量对应的Xm作为所述分片基准值。这里,X1、X2……Xn表示按照逐渐增大或减小的消息大小。后续,如果Kafka集群的架构发生变化,如新增或减少了某些节点,还可以再次进行上述测试,根据测试结果,更新所述分片基准值。
需要说明的是,本发明实施例中,在所述待发布消息的大小未超过所述预设尺寸的情况下,可以按照Kafka集群通常的消息发布机制,无需消息分割,直接进行消息发布,为节约篇幅,此处不再详述。
S103,从所述多个消息片段的编号中随机选择一个目标编号,根据所述分割时间戳和目标编号,组合得到每个所述消息片段的分区关键字。
这里,为了保证后续目标分区的随机性,可以从所述多个消息片段的编号中随机选择一个目标编号,并与所述分割时间戳进行组合,得到每个所述消息片段的分区关键字。也就是说,所述待发布消息的所有消息片段都具有相同的分区关键字,从而可以保证在后续发布至同一分区。具体的组合方式可以是分割时间戳在前,目标编号在后的方式,也可以是目标编号在前,分割时间戳在后的方式。例如,分割时间戳为20180522154122080,目标编号为00025,则一种可能的分区关键字为2018052215412208000025。
需要说明的是,本发明实施例优选的采用分割时间戳与随机顺序号的方式组合得到消息片段的分区关键字。作为可替代的方式,还可以为待发布消息设置一个预定长度的消息序列号(如采用顺序号的方式表示),利用该消息序列号替换前面的分割时间戳进行组合,以得到分区关键字。
S104,在所述Kafka集群的目标节点的所述待发布消息的主题下的分区中,确定所述分区关键字对应的目标分区,将所述多个消息片段按照分片顺序发布至所述目标分区。
这里,Kafka集群通常包括有多个节点(Broker),在发布消息时,本发明实施例将待发布消息的所有消息片段发布至同一目标节点下的同一目标分区,所述同一目标分区是从所述待发布消息的主题下的所有分区中确定出的一个分区,具体的确定方式可以是,获取所述目标节点中所述待发布消息的主题所包含的分区数量;然后,利用所述目标分区关键字对所述分区数量进行取模运算,根据得到的余数确定所述分区关键字对应的目标分区。例如,余数为0,表示目标分区为分区0,余数为1表示目标分区为分区1,等等。然后,将所述消息片段发布至所述目标分区。由于所述待发布消息的所有消息片段都具有相同的分区关键字,从而这些消息片段都会按照分片顺序发布于所述目标节点的所述待发布消息的主题下的同一分区。另外,发布的消息片段中还包括有该消息片段的编号。
通过以上处理,本发明实施例可以为同一消息的所有片段设置相同的分区关键字,从而使得它们发布至目标节点的主题下的同一分区,保证了消息的数据完整性和一致性。
另外,现有技术在进行消息片段的发布时,通常将同一消息的多个消息片段发布至多个不同分区,且仅能够保证在同一分区下这些消息片段满足分片顺序,因此在消息消费者订阅该消息时,也仅能保证从同一分区获得的消息片段是满足分片顺序的,而从不同分区获得的消息片段则可能是乱序的,因此消费者需要在接收到所有的消息片段后再进行重排序。而本发明实施例的上述方案中,由于同一个消息的所有消息片段均按照分片顺序发布至同一分区,也有利于后续消息消费者在订阅该消息时,能够快速的将该消息的所有消息片段按照分片属性提供给消息消费者,消费者无需对消息片段进行重排序即可还原该消息进行消费,从而可以降低消息订阅的响应延迟。
以上方法的S104中,在确定所述分区关键字对应的目标分区之前,本发明实施例还可以进一步确定用于发布所述待发布消息的目标节点。具体的,可以获取所述Kafka集群中的节点的系统资源的使用状态,所述系统资源包括CPU资源、内存资源和磁盘资源中的至少一种。然后,根据所述节点的系统资源的使用状态,计算所述节点的可用资源评分,并选择出可用资源评分最高的节点,作为所述待发布消息发布的目标节点。通过以上方式,本发明实施例可以优先选择空闲资源较多的节点作为消息发布的目标节点,从而可以在集群节点间均衡的发布消息。
优选的,所述系统资源具体可以包括CPU资源、内存资源和磁盘资源。此时,可以根据所述权重值,对所述节点的CPU资源的空闲率指标、内存指标以及磁盘指标进行加权求和,得到所述节点的可用资源评分。作为一种实现方式,其中,所述内存指标可以通过所述待发布消息的大小与所述内存的空余量的比值来表示;所述磁盘指标可以通过所述待发布消息的大小与所述磁盘的空余量的比值来表示,或者通过空闲磁盘容量与磁盘总容量之间的比值来表示。
从以上所述可以看出,本发明实施例提供的上述Kafka集群中的消息传输方法,通过将同一消息的消息片段按照分片顺序发布至同一目标分区,保证了数据的完整性和一致性,并能够降低消息订阅的响应延迟。另外,本发明实施例还可以通过预先对Kafka集群在不同消息大小下的吞吐量的测试,设置合理的分片基准值,可以提高集群系统的吞吐量。另外,本发明实施例还通过选择空闲资源较多的节点作为消息发布的目标节点,可以使集群各节点间负载更加均衡,系统资源能够得到更加有效的利用。
接下来将从消息消费者侧进一步介绍本发明实施例在订阅消息时的消息传输流程。
请参照图2,本发明实施例提供了另一种Kafka集群中的消息传输方法,可以应用于消息消费者,如图2所示,该方法包括:
S201,从Kafka集群获取订阅的目标主题的消息。
这里,可以参考Kafka集群的消息订阅流程,订阅目标主题的消息,为节约篇幅,本文对此再进行详细说明。
S202,根据获取到的消息是否含有消息片段编号,判断当前获取的消息是否为大尺寸消息的消息片段,其中,所述Kafka集群中,超过预设尺寸的大尺寸消息的所有消息片段均按分片顺序发布于同一节点中所述大尺寸消息的主题下的同一分区。
这里,在获取到订阅的消息后,进一步确认该消息是否为某个大尺寸消息的消息片段。本发明实施例在发布大尺寸消息时会进行分割处理并为消息片段进行编号,并且针对同一消息的所有消息片段,均按分片顺序发布于同一节点的所述目标主题下的同一分区。因此,可以根据获取到的消息是否含有消息片段编号,判断当前获取的消息是否为目标消息的消息片段。
需要说明的是,本发明实施例中,在获取到的消息不是某个大尺寸消息的消息片段时,表明该消息是一个正常大小的消息,此时可以直接开始消费处理该消息。
S203,在当前获取的消息为消息片段时,继续订阅所述目标主题的消息直至获取到所述大尺寸消息的最后一个消息片段。
这里,在当前获取的消息为消息片段时,可以按照Kafka集群的消息订阅流程,订阅继续订阅所述目标主题的消息,这样在每收到一个消息片段后,判断该消息片段是否为所述目标消息的最后一个消息片段。具体的,可以根据消息片段的编号方式进行判断,例如,在最后一个消息片段采用预先约定的结束编号时,可以根据消息片段编号是否为所述结束编号(如EOF)来进行判断。
S204,根据订阅到的所述大尺寸消息的所有消息片段,还原并消费所述大尺寸消息。
这里,由于同一消息的所有消息片段,是按分片顺序发布于同一节点的所述目标主题下的同一分区,因此,订阅获得的消息片段也是按照分片顺序的先后逐个获得,保证了消息片段之间满足原始的分片属性,从而可以在获取到目标消息的所有消息片段后,不需要重新排序,即可直接还原所述目标消息并进行消费。
可以看出,本发明实施例可以按照Kafka集群的订阅方式订阅获得同一消息的所有片段,然后直接还原该消息并进行消费,由于不需要对消息片段进行重排序,因此可以加快大尺寸消息的还原速度,降低了处理响应时间。
更进一步的,本发明实施例在在获取订阅的目标主题的消息之后,还可以将获取到的消息的偏移量更新至所述消息所在的目标节点;从而在消费者订阅过程发生故障(如系统宕机崩溃)的情况下,在重启订阅所述目标主题的消息时,从所述目标节点获取所述偏移量,并根据所述偏移量继续订阅并消费所述目标主题的消息。这样,本发明实施例不需要再从最开始处重复消费消息,只需从当前消费位置开始处理消息,避免了重复消费的同时,保证了数据一致性,也大大降低了时间成本。
以上分别从客户端侧和消费者侧描述了本发明实施例的消息传输方法。下面将进一步结合附图3给出的一个示例,通过客户端、节点以及消费者之间的交互流程,对以上各个方法实施例作进一步的介绍。
用户在传输消息前,可以在Kafka集群进行吞吐量测试,比较Kafka集群在发布不同尺寸大小的消息时的集群吞吐量,将集群吞吐量最大时的消息大小作为大尺寸消息分片的分片基准值,以此分片基准值对大尺寸消息进行分割。例如,在Kafka集群中进行吞吐量测试,比较Kafka集群在发布不同尺寸大小的消息时的集群吞吐量,测试用的消息的大小从1k比特到1M比特。将集群吞吐量最大时的消息大小(如10k比特)作为大尺寸消息分片的分片基准值,以此基准值对大尺寸消息进行分割。
在本示例中,以用户需要利用Kafka集群发布订阅一份XML文件为例进行说明,假设该文件大小为100M比特。本发明实施例提供的消息传输方法(可以简称为大尺寸消息传输技术)可以用来进行消息分割,同一消息的所有消息片段在同一分区的分发,保证了数据的完整性和一致性并降低响应延迟,同时保存消息消费偏移量,可以保证了消费者从宕机状态恢复后无重复消费,提高系统的性能也提高了效率。以下具体说明本示例的流程:
S300,客户端实时监控Kafka集群中各个节点(Broker)的资源使用状况,这些资源可以包括CPU资源、内存资源和磁盘资源。其中,CPU资源用于运算处理,内存资源通常用于保存运算处理时的相关数据,磁盘资源通常用于保存消息生产者产生的消息。
S301,在客户端处准备好待发布的消息(100M的XML文件)以及确定消息主题。
S302,根据消息的大小确定待处理的消息为大尺寸的消息,这就需要根据分片基准值对此消息进行分割,此时进入S303。
S303,对大尺寸消息的分割流程如下:
1)记录当前分割时间戳T,T的单位精确到毫秒(如:20180522154122080)。
2)读取XML文件并按照分片基准值进行分割,分割后对每个片段进行编号(如片段1:00001,片段2:00002……),直至最后一个片段编号,这里最好一个片段编号为EOF。
S304,根据各个节点的资源使用状况,选择用于发布上述消息的备选节点,备选节点的选取流程如下:
1)获取Kafka集群中每台节点(Broker)的资源使用状况。
2)对每个节点,例如,首先为CPU、内存和磁盘设定各自的权重比,设定的原则为三者(CPU、内存和磁盘)权重值之和为1。作为一种优选方式,可以设置内存权重等于磁盘权重,且内存权重和磁盘权重均大于CPU权重。
3)根据CPU、内存和磁盘的权重比,消息大小以及当前节点资源使用状况,计算出节点得分。
具体的,可以将大尺寸消息的大小和空余内存的比值与内存权重的乘积作为当前节点可用内存得分;将大尺寸消息和空余磁盘的比值与磁盘权重的乘积作为当前节点可用磁盘得分;将空闲CPU与CPU权重的乘积作为当前节点CPU得分;然后将这3个得分相加作为本节点的当前可以资源评分的分值。
4)对Kafka集群的其他节点也计算出各自节点得分,算法与上一步相同。
5)比较所有节点的得分,根据分值大小选出发布订阅本消息的备选节点。通常可以选择分值最大的节点。
S305~S306,在选取备选节点后,将消息片段分发到此节点下该大尺寸消息的消息主题的分区中,分发过程如下:
1)取得此大尺寸消息分割后的消息片段数目,假设消息片段的数目为num。
2)在总的消息片段数目范围内取一随机数(这里用randnum表示该随机数),并与消息分割时间戳组合在一起作为此消息所有消息片段的分区关键字(key),即randnum=rand(0,num),key=Long(T+randnum)。
3)在备选节点取得消息主题下拥有的分区数目,假设为Parno。
4)利用分区关键字(key)对分区数目取余数,取得的余数即为所有消息片段在此节点下的分区位置,所有的消息片段都分发到此分区中。即,待发布的目标分区的编号Par的计算方式为:Par=key mod Parno。
通过以上步骤,可以将大尺寸消息的各个消息片段按照分割顺序,逐个发布至同一备选节点的同一分区中。
接下来介绍消息订阅流程,具体流程如下:
S307,订阅方(消费者)按照Kafka集群的消息订阅机制,订阅消息。
S308,订阅方获取到订阅的消息后,更新消费偏移量,将更新后的消费偏移量发送到Kafka集群节点保存。
在上述过程中,订阅方可以持续不断的从集群中消费消息,并更新消费偏移量。
S309,根据订阅到的消息中是否存在消息片段编号,确定该消息是否为大尺寸消息的消息片段。在该消息为大尺寸消息的消息片段时,进入S310;在该消息为未超过预设尺寸的正常的普通消息时,进入S311
S310,在该消息为大尺寸消息的消息片段时,继续订阅下一条消息,直至最后一个消息片段,然后还原出大尺寸消息。这里,由于Kafka集群中发布的大尺寸消息在同一个分区中是有序,当订阅方当消费到最后一个消息片段时,无需重新排序直接将所有的消息片段组合在一起即可将原始大尺寸消息还原。
S311,订阅方消费还原后的大尺寸消息或者消费尺寸未超过预设尺寸的正常消息。
从以上示例可以看出,本发明实施例的消息传输方法,其分片规则以及节点选取算法,可以使得大尺寸消息在传输过程中,既能保证集群吞吐量不会大幅降低,还可以使得集群各节点负载更均衡,系统资源更加有效利用。同时,本发明实施例利用分区算法加速了大尺寸消息的还原速度,提高了处理响应时间;另外,偏移量保存在集群节点处,也保证了当订阅方系统崩溃恢复后可以无需再从最开始处重复消费消息,只需从当前消费位置开始处理消息,可以避免重复消费,同时也保证了数据一致性,也大大降低了时间成本。
基于以上方法,本发明实施例还提供了实施上述方法的设备,请参照图4,本发明实施例提供了一种Kafka集群中的消息传输装置400,可以应用Kafka集群的客户端,如图4所示,该消息传输装置400包括:
消息获取单元401,用于获取待发布消息的大小和主题;
分片处理单元402,用于在所述待发布消息的大小超过预设尺寸的情况下,按照预设的分片基准值对所述待发布消息进行分割,得到所述待发布消息的多个消息片段,记录分割时间戳并为每个消息片段进行顺序编号;
关键字组合单元403,用于从所述多个消息片段的编号中随机选择一个目标编号,根据所述分割时间戳和目标编号,组合得到每个所述消息片段的分区关键字;
分片发布单元404,用于在所述Kafka集群的目标节点的所述待发布消息的主题下的分区中,确定所述分区关键字对应的目标分区,将所述多个消息片段按照编号顺序发布至所述目标分区。
优选的,上述消息传输装置400还包括:
分片基准确定单元(图中未示出),用于通过发布不同大小的消息,分别测试所述Kafka集群在不同大小的消息下的集群吞吐量;根据集群吞吐量最大时的消息的大小,确定所述分片基准值。
优选的,上述消息传输装置400还包括:
目标节点确定单元(图中未示出),用于获取所述Kafka集群中的节点的系统资源的使用状态,所述系统资源包括CPU资源、内存资源和磁盘资源中的至少一种;根据所述节点的系统资源的使用状态,计算所述节点的可用资源评分,并选择出可用资源评分最高的节点,作为所述待发布消息发布的目标节点。
这里,所述系统资源包括CPU资源、内存资源和磁盘资源。优选的,所述目标节点确定单元,还用于获取预先设定的CPU资源、内存资源和磁盘资源各自的权重值;根据所述权重值,对所述节点的CPU资源的空闲率指标、内存指标以及磁盘指标进行加权求和,得到所述节点的可用资源评分,其中,所述内存指标通过所述待发布消息的大小与所述内存的空余量的比值来表示,所述磁盘指标通过所述待发布消息的大小与所述磁盘的空余量的比值来表示。
优选的,所述分片发布单元404,还用于获取所述目标节点中所述待发布消息的主题所包含的分区数量;利用所述目标分区关键字对所述分区数量进行取模运算,根据得到的余数确定所述分区关键字对应的目标分区。
优选的,所述分片处理单元404,还用于在为每个消息片段进行顺序编号时,进一步对所述待发布消息的最后一个消息片段采用预先约定的结束编号。
请参照图5,本发明实施例提供了另一种Kafka集群中的消息传输装置500,用于实现图2所示的方法,如图5所示,该消息传输装置500包括:
消息获取单元501,用于从Kafka集群的目标节点获取订阅的目标主题的消息;
消息片段判断单元502,用于根据获取到的消息是否含有消息片段编号,判断当前获取的消息是否为大尺寸消息的消息片段,其中,所述Kafka集群中,超过预设尺寸的大尺寸消息的所有消息片段均按分片顺序发布于同一节点中所述大尺寸消息的主题下的同一分区;
消息片段处理单元503,用于在当前获取的消息为消息片段时,继续订阅所述目标主题的消息直至获取到所述大尺寸消息的最后一个消息片段;
消息片段还原单元504,用于根据订阅到的所述大尺寸消息的所有消息片段,还原并消费所述大尺寸消息。
优选的,该消息传输装置500还可以包括:
偏移量更新单元(图中未示出),用于将当前获取到的消息的偏移量更新至所述目标节点;
重启订阅单元(图中未示出),用于在重启订阅所述目标主题的消息时,从所述目标节点获取所述偏移量,并根据所述偏移量继续订阅并消费所述目标主题的消息。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到各种等效的修改或替换,这些修改或替换都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以权利要求的保护范围为准。
Claims (9)
1.一种Kafka集群中的消息传输方法,其特征在于,包括:
获取待发布消息的大小和主题;
在所述待发布消息的大小超过预设尺寸的情况下,按照预设的分片基准值对所述待发布消息进行分割,得到所述待发布消息的多个消息片段,记录分割时间戳并为每个消息片段进行顺序编号,其中,在所述待发布消息的大小能够被所述分片基准值整除时,所述多个消息片段的大小均为所述分片基准值;而在不能整除时,则最后一个消息片段的大小将小于所述分片基准值,其他消息片段的大小均为所述分片基准值,并对最后一个消息片段采用预先约定的结束编号;
从所述多个消息片段的编号中随机选择一个目标编号,根据所述分割时间戳和目标编号,组合得到每个所述消息片段的分区关键字;
在所述Kafka集群的目标节点的所述待发布消息的主题下的分区中,确定所述分区关键字对应的目标分区,将所述多个消息片段按照编号顺序发布至所述目标分区。
2.如权利要求1所述的方法,其特征在于,在获取待发布消息的大小和主题之前,所述方法还包括:
通过发布不同大小的消息,分别测试所述Kafka集群在不同大小的消息下的集群吞吐量;
根据集群吞吐量最大时的消息的大小,确定所述分片基准值。
3.如权利要求1所述的方法,其特征在于,在确定所述分区关键字对应的目标分区之前,所述方法还包括:
获取所述Kafka集群中的节点的系统资源的使用状态,所述系统资源包括CPU资源、内存资源和磁盘资源中的至少一种;
根据所述节点的系统资源的使用状态,计算所述节点的可用资源评分,并选择出可用资源评分最高的节点,作为所述待发布消息发布的目标节点。
4.如权利要求3所述的方法,其特征在于,所述系统资源包括CPU资源、内存资源和磁盘资源;计算所述节点的可用资源评分的步骤,包括:
获取预先设定的CPU资源、内存资源和磁盘资源各自的权重值;
根据所述权重值,对所述节点的CPU资源的空闲率指标、内存指标以及磁盘指标进行加权求和,得到所述节点的可用资源评分,其中,所述内存指标通过所述待发布消息的大小与所述内存的空余量的比值来表示,所述磁盘指标通过所述待发布消息的大小与所述磁盘的空余量的比值来表示。
5.如权利要求1所述的方法,其特征在于,确定所述分区关键字对应的目标分区的步骤,包括:
获取所述目标节点中所述待发布消息的主题所包含的分区数量;
利用所述目标分区关键字对所述分区数量进行取模运算,根据得到的余数确定所述分区关键字对应的目标分区。
6.如权利要求1所述的方法,其特征在于,在为每个消息片段进行顺序编号时,进一步对所述待发布消息的最后一个消息片段采用预先约定的结束编号。
7.一种Kafka集群中的消息传输装置,其特征在于,包括:
消息获取单元,用于获取待发布消息的大小和主题;
分片处理单元,用于在所述待发布消息的大小超过预设尺寸的情况下,按照预设的分片基准值对所述待发布消息进行分割,得到所述待发布消息的多个消息片段,记录分割时间戳并为每个消息片段进行顺序编号,其中,在所述待发布消息的大小能够被所述分片基准值整除时,所述多个消息片段的大小均为所述分片基准值;而在不能整除时,则最后一个消息片段的大小将小于所述分片基准值,其他消息片段的大小均为所述分片基准值,并对最后一个消息片段采用预先约定的结束编号;
关键字组合单元,用于从所述多个消息片段的编号中随机选择一个目标编号,根据所述分割时间戳和目标编号,组合得到每个所述消息片段的分区关键字;
分片发布单元,用于在所述Kafka集群的目标节点的所述待发布消息的主题下的分区中,确定所述分区关键字对应的目标分区,将所述多个消息片段按照编号顺序发布至所述目标分区。
8.如权利要求7所述的消息传输装置,其特征在于,还包括:
分片基准确定单元,用于通过发布不同大小的消息,分别测试所述Kafka集群在不同大小的消息下的集群吞吐量;根据集群吞吐量最大时的消息的大小,确定所述分片基准值。
9.如权利要求7所述的消息传输装置,其特征在于,还包括:
目标节点确定单元,用于获取所述Kafka集群中的节点的系统资源的使用状态,所述系统资源包括CPU资源、内存资源和磁盘资源中的至少一种;根据所述节点的系统资源的使用状态,计算所述节点的可用资源评分,并选择出可用资源评分最高的节点,作为所述待发布消息发布的目标节点。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811319985.9A CN111163118B (zh) | 2018-11-07 | 2018-11-07 | 一种Kafka集群中的消息传输方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811319985.9A CN111163118B (zh) | 2018-11-07 | 2018-11-07 | 一种Kafka集群中的消息传输方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111163118A CN111163118A (zh) | 2020-05-15 |
CN111163118B true CN111163118B (zh) | 2023-04-07 |
Family
ID=70555425
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811319985.9A Active CN111163118B (zh) | 2018-11-07 | 2018-11-07 | 一种Kafka集群中的消息传输方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111163118B (zh) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112269661B (zh) * | 2020-10-30 | 2022-04-15 | 上海哔哩哔哩科技有限公司 | 基于Kafka集群的分区迁移方法和装置 |
CN115242787B (zh) * | 2022-07-22 | 2023-09-05 | 恒生电子股份有限公司 | 消息处理系统及方法 |
CN116132395A (zh) * | 2022-11-15 | 2023-05-16 | 马上消费金融股份有限公司 | 消息处理方法、电子设备及计算机可读存储介质 |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104519090A (zh) * | 2013-09-27 | 2015-04-15 | 深圳市腾讯计算机系统有限公司 | 文件传输方法及装置 |
CN105912628A (zh) * | 2016-04-07 | 2016-08-31 | 北京奇虎科技有限公司 | 主从数据库的同步方法及装置 |
CN106648904A (zh) * | 2017-01-09 | 2017-05-10 | 大连理工大学 | 一种流式数据处理自适应速率控制方法 |
CN106649766A (zh) * | 2016-12-27 | 2017-05-10 | 北京锐安科技有限公司 | 一种基于kafka的消息处理方法 |
CN106776855A (zh) * | 2016-11-29 | 2017-05-31 | 上海轻维软件有限公司 | 基于Spark Streaming读取Kafka数据的处理方法 |
CN106817295A (zh) * | 2016-12-08 | 2017-06-09 | 努比亚技术有限公司 | 一种消息处理装置和方法 |
CN106953901A (zh) * | 2017-03-10 | 2017-07-14 | 重庆邮电大学 | 一种提高消息传递性能的集群通信系统及其方法 |
CN107220123A (zh) * | 2017-05-25 | 2017-09-29 | 郑州云海信息技术有限公司 | 一种解决Spark数据倾斜方法及系统 |
CN107666516A (zh) * | 2017-09-20 | 2018-02-06 | 重庆邮电大学 | 一种基于消息热度保证kafka集群数据一致性的方法 |
CN108647329A (zh) * | 2018-05-11 | 2018-10-12 | 中国联合网络通信集团有限公司 | 用户行为数据的处理方法、装置及计算机可读存储介质 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10496283B2 (en) * | 2016-01-22 | 2019-12-03 | Suraj Prabhakar WAGHULDE | Adaptive prefix tree based order partitioned data storage system |
-
2018
- 2018-11-07 CN CN201811319985.9A patent/CN111163118B/zh active Active
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104519090A (zh) * | 2013-09-27 | 2015-04-15 | 深圳市腾讯计算机系统有限公司 | 文件传输方法及装置 |
CN105912628A (zh) * | 2016-04-07 | 2016-08-31 | 北京奇虎科技有限公司 | 主从数据库的同步方法及装置 |
CN106776855A (zh) * | 2016-11-29 | 2017-05-31 | 上海轻维软件有限公司 | 基于Spark Streaming读取Kafka数据的处理方法 |
CN106817295A (zh) * | 2016-12-08 | 2017-06-09 | 努比亚技术有限公司 | 一种消息处理装置和方法 |
CN106649766A (zh) * | 2016-12-27 | 2017-05-10 | 北京锐安科技有限公司 | 一种基于kafka的消息处理方法 |
CN106648904A (zh) * | 2017-01-09 | 2017-05-10 | 大连理工大学 | 一种流式数据处理自适应速率控制方法 |
CN106953901A (zh) * | 2017-03-10 | 2017-07-14 | 重庆邮电大学 | 一种提高消息传递性能的集群通信系统及其方法 |
CN107220123A (zh) * | 2017-05-25 | 2017-09-29 | 郑州云海信息技术有限公司 | 一种解决Spark数据倾斜方法及系统 |
CN107666516A (zh) * | 2017-09-20 | 2018-02-06 | 重庆邮电大学 | 一种基于消息热度保证kafka集群数据一致性的方法 |
CN108647329A (zh) * | 2018-05-11 | 2018-10-12 | 中国联合网络通信集团有限公司 | 用户行为数据的处理方法、装置及计算机可读存储介质 |
Non-Patent Citations (2)
Title |
---|
"A_study_of_a_video_analysis_framework_using_Kafka_and_spark_streaming";Ayae Ichinose;《2017 IEEE International Conference on Big Data (Big Data)》;20180126;全文 * |
"基于Kafka的大规模流数据分布式缓存与分析平台";牛牧;《中国优秀硕士学位论文全文数据库 信息科技辑》;20170331;全文 * |
Also Published As
Publication number | Publication date |
---|---|
CN111163118A (zh) | 2020-05-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111813513B (zh) | 基于分布式的实时任务调度方法、装置、设备及介质 | |
CN106953901B (zh) | 一种提高消息传递性能的集群通信系统及其方法 | |
CN111163118B (zh) | 一种Kafka集群中的消息传输方法及装置 | |
CN110096336B (zh) | 数据监控方法、装置、设备和介质 | |
CN110648178A (zh) | 一种增加kafka消费能力的方法 | |
CN113452774B (zh) | 消息推送方法、装置、设备及存储介质 | |
CN113282604B (zh) | 基于消息队列实现的高可用时序数据库集群系统 | |
CN111240901A (zh) | 分布式块存储系统的节点动态扩展系统、方法及设备 | |
CN113326150A (zh) | 一种联机小批量消息处理方法和装置 | |
Huang et al. | Load balancing for clusters of VOD servers | |
CN113760498A (zh) | 消息消费方法、装置、电子设备和计算机可读介质 | |
CN111158931A (zh) | 一种针对Kafka分区的数据动态均衡方法、装置及存储介质 | |
CN110728372A (zh) | 一种人工智能模型动态加载的集群设计方法及集群架构 | |
US7260611B2 (en) | Multi-leader distributed system | |
CN112054926B (zh) | 集群管理方法、装置、电子设备及存储介质 | |
CN113986962A (zh) | 排行榜生成方法、装置、设备及存储介质 | |
CN113347238A (zh) | 基于区块链的消息分区方法及系统、设备、存储介质 | |
CN111638980A (zh) | 基于内存映射的消息处理方法、装置、系统和存储介质 | |
CN111641874A (zh) | 一种分布式计算方法、系统、及可读存储介质 | |
CN110839083A (zh) | 话单推送方法及装置 | |
CN116166451B (zh) | 一种主题数量的动态调节方法、系统、装置及存储介质 | |
Priovolos et al. | Escape: Elastic caching for big data systems | |
Raj et al. | Enhancing File Recovery from Distributed File Systems (DFSs) Using Erasure Coding and Replication | |
CN116112570A (zh) | 消息处理方法、装置、电子设备与存储介质 | |
CN114942829A (zh) | 一种分布式存储时延优化方法、装置及介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |