CN110113420A - 基于nvm的分布式消息队列管理系统 - Google Patents
基于nvm的分布式消息队列管理系统 Download PDFInfo
- Publication number
- CN110113420A CN110113420A CN201910381138.3A CN201910381138A CN110113420A CN 110113420 A CN110113420 A CN 110113420A CN 201910381138 A CN201910381138 A CN 201910381138A CN 110113420 A CN110113420 A CN 110113420A
- Authority
- CN
- China
- Prior art keywords
- message
- file
- server
- rdma
- nvm
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- 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/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- 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)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开一种基于NVM的分布式消息队列管理系统,采用基于主题的发布订阅模式,设置有生产者机器、消费者机器、消息服务器集群和集群管理器,每个机器上均配置了NVM存储器和RDMA网卡,且通过RDMA网络互联;其效果是:可绕过复杂的I/O软件栈,通过进程的虚拟地址访问消息数据,可以通过访问支持随机读取的消息元数据完成对消息数据的访问,同时基于RDMA单边操作传输消息,直接读写远端服务器内存中的消息数据,无需任何多余的数据拷贝,实现数据高吞吐量、低延迟的消息传输,通过主题分区机制保证远程消息写入的无锁化,并在远程消息写入过程中,采用了基于消息生产速度、消息传输速度自适应的消息批处理策略,降低传输延迟,提升传输带宽。
Description
技术领域
本发明涉及计算机数据存储技术,更具体地说,是一种基于NVM的分布式消息队列管理系统。
背景技术
消息队列,也称作消息中间件,是消息传递过程中保存消息的容器,是分布式系统中的重要组件,主要解决应用解耦,异步消费等问题。提供消息持久化机制,保证消息能够正确接收,保证消息在突发情况下不会丢失,保证消息能够被异步消费,从而使服务器能够应对大吞吐量的消息处理场景。
现有的消息队列将消息存放在消息服务器的内存或者硬盘中,采用传统的TCP/IP网络传输数据。存放在内存中可以保证对消息的实时处理和快速存取,但是因为内存容量有限,而且掉电之后数据无法恢复,消息队列的可靠性无法得到保证;而硬盘本身就是低速设备,存取数据时还需要经过复杂的I/O软件栈,无法保证快速的数据读写;传统以太网传输带宽低、延迟大,无法有效满足大数据时代低时延、高吞吐量的需求。现有的消息队列,无法兼顾消息持久化和高吞吐量。
发明内容
针对现有技术中存在的问题,近年来出现的新型存储与网络技术带来了突破此困境的机遇。一方面,新型的非易失存储器(Non-Volatile Memory,NVM)具有内存级的读写速度和可按字节寻址等优点;另一方面,远程内存直接存取技术(Remote Direct MemmoryAccess,RDMA)可以直接读写远端内存,不需要占用远端服务器的CPU。
有鉴于此,本发明提出一种基于NVM的分布式消息队列管理系统,通过使用基于主题的发布订阅模式,实现支持推模式和拉模式消费。
为了实现上述目的,本发明所采用的具体技术方案如下:
一种基于NVM的分布式消息队列管理系统,其关键在于:设置有生产者机器、消费者机器、消息服务器集群和集群管理服务器,每个机器上均配置了NVM存储器和RDMA网卡,且通过RDMA网络互联;
所述生产者机器,用于通过生产者进程将消息写入本地消息存储模块中,并通过代理进程按照一定的策略将消息发往消息服务器;
所述消费者机器,用于运行消费者进程,负责消费消息服务器中的消息;
所述消息服务器集群中包括多个消息服务器(Broker),每个消息服务器用于接收生产者发来的消息,持久化存储消息并将消息发往有订阅关系的消费者;
所述集群管理服务器(Manager),用于配置订阅关系,保存消息服务器集群的基本信息,负责消息服务器的灾备控制,保证消息服务器集群负载均衡,确保消息队列的健康运行。
可选地,系统使用主题分区机制,同一个主题可分为多个分区,消息的生产和消费过程按分区进行,单个分区内的消息按序排列,消息队列对所有消息文件都做了冗余备份,分别定义为主分区和备份分区,主分区参与消费流程,备份分区作为冷备份存放在非主分区所在的消息服务器上。
可选地,系统数据流程包括以下四种:
(1)消息发布流程:用于实现生产者机器上的生产者进程调用API生产某主题某分区的消息并存放在本地的消息存储模块中,还用于实现生产者机器上的传输代理进程将消息传输到主分区所在消息服务器;
(2)消息备份流程:主分区所在消息服务器上的传输代理进程将消息推送至第0备份分区所在消息服务器,第0备份分区所在消息服务器的传输代理将消息推送至第1备份分区所在消息服务器;
(3)推模式消费流程;主分区所在服务器的传输代理将消息推送至订阅了该分区的消费者所在服务器的消息存储模块中,消费者随后再从消息存储模块中读取消息;
(4)拉模式消费流程;消费者主动从主分区所在服务器的消息存储模块中拉取消息。
可选地,所述消息发布流程、消息备份流程以及推模式消费流程属于远程消息写入,所述拉模式消费流程属于远程消息读取,消息的写入和读取采用共享内存方式实现。
可选地,系统采用新型非易失存储设备,并在存储模块中设置有消息文件和元数据文件且建立了两个键值存储结构用于记录每个消息文件包含的消息数和消息文件大小,所述消息文件和元数据文件一一对应且分开保存,其中消息文件用于存放消息实体数据,元数据文件用于存放每条消息的描述信息,包括消息大小、在消息文件内的偏移,消息生成时间。消息文件和元数据文件本质是共享NVM内存,可映射在进程的虚拟地址空间,通过虚拟地址访问数据。
可选地,在消息写入过程中,包括写入消息文件、写入元数据文件以及计算并更新消息数量和消息文件大小键值存储结构三个步骤,同一个主题分区同时只运行一个生产者进程进行写入操作,如果存在两个生产者进程都在生成某一个主题的消息时,则为其分配不同的主题分区。
可选地,更新键值存储结构中消息文件大小、消息文件内消息数量是后台线程通过滑动检测点检测元数据文件中的元数据项计算出的。
可选地,每个机器上均配置了消息传输模块,所述消息传输模块包括消息偏移管理模块、运行在生产者机器上的传输代理进程、运行在消息服务器上的传输代理进程、运行在消息服务器和消费者机器上的服务进程。
可选地,系统将远端文件映射的地址注册至RDMA网卡,本端在获取到远端文件的映射地址和注册信息后,通过计算偏移的方式利用RDMA网络读写远端文件,且消息发布流程、推模式消费流程、消息备份流程是通过RDMA WRITE单边操作完成的,且采用消息批处理机制,一次性发送当前未发送的消息。拉模式消费流程通过RDMA READ单边操作完成。
本发明的显著效果是:
(1)系统基于NVM的高性能消息存储系统,可绕过复杂的I/O软件栈,通过进程的虚拟地址访问消息数据,可以通过访问支持随机读取的消息元数据完成对消息数据的访问。
(2)系统基于RDMA单边操作传输消息,直接读写远端服务器NVM内存中的消息数据,无需任何多余的数据拷贝,实现数据高吞吐量、低延迟的消息传输。
(3)系统通过主题分区机制保证远程消息写入的无锁化。
(4)在远程消息写入过程中,采用了基于消息生产速度、消息传输速度自适应的消息批处理策略,降低传输延迟,提升传输带宽。
附图说明
下面将结合附图及实施例对本发明作进一步说明,附图中:
图1为本发明的系统架构图;
图2为本发明的系统数据流向示意图;
图3为本发明具体实施例中的消息存储模块逻辑结构图;
图4为本发明具体实施例中的共享内存原理框图;
图5为本发明具体实施例中的消息文件与元数据文件关系图;
图6为本发明具体实施例中的消息写操作原理框图;
图7为本发明具体实施例中的滑动检测原理图;
图8为本发明具体实施例中的消息传输模块架构图;
图9为本发明具体实施例中的RDMA WRITE消息传输机制原理图;
图10为本发明具体实施例中的RDMA READ消息传输机制原理图;
图11为本发明具体实施例中的远程写冲突规避机制原理图;
图12为本发明具体实施例中的消息批处理原理图;
图13为本发明具体实施例中消息发布流程图;
图14为本发明具体实施例中消息推模式控制流程图;
图15为本发明具体实施例中消息拉模式控制流程图。
具体实施方式
为了使本发明要解决的技术问题、技术方案和优点更加清楚,下面将结合附图及具体实施例进行详细描述,应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
如图1所示,本发明提出的一种基NVM的分布式消息队列管理系统,设置有生产者机器、消费者机器、消息服务器集群和集群管理服务器,每个机器上均配置了NVM存储器和RDMA网卡,且通过RDMA网络互联;
所述生产者机器,用于通过生产者进程将消息写入本地消息存储模块中,并通过代理进程按照一定的策略将消息发往消息服务器;
所述消费者机器,用于运行消费者进程,负责消费消息服务器中的消息;
所述消息服务器集群中包括多个消息服务器(Broker),每个消息服务器用于接收生产者发来的消息,持久化存储消息并将消息发往有订阅关系的消费者;
所述集群管理服务器(Manager),用于配置订阅关系,保存消息服务器集群的基本信息,负责消息服务器的灾备控制,保证消息服务器集群负载均衡,确保消息队列的健康运行。
在具体实施时,系统使用主题(Topic)的概念,Topic即某一类消息的抽象集合,系统支持Topic分区,同一个Topic可分为多个分区(Partition,简称P),用作横向扩展,如图2中Topic0_P0和Topic0_P1都属于Topic0的分区,生产、消费过程按Partition进行,单Partition内保证消息的绝对有序。每个Topic Partition都包含多个消息文件,存放在消息存储模块中。同一个Topic Partition可以被多个消费者订阅,系统对所有的消息文件都做了冗余备份,分别定义为主分区(Partition leader)和备份分区(Partitionfollower),主分区参与消费流程,备份分区作为冷备份存放在非主分区所在的消息服务器上。系统数据流程包括以下四种:
(1)消息发布流程:用于实现生产者机器上的生产者进程调用API生产某主题某分区的消息并存放在本地的消息存储模块中,还用于实现生产者机器上的传输代理进程将消息传输到主分区所在消息服务器;
(2)消息备份流程:主分区所在消息服务器上的传输代理进程将消息推送至第0备份分区所在消息服务器,第0备份分区所在消息服务器的传输代理将消息推送至第1备份分区所在消息服务器;
(3)推模式消费流程;适用于消费者处理速度快的情况,在推模式中,主分区所在服务器的传输代理将消息推送至订阅了该分区的消费者所在服务器的消息存储模块中,消费者随后再从消息存储模块中读取消息;
(4)拉模式消费流程;适用于消费者处理速度慢的情况,在拉模式中,消费者主动从主分区所在服务器的消息存储模块中拉取消息。
这四种数据流程又分为两大类:远程消息写入和远程消息读取。消息发布流程、消息备份流程、推模式消费流程属于远程消息写入。拉模式消费属于远程消息读取。
如图3所示,本发明采用新型非易失存储设备,以文件的形式持久化保存消息,将消息数据和消息描述信息(本文后面称为消息元数据)分开保存,通过查看消息元数据信息查找消息数据。存储模块中有消息文件和元数据文件两种文件,消息文件中存放着消息实体数据,元数据文件中存放每条消息的描述信息,包括消息大小、消息在消息文件内偏移、消息生产时间等。每个消息文件和元数据文件的大小固定,可自行配置,通常情况下,元数据文件小于消息文件。具体实施时,消息文件的命名方式为Topic_P-date-index.log,其中Topic_P为Topic Partition名,date为当前日期,index为文件id,从0开始递增,代表该Partition当天的第几个文件,消息文件存放在log/topic目录下。与消息文件对应,存在着同名的元数据文件,元数据文件的后缀为.meta,存放在meta/topic目录下。存储模块中建立了两个键值存储结构记录每个消息文件包含的消息数和消息文件大小,分别以消息文件名Topic_P-date-index为key,以消息文件中消息数量counts为value;以Topic_P-date-index为key,以消息文件大小size为value。
在本系统中,消息文件需要被写入进程写入,被读取进程读取,这两个进程通常情况下还是一起工作的,Linux系统提供了共享内存(shm)机制,所谓共享内存,就是允许把同一块内存分别映射在不同进程的地址空间,如图4所示,进程1可以即时看到进程2对共享内存中数据的更新,反之亦然。本系统将NVM物理空间作为共享NVM内存池,每一个消息文件和元数据文件本质上都是一段共享NVM内存,将共享NVM内存映射在进程的虚拟地址空间后,可以通过虚拟地址访问数据,避免复杂的I/O软件栈。
共享内存的具体实施是主要包括以下4个系统调用函数:
①创建共享内存int shmget(key_t key,size_t size,int shmflg);
第一个参数是共享内存段的命名;
第二个参数是需要创建的共享内存容量;
第三个是权限标志;
shmget函数成功时返回一个与key相关的共享内存标识符shm_id。
②将共享内存映射在进程的地址空间void*shmat(int shm_id,const void*shm_addr,int shmflg);
第一个参数是由shmget函数返回的共享内存标识;
第二个参数是指定共享内存映射到当前进程中的地址位置,通常为空,表示让系统来选择共享内存的地址;
第三个参数,shm_flg是一组标志位,通常为0;
调用成功后返回映射空间的首地址。
③将共享内存总当前进程中分离int shmdt(const void*shmaddr);
该函数用于将共享内存从当前进程中分离。注意,将共享内存分离并不是删除它,只是使该共享内存对当前进程不再可用。
④控制共享内存int shmctl(int shm_id,int command,struct shmid_ds*buf);例如更改共享内存的关联值,删除共享内存段等。
消息文件和元数据文件大小固定,当写满后需要创建新的文件时,分别对新的消息文件名和元数据名取hash值,并作为参数调用Linux共享内存函数shmget,获取到对应的共享内存标识符shm_id,当进程需要访问消息文件和元数据文件时调用shmat函数即可映射在进程的虚拟地址空间,通过访问返回的地址就可以完成数据访问。
在消息读取过程中,先读取所述元数据文件,并从所述元数据文件中获取该消息的大小以及该消息在消息文件内的偏移,然后再读取对应的消息文件。
具体而言,可根据消息id快速查询并读取,消息id由该消息所在文件的文件名结合该消息在该文件内的序号共同组成,在每个消息文件内消息id均从0开始递增。消息文件与元数据文件是一一对应的,如图5所示,元数据文件保存着每条消息的元数据信息,每条消息的元数据项由该消息的生产时间、该消息在消息文件中的偏移、该消息的长度组成。元数据项大小固定,将元数据文件映射在进程的虚拟地址空间后,可在用户态随机访问如何一个元数据项。读取消息时,先读取对应的元数据项,获取该消息在消息文件中的偏移和消息大小,就可以访问真正的消息数据。
在消息写入过程中,包括写入消息文件、写入元数据文件以及计算并更新消息数量和消息文件大小键值存储结构三个步骤。
具体实施时,同一个Partition同时只允许一个生产者进程进行写入操作,如果存在两个生产者进程都在生产某一Topic的消息,则为其分配不同的Partition。现在以生产者进程生产Topic1_P0-#-#文件的消息3为例讲述消息写入操作,如图6所示。
1)生成进程调用API生成消息,封装处理后以append方式写入消息文件。
2)消息文件写成功后会更新消息文件对应的元数据文件,以append方式在对应的元数据文件中写入消息3的元数据项。
3)后台线程通过检测元数据项,计算出该消息文件内的消息总数和该消息文件的大小,更新相关的键值存储结构。在中间任何一步失败则表示本次写入消息失败,回到第一步重新执行。
更新键值存储结构中消息文件大小、消息文件内消息数量是后台线程通过滑动检测点检测元数据项计算出的,检测流程如图7所示。
元数据文件创建后,元数据项的所有字段会被初始化为0。将元数据文件映射在进程的虚拟地址空间后,因为每一个元数据项大小固定,可以访问任何一个元数据项。消息元数据项中代表消息长度的字段size放在末尾,且用整形表示,CPU进行写入操作时是原子操作,所以只要size字段不为0,就代表着该消息的写入操作已经完成,该元数据项标识了一条新的消息,随后更改消息文件中消息数量和消息文件大小,同时将检测点移向下一个元数据项。
系统数据传输流程主要包括消息发布、消息备份、推模式消费、拉模式消费四种,而消息备份流程本质上和推模式消费流程相同,系统将Topic follower视为特殊的消费者数据传输流程由消息传输模块负责,如图8所示,消息传输模块主要由消息偏移管理模块、运行在生产者机器上的传输代理进程Proxy、运行在消息服务器上的传输代理进程Worker、运行在消息服务器和消费者机器上的Server进程组成。
生产者机器上的传输代理进程Proxy与消息服务器上的Server进程建立RDMA连接后将消息推送至消息服务器,Server进程负责对远程写入消息数据的检测并及时更改键值存储结构中消息数量和消息文件大小,检测过程同样采用滑动监测点检测技术。Proxy是多线程发送模型,每个线程负责一个Partition的发送。在消费流程中,如果是推模式消费,由消息服务器上的代理进程Worker与消费者机器上的Server建立连接,并将消息发送至消费者机器上的消息存储模块。Worker同样是多线程发送模型,每一个线程负责一个订阅关系的发送;如果是拉模式消费,则由消费者进程与消息服务器上的Server进程建立RDMA连接,直接拉取消息。
为保证消息传输的有序进行,避免消息漏发或者重发,需要依靠消息偏移管理模块。消息偏移管理模块在生产者机器、消费者机器、消息服务器上均有部署,如图8所示。在生产者机器上主要包括已发送消息个数和已发送消息文件偏移两个键值存储结构,以文件名为key,分别以该文件已发送消息个数和该文件已发送消息偏移为value,这两个键值存储结构持久化保存在NVM中。在消息服务器上的消息偏移管理模块略有不同,因为每个Topic Partition可以被多个消费者订阅,所以系统为每个订阅关系都维持了两个键值存储结构,主要用于推模式消费流程。消费者机器上的消费偏移管理模块与消息服务器上的类似,记录了该机器上每个消费者的消费偏移情况,主要用于拉模式消费消息。
系统的消息数据以为文件形式保存,数据流程又可以分为远程消息写入和远程消息读取两大类。消息发布、推模式消费、消息备份的数据传输流程本质上是将本地消息文件的数据写入到远端消息文件中,而拉模式消费本质上是读取远端消息文件中的数据。基于Infiniband协议的RDMA网络有RDMA READ、RDMA WRITE单边操作和RDMA SEND、RDMA RECV双边操两类。双边操作需要接收方感知通信过程,并且提前在接收队列中放入接收事件,否则无法正确接收消息。而单边操作只需要获取到远端的虚拟地址和权限就可以进行远程读写,远端不需要感知通信过程。系统通过单边操作传输消息数据,通过双边操作传输控制信息,如创建文件、获取RDMA注册信息等。远程消息写入通过RDMA WRITE操作完成,远程消息读取通过RDMA READ操作完成。
(1)RDMA WRITE单边操作
通过RDMA WRITE进行远程消息写入操作与本地消息写入操作类似,先写入消息数据,再写入对应的元数据项。具体操作如图9所示,假设服务器A需要往服务器B传输消息。
表1 RDMA WRITE传输消息数据时主要参数
系统的文件是通过共享NVM内存保存的,映射在进程的虚拟地址空间,并注册至RDMA网卡,根据起始地址和偏移完成远程消息写入。RDMA WRITE进行数据传输时,主要参数包括本地虚拟地址Local addr、本地虚拟地址注册至RDMA网卡后产生的密钥Local key、远端虚拟地址Remote addr、远端虚拟地址注册至RDMA网卡后产生的密钥Remote key。如表1所示是RDMA WRITE操作主要参数的赋值方法,每一条消息的元数据项中都记录了该消息在消息文件中的偏移和该消息的长度,所以在知晓本地文件和远端文件的起始地址后可自行计算出Local addr和Remote addr。而Local key和Remote key在进行RDMA注册操作之后就不会改变,所以服务器A只需要提前获取到服务器B端文件映射后的起始地址和进行RDMA注册后的rkey,就可自行完成消息传输操作,在传输过程中,不需要服务器B的参与。
消息数据传输完成后还需要传输消息对应的元数据项,系统中的消息id是有序递增的,元数据项大小固定,RDMA WRITE传输消息元数据项时主要参数赋值过程如表2所示。
表2 RDMA WRITE传输消息元数据时主要参数
RDMA通过硬件保证数据传输的可靠性,可以通过检测RDMA完成事件的返回码来判断操作是否成功。写入消息数据和对应的元数据项是一个整体操作,任何一步操作失败都意味着本次消息写入失败,需要重新写入该消息数据。对端的后台线程同样采用滑动的检测点检测元数据项更新消息数量和消息文件大小键值存储结构。
(2)RDMA READ单边操作
拉模式消费是通过RDMA READ单边操作完成的,在消息服务器上的消息存储模块中,有键值存储结构记录着每个消息文件当前的消息总数,将该键值存储结构注册至RDMA网卡,即可在远端通过RDMA READ操作读取。如图10所示,消费者会定时通过RDMA READ操作查询消息服务器上的消息的数量是否发生变化,如果发生变化,说明有新消息产生,然后通过RDMA READ操作读取新消息的元数据信息,再根据读到的元数据信息读取对应的消息实体,RDMA READ操作的参数赋值方法与RDMA WRITE相同,这里不再赘述。
具体实施时,系统采用了消息无锁传输机制,通过Topic分区机制保证消息发布流程的无锁化。系统将远端文件映射的地址注册至RDMA网卡,本端在获取到远端文件的映射地址和注册信息后,可以通过计算偏移的方式利用RDMA读写远端文件。如果没有Topic分区机制,则会发生下面这种问题,如图11(a)所示,两台生产者机器都在生产Topic0的消息,这样这两台生产者机器上的传输代理进程会通过RDMA WRITE写同一台消息服务器的同一个消息文件,在不采取任何文件锁的情况下,两个代理进程各自计算偏移,会造成消息数据的覆盖,破坏数据。
若要保证数据安全,两个代理进程就不能自行计算偏移完成数据写入。如图11(b)所示,需要对消息服务器上的文件加锁保护,传输代理进程需要先向消息服务器发送远程写请求,消息服务器上的请求代理进程根据写冲突避免机制回复可以写入的地址,然后传输代理进程才可以进行远程写入操作。但是这样,两台机器上的代理进程又会因为等待远程写许可而无法及时将消息写入到消息服务器中,产生写入延迟,所以这也不是一个很好的解决办法。
系统在遇到这种状况时将Topic划分为不同的Partition,如图11(c)所示,每个传输代理进程写不同Partition,两个Partition可以放在同一台消息服务器上,也可以放在不同的消息服务器上,这样既可以避免远程写冲突,又可以避免因为复杂的锁机制引起的性能下降。
在具体实施时,系统还采用了消息批处理机制,消息发布流程、推模式消费流程、消息备份流程是通过RDMA WRITE单边操作完成的,但是一条消息的长度通常情况下不会很大,如果在进行远程消息写入时,一次只写入一条消息,无法充分利用RDMA带宽,RDMA在传输小块数据时,软件耗时的占比过高,在面对快速连续生产的短消息时,会影响传输速度。所以,在远程消息写入的过程中,系统采用了消息批处理技术,设计了灵活的消息合并发送策略。
以消息发布流程为例,在进行消息传输操作时,既要保证一次多传输几条消息,又要保证生产的消息能够及时的发送出去,不会刻意等待消息合并而增加延迟。本文的消息合并策略并不是合并固定的消息长度或消息数量,而是与当前新消息的生产速度和传输速度相关的,以一次数据传输操作来说明系统的批处理策略。
系统持久化记录了每个消息文件的已发送消息数量和消息总数量,传输代理进程不断的检测消息文件已发送消息数和消息总数,如果已发送消息数小于消息总数,说明有新的消息产生,需要发送消息。系统的一次数据传输操作是从传输代理进程检测到已发送消息数小于消息总数开始的,如图12所示,假如本次传输操作开始时已发送消息数是k,而此时总消息数是m(m>k),因为在消息文件中消息id是从0开始递增的,所以从第k条消息到第m-1条消息都未被发送,一次性传输这些未发送的消息。通过访问id从k到m-1每一个元数据项中代表消息长度的字段,就可计算出需要发送的消息长度之和,结合已记录的消息文件发送偏移,就可以通过RDMA WRITE操作发送至远端。如果在这次消息传输过程中,如果又有新的消息产生,如图12所示,该消息传输操作完成后,消息总数变为n,已发送消息总数变为m,则此次传输操作发送id从m至n-1的消息。当然系统并不会合并过多的消息,默认情况下,单次合并发送的消息总长度不超过1MB。
消息的合并发送策略是灵活的,可以根据当前的消息生产速度和传输速度变化。如果消息生产速度非常的快,在上一次传输操作完成之后,已经有多条新消息产生,就将多条新消息打包一次性传输过去。如果消息的生产速度慢,在上一次传输操作完成之后,只有一条新的消息产生,则发送策略就自动退化成单条消息传输。通过这种方法,可以根据当前消息生产速度和传输速度自适应的调节发送策略,降低延迟,增加吞吐量。
为了进一步理解本发明的构思,下面对系统数据传输的详细过程做进一步介绍,包括消息发布、推模式消费、拉模式消费的详细步骤,系统将消息备份流程视作特殊的推模式消费流程处理,将follower视为消费者,这里不单独叙述。
①消息发布流程
生产者机器上的生产者进程调用API生产某个Topic Partition的消息,并将消息写入本地的消息存储模块中保存,运行在本机的传输代理进程Proxy负责将消息写入到对应的消息服务器。现在以生产者机器上有全新的Topic Partition时,Proxy进程的后续操作为例,如图13所示。
1)当生产者机器上的Proxy代理发现有新的Topic Partition产生时,向集群管理者(Manager)发起请求。如果Manager查询到该Partition的配置信息,发送配置好的消息服务器IP、端口给Proxy进程,如果预先未配置该Partition的消息服务器,则按照负载均衡策略分配消息服务器。
2)Proxy进程收到Manager反馈的消息服务器信息后检查与该服务器的RDMA连接情况,如果连接不存在,建立连接。
3)Proxy进程发送消息文件名给消息服务器,并将该消息文件与元数据文件映射的虚拟地址注册至RDMA网卡。运行在消息服务器上的Server进程创建对应的消息文件与元数据文件,并将映射的虚拟地址注册至RDMA网卡,将注册信息连同虚拟地址返回给生产者机器上的Proxy进程,这个过程是通过RDMA SEND、RDMA RECV双边操作完成的。
4)Proxy进程查询消息偏移模块中记录的已发送消息数,然后和消息总数比较,如果有未传输的消息,通过RDMA WRITE单边操作写入到消息服务器的消息文件中。
5)在第4步执行成功之后,通过RDMA WRITE单边操作将已写入消息对应的元数据信息写入消息服务器端的元数据文件中。
6)在上述操作执行成功后,Proxy进程会更改本地键值存储结构中已发送消息数、已发送消息文件偏移。如果在传输消息或者元数据信息的过程中,任何一步出现错误,则回退至第4步,重新执行传输过程。
7)运行在消息服务器上的Server进程,通过滑动的检测点检查元数据文件,更新键值存储结构中该消息文件大小和消息个数。
8)如果当前的消息文件已经是最大大小,并且已经传输完,则返回第3步,发送该Partition的下一个文件。
②推模式消费流程
推模式消费由消息服务器(Broker)上的Worker代理进程通过RDMA WRITE单边操作完成,与消息发布流程大体上一致。在消费者机器上部署消息存储模块,存储消息服务器发送来的消息,消费者进程从消息存储模块中读取消息完成消费过程。消费者机器上的Server进程会定期删除各个Topic Partition中已经完全被消费者处理完的消息文件。以当Worker进程检测到新Topic Partition时的后续操作为例,如图14所示。
1)当消息服务器上的Worker代理发现有新的Topic Partition产生时,向服务器管理(Manager)发起请求,Manager将查询订阅关系,同一个Topic Partition可能被多个消费者订阅,Manager将所有订阅了该Partition的消费者所在机器的IP、端口发给Worker进程。如果位于同一台机器上的两个消费者都订阅了该Partition,则在传输消息时,只传输一份。
2)Worker进程检查与消费者机器的RDMA连接情况,如果连接不存在,建立连接。
3)Worker进程将消息文件和元数据文件映射的虚拟地址注册至RDMA网卡,发送消息文件名,消费者机器上的Server进程创建对应的消息文件与元数据文件,将映射的虚拟地址注册至RDMA网卡,并将注册信息连同虚拟地址返回给Worker进程,这个过程是通过RDMA SEND、RDMA RECV双边操作完成的。
4)Worker进程查询消息偏移模块中记录的已发送消息数并和消息总数比较,通过RDMA WRITE操作将未发送的消息数据写入到消费者机器上的消息存储模块中。
5)Worker进程通过RDMA WRITE操作远程写入已传输消息的元数据信息。执行成功后更新本地键值存储系统中已发送消息数和已发送消息偏移。在传输消息数据或元数据的过程中,任何一步失败,则返回至第4步重新执行。
6)运行在消费者机器上的Server进程,通过滑动的检测点检查元数据项更新键值存储结构中消息文件大小和消息个数。
7)如果当前的消息文件已经达到最大大小并且已经发送完,则需要发送该Partition的下一个文件,回到第3步。
③拉模式消费流程
在拉模式中,消费者通过RDMA READ单边操作从消息服务器上的消息存储区拉取消息。以消费者机器上的Consumer进程订阅了某Topic Partition的后续流程为例,如图15所示。
1)首先,Consumer进程需要向Manager机器请求该Topic Partition所在消息服务器的IP、端口。
2)Consumer进程检查与消息服务器是否有RDMA连接,如果没有则建立连接。
3)通过RDMA SEND操作发送Topic Partition名,消息服务器上的Worker进程将对应消息文件和元数据文件映射的虚拟地址注册至RDMA网卡,并将注册信息返回给Consumer。
4)Consumer进程会定期通过RDMA READ操作读取消息服务器上的键值存储结构,判断该消息文件的消息总数是否发生变化。
5)当该消息文件消息总数发生了变化,比如说消息总数是n,但是已经消费的消息数是k(n>k),因为消息id是从0开始的,所以也就是说该消息文件从消息k至消息n-1是新产生的消息。因为消息元数据项大小固定,consumer0可以定位到第k条消息至第n-1条消息的元数据项,通过RDMA READ操作即可获取这些元数据信息。
6)Consumer进程根据读到的元数据信息,通过RDMA READ操作直接读取消息数据。回到第4步继续执行拉取操作。
7)如果当前读取的消息文件已达到最大大小并且全部读取完,则读取该Partition的下一个消息文件。
综上所述,本实施例提供的基于RDMA和NVM的分布式消息队列,可绕过复杂的I/O软件栈,通过虚拟地址访问消息数据,可以通过访问支持随机读取的消息元数据完成对消息数据的访问。可以直接读写远端服务器内存中的消息数据,无需任何多余的数据拷贝,实现数据高吞吐量、低延迟的消息传输。通过Topic分区机制保证远程消息写入的无锁化。在远程消息写入过程中,采用了基于消息生产速度、消息传输速度自适应的消息批处理策略,降低传输延迟,提升传输带宽。
上面结合附图对本发明的实施例进行了描述,但是本发明并不局限于上述的具体实施方式,上述的具体实施方式仅仅是示意性的,而不是限制性的,本领域的普通技术人员在本发明的启示下,在不脱离本发明宗旨和权利要求所保护的范围情况下,还可做出很多形式,这些均属于本发明的保护之内。
Claims (9)
1.一种基于NVM的分布式消息队列管理系统,其特征在于:设置有生产者机器、消费者机器、消息服务器集群和集群管理服务器,每个机器上均配置了NVM存储器和RDMA网卡,且通过RDMA网络互联;
所述生产者机器,用于通过生产者进程将消息写入本地消息存储模块中,并通过代理进程按照一定的策略将消息发往消息服务器;
所述消费者机器,用于运行消费者进程,负责消费消息服务器中的消息;
所述消息服务器集群中包括多个消息服务器-,每个消息服务器用于接收生产者发来的消息,持久化存储消息并将消息发往有订阅关系的消费者;
所述集群管理服务器,用于配置订阅关系,保存消息服务器集群的基本信息,负责消息服务器的灾备控制,保证消息服务器集群负载均衡,确保消息队列的健康运行。
2.根据权利要求1所述的基于NVM的分布式消息队列管理系统,其特征在于:系统使用主题分区机制,同一个主题可分为多个分区,消息的生产和消费过程按分区进行,单个分区内的消息按序排列,消息队列对所有消息文件都做了冗余备份,分别定义为主分区和备份分区,主分区参与消费流程,备份分区作为冷备份存放在非主分区所在的消息服务器上。
3.根据权利要求2所述的基于NVM的分布式消息队列管理系统,其特征在于,系统数据流程包括以下四种:
(1)消息发布流程:用于实现生产者机器上的生产者进程调用API生产某主题某分区的消息并存放在本地的消息存储模块中,还用于实现生产者机器上的传输代理进程将消息传输到主分区所在消息服务器;
(2)消息备份流程:主分区所在消息服务器上的传输代理进程将消息推送至第0备份分区所在消息服务器,第0备份分区所在消息服务器的传输代理将消息推送至第1备份分区所在消息服务器;
(3)推模式消费流程;主分区所在服务器的传输代理将消息推送至订阅了该分区的消费者所在服务器的消息存储模块中,消费者随后再从消息存储模块中读取消息;
(4)拉模式消费流程;消费者主动从主分区所在服务器的消息存储模块中拉取消息。
4.根据权利要求3所述的基于NVM的分布式消息队列管理系统,其特征在于,所述消息发布流程、消息备份流程以及推模式消费流程属于远程消息写入,所述拉模式消费流程属于远程消息读取,消息的远程写入通过RDMA WRITE操作实现,消息的远程读取采用RDMAREAD操作实现。
5.根据权利要求1-4任一所述的基于NVM的分布式消息队列管理系统,其特征在于,系统采用新型非易失存储设备,并在存储模块中设置有消息文件和元数据文件且建立了两个键值存储结构用于记录每个消息文件包含的消息数和消息文件大小,所述消息文件和元数据文件一一对应且分开保存,其中消息文件用于存放消息实体数据,元数据文件用于存放每条消息的描述信息,包括消息大小、在消息文件内的偏移,消息生成时间。消息文件和元数据文件本质是共享NVM内存,可映射在进程的虚拟地址空间,通过访问虚拟地址访问数据。
6.根据权利要求5所述的基于NVM的分布式消息队列管理系统,其特征在于,在消息写入过程中,包括写入消息文件、写入元数据文件以及计算并更新消息数量和消息文件大小键值存储结构三个步骤,同一个主题分区同时只运行一个生产者进程进行写入操作,如果存在两个生产者进程都在生成某一个主题的消息时,则为其分配不同的主题分区。
7.根据权利要求6所述的基于NVM的分布式消息队列管理系统,其特征在于,更新键值存储结构中消息文件大小、消息文件内消息数量是后台线程通过滑动检测点检测元数据文件中的元数据项计算出的。
8.根据权利要求1所述的基于NVM的分布式消息队列管理系统,其特征在于,每个机器上均配置了消息传输模块,所述消息传输模块包括消息偏移管理模块、运行在生产者机器上的传输代理进程、运行在消息服务器上的传输代理进程、运行在消息服务器和消费者机器上的服务进程。
9.根据权利要求3所述的基于NVM的分布式消息队列管理系统,其特征在于,系统将远端文件映射的地址注册至RDMA网卡,本端在获取到远端文件的映射地址和注册信息后,通过计算偏移的方式利用RDMA网络读写远端文件,且消息发布流程、推模式消费流程、消息备份流程是通过RDMA WRITE单边操作完成的,且采用消息批处理机制,一次性发送当前未发送的消息,拉模式消费通过RDMA READ单边操作完成。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910381138.3A CN110113420B (zh) | 2019-05-08 | 2019-05-08 | 基于nvm的分布式消息队列管理系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910381138.3A CN110113420B (zh) | 2019-05-08 | 2019-05-08 | 基于nvm的分布式消息队列管理系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110113420A true CN110113420A (zh) | 2019-08-09 |
CN110113420B CN110113420B (zh) | 2020-06-05 |
Family
ID=67488864
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910381138.3A Active CN110113420B (zh) | 2019-05-08 | 2019-05-08 | 基于nvm的分布式消息队列管理系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110113420B (zh) |
Cited By (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110851248A (zh) * | 2019-10-12 | 2020-02-28 | 中国平安财产保险股份有限公司 | 异步任务数据处理方法、装置及计算机可读存储介质 |
CN111049915A (zh) * | 2019-12-17 | 2020-04-21 | 书行科技(北京)有限公司 | 一种容器云下消息队列代理网格及方法 |
CN111124703A (zh) * | 2019-11-25 | 2020-05-08 | 山东鲁能软件技术有限公司 | 一种集群环境下自动提醒处理工作的方法及系统 |
CN111367628A (zh) * | 2020-03-05 | 2020-07-03 | 中国银行股份有限公司 | 分布式事务的处理方法、装置及消息生产方、消费方系统 |
CN111400306A (zh) * | 2020-02-20 | 2020-07-10 | 上海交通大学 | 基于rdma与非易失性内存的基数树访问系统 |
CN111416872A (zh) * | 2020-03-30 | 2020-07-14 | 中国人民解放军国防科技大学 | 基于mp和rdma的高速缓存文件系统通信方法及系统 |
CN111459686A (zh) * | 2020-03-17 | 2020-07-28 | 无锡华云数据技术服务有限公司 | 队列消息存储转发方法、系统及具操作系统的计算机装置 |
CN111966446A (zh) * | 2020-07-06 | 2020-11-20 | 复旦大学 | 一种容器环境下rdma虚拟化方法 |
CN112527520A (zh) * | 2020-12-01 | 2021-03-19 | 中国建设银行股份有限公司 | 一种部署消息中间件的方法和装置 |
CN112583931A (zh) * | 2020-12-25 | 2021-03-30 | 北京百度网讯科技有限公司 | 消息处理方法、消息中间件、电子设备和存储介质 |
CN112596669A (zh) * | 2020-11-25 | 2021-04-02 | 新华三云计算技术有限公司 | 一种基于分布式存储的数据处理方法及装置 |
CN113297110A (zh) * | 2021-05-17 | 2021-08-24 | 阿里巴巴新加坡控股有限公司 | 数据采集系统、方法以及装置 |
CN113360293A (zh) * | 2021-06-02 | 2021-09-07 | 奥特酷智能科技(南京)有限公司 | 一种基于远程虚拟共享内存机制的车身电气网络架构 |
CN114217875A (zh) * | 2021-12-17 | 2022-03-22 | 平安壹钱包电子商务有限公司 | 处理订单的方法、装置、设备及存储介质 |
CN114726883A (zh) * | 2022-04-27 | 2022-07-08 | 重庆大学 | 一种嵌入式rdma系统 |
CN114979270A (zh) * | 2022-05-25 | 2022-08-30 | 上海交通大学 | 适用于rdma网络的消息发布方法及系统 |
CN115118738A (zh) * | 2022-08-30 | 2022-09-27 | 深圳华锐分布式技术股份有限公司 | 基于rdma的灾备方法、装置、设备及介质 |
CN115297187A (zh) * | 2022-07-12 | 2022-11-04 | 重庆大学 | 一种网络通讯协议与总线协议的转换装置及集群系统 |
WO2023250018A1 (en) * | 2022-06-22 | 2023-12-28 | Afiniti, Ltd. | Communication system node having multiple modules and a shared memory |
CN117742998A (zh) * | 2024-02-18 | 2024-03-22 | 浩鲸云计算科技股份有限公司 | 一种面向计费采集数据转发的高性能队列方法及系统 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2014200239A1 (en) * | 2013-11-08 | 2015-05-28 | Tata Consultancy Services Limited | System and method for multiple sender support in low latency fifo messaging using rdma |
CN105912275A (zh) * | 2016-04-27 | 2016-08-31 | 华为技术有限公司 | 在非易失性存储系统中建立连接的方法和装置 |
CN106302817A (zh) * | 2016-09-29 | 2017-01-04 | 南京中新赛克科技有限责任公司 | 一种基于分布式消息队列的数据总线实现方法和装置 |
CN107465735A (zh) * | 2017-07-31 | 2017-12-12 | 杭州多麦电子商务股份有限公司 | 分布式消息系统 |
CN109683811A (zh) * | 2018-11-22 | 2019-04-26 | 华中科技大学 | 一种混合内存键值对存储系统的请求处理方法 |
-
2019
- 2019-05-08 CN CN201910381138.3A patent/CN110113420B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2014200239A1 (en) * | 2013-11-08 | 2015-05-28 | Tata Consultancy Services Limited | System and method for multiple sender support in low latency fifo messaging using rdma |
CN105912275A (zh) * | 2016-04-27 | 2016-08-31 | 华为技术有限公司 | 在非易失性存储系统中建立连接的方法和装置 |
CN106302817A (zh) * | 2016-09-29 | 2017-01-04 | 南京中新赛克科技有限责任公司 | 一种基于分布式消息队列的数据总线实现方法和装置 |
CN107465735A (zh) * | 2017-07-31 | 2017-12-12 | 杭州多麦电子商务股份有限公司 | 分布式消息系统 |
CN109683811A (zh) * | 2018-11-22 | 2019-04-26 | 华中科技大学 | 一种混合内存键值对存储系统的请求处理方法 |
Non-Patent Citations (1)
Title |
---|
SONGPING YU,: "Megalloc*: Fast Distributed Memory Allocator for", 《2017 INTERNATIONAL CONFERENCE ON NETWORKING, ARCHITECTURE, AND STORAGE (NAS)》 * |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110851248A (zh) * | 2019-10-12 | 2020-02-28 | 中国平安财产保险股份有限公司 | 异步任务数据处理方法、装置及计算机可读存储介质 |
CN111124703A (zh) * | 2019-11-25 | 2020-05-08 | 山东鲁能软件技术有限公司 | 一种集群环境下自动提醒处理工作的方法及系统 |
CN111124703B (zh) * | 2019-11-25 | 2024-03-22 | 山东鲁软数字科技有限公司 | 一种集群环境下自动提醒处理工作的方法及系统 |
CN111049915A (zh) * | 2019-12-17 | 2020-04-21 | 书行科技(北京)有限公司 | 一种容器云下消息队列代理网格及方法 |
CN111400306B (zh) * | 2020-02-20 | 2023-03-28 | 上海交通大学 | 基于rdma与非易失性内存的基数树访问系统 |
CN111400306A (zh) * | 2020-02-20 | 2020-07-10 | 上海交通大学 | 基于rdma与非易失性内存的基数树访问系统 |
CN111367628A (zh) * | 2020-03-05 | 2020-07-03 | 中国银行股份有限公司 | 分布式事务的处理方法、装置及消息生产方、消费方系统 |
CN111367628B (zh) * | 2020-03-05 | 2023-05-23 | 中国银行股份有限公司 | 分布式事务的处理方法、装置及消息生产方、消费方系统 |
CN111459686A (zh) * | 2020-03-17 | 2020-07-28 | 无锡华云数据技术服务有限公司 | 队列消息存储转发方法、系统及具操作系统的计算机装置 |
CN111459686B (zh) * | 2020-03-17 | 2023-06-27 | 华云数据控股集团有限公司 | 队列消息存储转发方法、系统及具操作系统的计算机装置 |
CN111416872A (zh) * | 2020-03-30 | 2020-07-14 | 中国人民解放军国防科技大学 | 基于mp和rdma的高速缓存文件系统通信方法及系统 |
CN111966446A (zh) * | 2020-07-06 | 2020-11-20 | 复旦大学 | 一种容器环境下rdma虚拟化方法 |
CN112596669A (zh) * | 2020-11-25 | 2021-04-02 | 新华三云计算技术有限公司 | 一种基于分布式存储的数据处理方法及装置 |
CN112527520A (zh) * | 2020-12-01 | 2021-03-19 | 中国建设银行股份有限公司 | 一种部署消息中间件的方法和装置 |
CN112583931A (zh) * | 2020-12-25 | 2021-03-30 | 北京百度网讯科技有限公司 | 消息处理方法、消息中间件、电子设备和存储介质 |
CN113297110A (zh) * | 2021-05-17 | 2021-08-24 | 阿里巴巴新加坡控股有限公司 | 数据采集系统、方法以及装置 |
CN113360293B (zh) * | 2021-06-02 | 2023-09-08 | 奥特酷智能科技(南京)有限公司 | 一种基于远程虚拟共享内存机制的车身电气网络架构 |
CN113360293A (zh) * | 2021-06-02 | 2021-09-07 | 奥特酷智能科技(南京)有限公司 | 一种基于远程虚拟共享内存机制的车身电气网络架构 |
CN114217875A (zh) * | 2021-12-17 | 2022-03-22 | 平安壹钱包电子商务有限公司 | 处理订单的方法、装置、设备及存储介质 |
CN114726883B (zh) * | 2022-04-27 | 2023-04-07 | 重庆大学 | 一种嵌入式rdma系统 |
CN114726883A (zh) * | 2022-04-27 | 2022-07-08 | 重庆大学 | 一种嵌入式rdma系统 |
CN114979270B (zh) * | 2022-05-25 | 2023-08-25 | 上海交通大学 | 适用于rdma网络的消息发布方法及系统 |
CN114979270A (zh) * | 2022-05-25 | 2022-08-30 | 上海交通大学 | 适用于rdma网络的消息发布方法及系统 |
WO2023250018A1 (en) * | 2022-06-22 | 2023-12-28 | Afiniti, Ltd. | Communication system node having multiple modules and a shared memory |
CN115297187A (zh) * | 2022-07-12 | 2022-11-04 | 重庆大学 | 一种网络通讯协议与总线协议的转换装置及集群系统 |
CN115297187B (zh) * | 2022-07-12 | 2023-11-17 | 重庆大学 | 一种网络通讯协议与总线协议的转换装置及集群系统 |
CN115118738B (zh) * | 2022-08-30 | 2022-11-22 | 深圳华锐分布式技术股份有限公司 | 基于rdma的灾备方法、装置、设备及介质 |
CN115118738A (zh) * | 2022-08-30 | 2022-09-27 | 深圳华锐分布式技术股份有限公司 | 基于rdma的灾备方法、装置、设备及介质 |
CN117742998A (zh) * | 2024-02-18 | 2024-03-22 | 浩鲸云计算科技股份有限公司 | 一种面向计费采集数据转发的高性能队列方法及系统 |
CN117742998B (zh) * | 2024-02-18 | 2024-05-07 | 浩鲸云计算科技股份有限公司 | 一种面向计费采集数据转发的高性能队列方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN110113420B (zh) | 2020-06-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110113420A (zh) | 基于nvm的分布式消息队列管理系统 | |
Dobbelaere et al. | Kafka versus RabbitMQ: A comparative study of two industry reference publish/subscribe implementations: Industry Paper | |
US10534681B2 (en) | Clustered filesystems for mix of trusted and untrusted nodes | |
CN1770110B (zh) | 对I/O完成进行无锁InfiniBand轮询的方法和系统 | |
KR101833114B1 (ko) | 분산 데이터베이스 시스템들을 위한 고속 장애 복구 | |
CN107888657A (zh) | 低延迟分布式存储系统 | |
CN101208671B (zh) | 管理消息队列 | |
US5948062A (en) | Network file server using a cached disk array storing a network file directory including file locking information and data mover computers each having file system software for shared read-write file access | |
KR101771246B1 (ko) | 분산 데이터 시스템들을 위한 전 시스템에 미치는 체크포인트 회피 | |
CN102831156B (zh) | 一种云计算平台上的分布式事务处理方法 | |
US8799213B2 (en) | Combining capture and apply in a distributed information sharing system | |
US7076553B2 (en) | Method and apparatus for real-time parallel delivery of segments of a large payload file | |
CN101535965B (zh) | 用于提高存储管理系统的可伸缩性和可移植性的技术 | |
US7010617B2 (en) | Cluster configuration repository | |
CN103020257B (zh) | 数据操作的实现方法和装置 | |
CN103312624A (zh) | 一种消息队列服务系统和方法 | |
CN104750757B (zh) | 一种基于HBase的数据存储方法和设备 | |
CN1184285A (zh) | 多媒体系统中高效传送数据流的系统方法 | |
CN110109873A (zh) | 一种用于消息队列的文件管理方法 | |
CN109639773A (zh) | 一种动态构建的分布式数据集群控制系统及其方法 | |
CN110262909A (zh) | RabbitMQ分层管理及消息投递方法、系统 | |
US7152096B2 (en) | High performance storage access environment | |
US7506000B2 (en) | Method and system for programming disconnected data | |
WO2003032182A1 (en) | System and method for providing a pluggable message store | |
CN110196881B (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 |