CN115623071A - 单机多客户端的发布订阅消息分发方法及*** - Google Patents
单机多客户端的发布订阅消息分发方法及*** Download PDFInfo
- Publication number
- CN115623071A CN115623071A CN202211077361.7A CN202211077361A CN115623071A CN 115623071 A CN115623071 A CN 115623071A CN 202211077361 A CN202211077361 A CN 202211077361A CN 115623071 A CN115623071 A CN 115623071A
- Authority
- CN
- China
- Prior art keywords
- message
- client
- cache
- topic
- server
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 28
- 238000009826 distribution Methods 0.000 claims description 19
- 230000007246 mechanism Effects 0.000 claims description 12
- 238000003860 storage Methods 0.000 claims description 10
- 230000005540 biological transmission Effects 0.000 abstract description 2
- 238000004364 calculation method Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
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/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]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了单机多客户端的发布订阅消息分发方法及***,属于数据库数据传输技术领域,要解决的技术问题为如何减少服务端的压力,并减少内存的占用。包括如下步骤:创建一个面向多客户端的pull请求线程,pull请求线程用于基于pull请求从服务端拉取主题消息;创建一个面向多客户端的全局缓存;对于用户发布至服务端的各主题消息,基于pull请求将每个主题消息的数据存储至全局缓存中,并将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中;每个客户端获取其订阅的主题消息时,基于所述主题消息的只读引用将所述主题消息的数据从全局缓存复制至其缓存中。
Description
技术领域
本发明涉及数据库数据传输技术领域,具体地说是单机多客户端的发布订阅消息分发方法及***。
背景技术
随着人们对能源的需求越来越大,能源的采集控制越来越向着精细化控制管理,因此对能源的生产管理要求越来越精准,从而产生了数字能源这一领域,大量实时采集***产生大量的时序数据,从而产生了对时序数据进行存储、计算等需求,尤其是对流计算,在某些场景下反馈控制***需要知道流计算结果以进行控制、通知等操作,同时大屏展示的需求也是比较多的需求之一,同时告警***也需要知道变化。
针对于此场景,一般采用发布/订阅模型来构建解决方案,发布/订阅消息收发是一种异步的服务间通信方式,在发布/订阅模式下,发布到主题的任何消息都会立即被主题的所有订阅者接收。发布/订阅消息收发可用于启用事件驱动架构,或分离应用程序,以提高性能、可靠性和可扩展性。时序数据流计算场景下,数据是不断产生的,并且在大规模应用的场景下用户对获取数据的性能是有很高要求的,当采用pull-mode的设计时存在如下问题:
(1)每一个客户端不断向服务端请求数据,当大量客户端接入后,服务端会承受大量的不间断的请求,尤其是在单机多客户端架构下,每一个客户端都不停的向服务端请求数据,增加了***的负载,并降低了***的性能;
(2)由于多客户端同时订阅同一个主题时,时常将数据进行多次复制,大大增加了内存的占用。
基于上述分析,如何减少服务端的压力,并减少内存的占用,是需要解决的技术问题。
发明内容
本发明的技术任务是针对以上不足,提供单机多客户端的发布订阅消息分发方法及***,来解决如何减少服务端的压力,并减少内存的占用的问题。
第一方面,本发明一种单机多客户端的发布订阅消息分发方法,应用于包括服务端和多个客户端的发布订阅消息***,所述多个客户端配置于同一个单机,所述方法包括如下步骤:
创建一个面向多客户端的pull请求线程,所述pull请求线程用于基于 pull请求从服务端拉取主题消息;
创建一个面向多客户端的全局缓存,所述全局缓存用于存储基于pull 请求从服务端拉取的主题消息的数据;
对于用户发布至服务端的各主题消息,基于pull请求将每个主题消息的数据存储至全局缓存中,并将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中;
每个客户端获取其订阅的主题消息时,基于所述主题消息的只读引用将所述主题消息的数据从全局缓存复制至其缓存中。
作为优选,还包括如下步骤:创建一个面向服务端的共享缓存;
服务端将用户发布的各主题消息的数据推送至共享缓存中进行存储;
基于pull请求,服务端将共享缓存中各主题消息的数据发送至全局缓存中进行存储,并将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中。
作为优选,服务端通过copy-on-write(中文翻译为写时复制)机制将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中。
作为优选,所述主题消息的只读引用为主题消息在全局缓存中的地址索引。
作为优选,每个客户端的缓存中均配置有队列;
对于每个客户端,所述客户端订阅主题消息的只读引用存储于其缓存内队列中。
第二方面,本发明一种单机多客户端的发布订阅消息分发***,包括服务端和多个客户端,所述多个客户端配置于同一个单机,所述多个客户端侧配置有一个pull请求线程,所述pull请求线程用于基于pull请求从服务端拉取主题消息;
所述多个客户端侧配置有一个全局缓存,所述全局缓存用于存储基于 pull请求从服务端拉取的主题消息的数据;
对于用户发布至服务端的各主题消息,服务端用于执行:基于pull请求将每个主题消息的数据存储至全局缓存中,并将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中;
每个客户端获取其订阅的主题消息时,客户端用于基于所述主题消息的只读引用将所述主题消息的数据从全局缓存复制至其缓存中。
作为优选,所述服务端配置有共享缓存;
所述服务端用于将用户发布的各主题消息的数据推送至共享缓存中进行存储;
基于pull请求,所述服务端用于将共享缓存中各主题消息的数据发送至全局缓存中进行存储,并将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中。
作为优选,所述服务端用于通过copy-on-write机制将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中。
作为优选,所述主题消息的只读引用为主题消息在全局缓存中的地址索引。
作为优选,每个客户端的缓存中均配置有队列;
对于每个客户端,所述客户端订阅主题消息的只读引用存储于其缓存内队列中。
本发明的单机多客户端的发布订阅消息分发方法及***具有以下优点:每一个客户端不单独进行pull请求而是创建一个全局缓存,只单独创建一个pull 请求线程,通过pull请求一直读取数据并将读取的各主题消息的数据存储到全局缓存中,并利用分发机制将每个主题消息的只读引用存储到订阅该主题消息的客户端缓存中,客户端获取数据时通过只读引用从全局缓存中将数据复制到其缓存中,减少了服务端的压力,并提升了内存的利用率,从而整体提升发布订阅***的运行效率,大大节省了***资源的利用率和***稳定性。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
下面结合附图对本发明进一步说明。
图1为常规发布订阅多客户端的消息分发流程框图;
图2为实施例1单机多客户端的发布订阅消息分发方法中单pull线程工作流程框图;
图3为实施例1单机多客户端的发布订阅消息分发方法中的基 copy-on-write机制的工作流程框图。
图4为实施例1单机多客户端的发布订阅消息分发方法中Copy-on-Write 模式下客户端获取数据流程框图。
具体实施方式
下面结合附图和具体实施例对本发明作进一步说明,以使本领域的技术人员可以更好地理解本发明并能予以实施,但所举实施例不作为对本发明的限定,在不冲突的情况下,本发明实施例以及实施例中的技术特征可以相互结合。
本发明实施例提供单机多客户端的发布订阅消息分发方法及***,用于解决如何减少服务端的压力,并减少内存的占用的技术问题。
实施例1:
如图1所示,常规单机多客户端的发布订阅***设计中,每个客户端通过其pull线程向服务端发送pull请求,基于pull请求拉取其订阅的主题消息的数据,如果多个客户端请求的是同一个主题的消息,则服务端需要将该主题消息的数据复制多份发送至每个客户端,增加了服务端的压力,并大量占用了内存。
本发明一种单机多客户端的发布订阅消息分发方法,应用于包括服务端和多个客户端的发布订阅消息***,所述多个客户端配置于同一个单机,所述方法包括如下步骤:
S100、创建一个面向多客户端的pull请求线程,所述pull请求线程用于基于pull请求从服务端拉取主题消息;
创建一个面向多客户端的全局缓存,所述全局缓存用于存储基于pull 请求从服务端拉取的主题消息的数据。
相对于常规设计,本实施例步骤S100每一个客户端不单独进行pull请求,而是在客户端创建一个全局缓存并单独创建一个pull请求线程。该单独的pull请求线程面向多个客户端,该pull请求线程一直向服务发送pull请求,基于该pull请求将服务端的各个主题消息的数据拉取至客户度,并存储在全局缓存中。
S200、对于用户发布至服务端的各主题消息,基于pull请求将每个主题消息的数据存储至全局缓存中,并将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中,具体如图2所示。
作为本实施例的具体实施,如图3所示,服务端通过copy-on-write机制将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中,本实施例主题消息的只读引用为主题消息在全局缓存中地址索引。
即本实施例中,服务端将同一个主题消息的数据存储到全局缓存中,并将订阅该主题消息在全局缓存的地址索引存储到订阅该主题消息的每个客户端的缓存中。
相对于常规设计,即时有多个客户端订阅了同一个主题的,本实施例中服务端将同一个主题消息的数据单次发送到全局缓存中,无需复制数据进行多次发送,减少了服务端压力。同时,服务端利用分发机制将主题消息在全局缓存中的地址索引发送到订阅该主题消息的客户端缓存中,即当前客户端对其订阅的主题消息至具有读操作权限,无法进行写操作,从而确保全局缓存中各主题消息的数据完整性和不可修改性。
S300、每个客户端获取其订阅的主题消息时,基于所述主题消息的只读引用将所述主题消息的数据从全局缓存复制至其缓存中。
执行步骤S200后,客户端缓存中存储有其订阅主题消息在全局缓存中的索引地址,如果客户端需要获取其订阅主题消息的数据并进行写操作,需要基于主题消息在全局缓存中索引地址、将对应主题消息的数据从全局缓存复制到其缓存中,然后对存储于其缓存中的数据进行写操作,如图4所示。
作为本实施例方法的改进,在步骤S100还包括如下操作:创建一个面向服务端的共享缓存,该共享缓存用于存储用户发布到服务端的各主题消息的数据。
对应的,在步骤S200中,基于pull请求,服务端将共享缓存中各主题消息的数据发送至全局缓存中进行存储,并将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中。
本实施例的方法每一个客户端不单独进行pull请求而是创建一个缓存,只单独创建一个pull请求线程,一直读取数据,利用分发机制将收到的数据存储带指定的客户端缓存中,利用Copy-on-Write机制,对于同一个发布消息每次仅仅将数据的只读引用存储到客户端缓存中,只有用户真实获取数据的时候再将数据复制给客户端,大大减少了瞬时大量内存的占用。
实施例2:
本发明一种单机多客户端的发布订阅消息分发***,包括服务端和多个客户端,多个客户端配置于同一个单机,在多个客户端侧配置有一个pull 请求线程,所述pull请求线程用于基于pull请求从服务端拉取主题消息;在多个客户端侧配置有一个全局缓存,所述全局缓存用于存储基于pull请求从服务端拉取的主题消息的数据。该***可执行实施例1公开的方法实现消息分发。
对于用户发布至服务端的各主题消息,服务端用于执行:基于pull请求将每个主题消息的数据存储至全局缓存中,并将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中。
作为具体实施,服务端用于通过copy-on-write机制将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中,本实施例主题消息的只读引用为主题消息在全局缓存中地址索引。
即本实施例中,服务端将同一个主题消息的数据存储到全局缓存中,并将订阅该主题消息在全局缓存的地址索引存储到订阅该主题消息的每个客户端的缓存中。
相对于常规设计,即时有多个客户端订阅了同一个主题的,本实施例中服务端将同一个主题消息的数据单次发送到全局缓存中,无需复制数据进行多次发送,减少了服务端压力。同时,服务端利用分发机制将主题消息在全局缓存中的地址索引发送到订阅该主题消息的客户端缓存中,即当前客户端对其订阅的主题消息至具有读操作权限,无法进行写操作,从而确保全局缓存中各主题消息的数据完整性和不可修改性。
每个客户端获取其订阅的主题消息时,客户端用于基于所述主题消息的只读引用将所述主题消息的数据从全局缓存复制至其缓存中。
客户端缓存中存储有其订阅主题消息在全局缓存中的索引地址,如果客户端需要获取其订阅主题消息的数据并进行写操作,需要基于主题消息在全局缓存中索引地址、将对应主题消息的数据从全局缓存复制到其缓存中,然后对存储于其缓存中的数据进行写操作。
作为本实施例***的改进,在服务端配置有一个共享缓存,该共享缓存用于存储用户发布到服务端的各主题消息的数据。
对应的,基于pull请求,服务端用于将共享缓存中各主题消息的数据发送至全局缓存中进行存储,并将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中。
上文通过附图和优选实施例对本发明进行了详细展示和说明,然而本发明不限于这些已揭示的实施例,基与上述多个实施例本领域技术人员可以知晓,可以组合上述不同实施例中的手段得到本发明更多的实施例,这些实施例也在本发明的保护范围之内。
Claims (10)
1.一种单机多客户端的发布订阅消息分发方法,其特征在于,应用于包括服务端和多个客户端的发布订阅消息***,所述多个客户端配置于同一个单机,所述方法包括如下步骤:
创建一个面向多客户端的pull请求线程,所述pull请求线程用于基于pull请求从服务端拉取主题消息;
创建一个面向多客户端的全局缓存,所述全局缓存用于存储基于pull请求从服务端拉取的主题消息的数据;
对于用户发布至服务端的各主题消息,基于pull请求将每个主题消息的数据存储至全局缓存中,并将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中;
每个客户端获取其订阅的主题消息时,基于所述主题消息的只读引用将所述主题消息的数据从全局缓存复制至其缓存中。
2.根据权利要求1所述的单机多客户端的发布订阅消息分发方法,其特征在于,还包括如下步骤:创建一个面向服务端的共享缓存;
服务端将用户发布的各主题消息的数据推送至共享缓存中进行存储;
基于pull请求,服务端将共享缓存中各主题消息的数据发送至全局缓存中进行存储,并将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中。
3.根据权利要求1或2所述的单机多客户端的发布订阅消息分发方法,其特征在于,服务端通过copy-on-write机制将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中。
4.根据权利要求1或2所述的单机多客户端的发布订阅消息分发方法,其特征在于,所述主题消息的只读引用为主题消息在全局缓存中的地址索引。
5.根据权利要求1或2所述的单机多客户端的发布订阅消息分发方法,其特征在于,每个客户端的缓存中均配置有队列;
对于每个客户端,所述客户端订阅主题消息的只读引用存储于其缓存内队列中。
6.一种单机多客户端的发布订阅消息分发***,包括服务端和多个客户端,所述多个客户端配置于同一个单机,其特征在于,
所述多个客户端侧配置有一个pull请求线程,所述pull请求线程用于基于pull请求从服务端拉取主题消息;
所述多个客户端侧配置有一个全局缓存,所述全局缓存用于存储基于pull请求从服务端拉取的主题消息的数据;
对于用户发布至服务端的各主题消息,服务端用于执行:基于pull请求将每个主题消息的数据存储至全局缓存中,并将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中;
每个客户端获取其订阅的主题消息时,客户端用于基于所述主题消息的只读引用将所述主题消息的数据从全局缓存复制至其缓存中。
7.根据权利要求6所述的单机多客户端的发布订阅消息分发***,其特征在于,所述服务端配置有共享缓存;
所述服务端用于将用户发布的各主题消息的数据推送至共享缓存中进行存储;
基于pull请求,所述服务端用于将共享缓存中各主题消息的数据发送至全局缓存中进行存储,并将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中。
8.根据权利要求6或7所述的单机多客户端的发布订阅消息分发***,其特征在于,所述服务端用于通过copy-on-write机制将每个主题消息的只读引用存储至订阅所述主题消息的每个客户端的缓存中。
9.根据权利要求6或7所述的单机多客户端的发布订阅消息分发***,其特征在于,所述主题消息的只读引用为主题消息在全局缓存中的地址索引。
10.根据权利要求6或7所述的单机多客户端的发布订阅消息分发***,其特征在于,每个客户端的缓存中均配置有队列;
对于每个客户端,所述客户端订阅主题消息的只读引用存储于其缓存内队列中。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211077361.7A CN115623071A (zh) | 2022-09-05 | 2022-09-05 | 单机多客户端的发布订阅消息分发方法及*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211077361.7A CN115623071A (zh) | 2022-09-05 | 2022-09-05 | 单机多客户端的发布订阅消息分发方法及*** |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115623071A true CN115623071A (zh) | 2023-01-17 |
Family
ID=84858684
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211077361.7A Pending CN115623071A (zh) | 2022-09-05 | 2022-09-05 | 单机多客户端的发布订阅消息分发方法及*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115623071A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117914943A (zh) * | 2024-03-20 | 2024-04-19 | 深圳华锐分布式技术股份有限公司 | 数据订阅及推送方法、装置、设备及介质 |
-
2022
- 2022-09-05 CN CN202211077361.7A patent/CN115623071A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117914943A (zh) * | 2024-03-20 | 2024-04-19 | 深圳华锐分布式技术股份有限公司 | 数据订阅及推送方法、装置、设备及介质 |
CN117914943B (zh) * | 2024-03-20 | 2024-06-14 | 深圳华锐分布式技术股份有限公司 | 数据订阅及推送方法、装置、设备及介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Fu et al. | A fair comparison of message queuing systems | |
CN112579148B (zh) | 基于业务代理的业务消息处理方法、装置及电子设备 | |
CN114363407B (zh) | 消息服务方法及装置、可读存储介质及电子设备 | |
CN113032419B (zh) | 一种多源数据聚合搜索方法、装置、设备及存储介质 | |
CN110648178A (zh) | 一种增加kafka消费能力的方法 | |
CN114064211B (zh) | 一种基于端-边-云计算架构的视频流分析***及方法 | |
CN115623071A (zh) | 单机多客户端的发布订阅消息分发方法及*** | |
CN112055061A (zh) | 分布式消息处理方法和设备 | |
CN114827171B (zh) | 信息同步方法、装置、计算机设备和存储介质 | |
CN115328664A (zh) | 一种消息消费方法、装置、设备及介质 | |
CN111526188A (zh) | 基于Spark Streaming结合Kafka确保数据零丢失的***和方法 | |
CN114063936A (zh) | 一种优化定时任务的方法、***、设备和存储介质 | |
CN111917814A (zh) | 数据发布、订阅方法、装置、设备、***及可读存储介质 | |
CN110704212B (zh) | 一种消息处理方法及装置 | |
CN116842090A (zh) | 一种对账***、方法、设备及存储介质 | |
CN111475315A (zh) | 服务器及订阅通知推送控制、执行方法 | |
CN110955461A (zh) | 计算任务的处理方法、装置、***、服务器和存储介质 | |
CN116107710A (zh) | 用于处理离线渲染任务的方法、装置、设备和介质 | |
Aahlad et al. | Asynchonrous Notifications Among Distributed Objects. | |
CN117692418A (zh) | 消息处理方法、装置、计算机设备和存储介质 | |
CN115883639A (zh) | 一种web实时消息推送方法及装置、设备、存储介质 | |
CN116166451B (zh) | 一种主题数量的动态调节方法、***、装置及存储介质 | |
US9613150B2 (en) | Remote viewing of documents via the web in real-time | |
CN112965796B (zh) | 一种任务调度***、方法和装置 | |
JP2009110165A (ja) | パブリッシュ/サブスクライブ通信における負荷分散処理方法及びその実施装置と処理プログラム |
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 |