CN112055061A - 分布式消息处理方法和设备 - Google Patents
分布式消息处理方法和设备 Download PDFInfo
- Publication number
- CN112055061A CN112055061A CN202010851195.6A CN202010851195A CN112055061A CN 112055061 A CN112055061 A CN 112055061A CN 202010851195 A CN202010851195 A CN 202010851195A CN 112055061 A CN112055061 A CN 112055061A
- Authority
- CN
- China
- Prior art keywords
- message
- publisher
- topic
- target
- subscriber
- 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
- 238000003672 processing method Methods 0.000 title claims abstract description 52
- 238000000034 method Methods 0.000 claims abstract description 113
- 230000008569 process Effects 0.000 claims abstract description 94
- 238000012545 processing Methods 0.000 claims abstract description 31
- 230000006870 function Effects 0.000 claims description 35
- 238000001914 filtration Methods 0.000 abstract description 10
- 230000005540 biological transmission Effects 0.000 description 11
- 230000002159 abnormal effect Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 238000007493 shaping process Methods 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 2
- 230000002441 reversible effect Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 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/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/566—Grouping or aggregating service requests, e.g. for unified processing
-
- 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/06—Management of faults, events, alarms or notifications
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明公开了一种分布式消息处理方法和设备，所述方法通过消息发布者将发布者信息和Topic名称发送至全局消息管理器，全局消息管理器对发布者信息和Topic名称进行存储；消息订阅者发送目标Topic名称至全局消息管理器；消息订阅者根据主题序号和进程文件序号确定目标发布者，将异步拉消息请求发送至目标发布者，并接收目标发布者返回的消息序列，根据消息序列进行消息上报；消息可以被持久化，订阅者只用获取和自己关注的消息，消息的过滤是直接在发布者中就过滤了，不用拉取所有消息后再在订阅者中过滤，减少了带宽；不仅保证了网管功能的正确性和可靠性，更加保证了功能处理的及时性和高效性。
Description
技术领域
本发明电信传输网络管理领域，尤其涉及一种分布式消息处理方法和设备。
背景技术
在电信传输网管中，很多功能都依赖于消息上报，如设备(如单板)上报了一个紧急告警，在网管服务中处理后，需要在网管界面上对应的单板上显示紧急告警图标提醒用户，并通过告警发生告知用户。
消息机制无论是在网管服务之间，还是网管服务和网管客户端都之间都应用广泛，传统的采用消息中间件的方式，一是不能保证消息是否准确到达到订阅者了，因为发布者只是把消息发给了统一的消息发布服务；二是消息存在丢失的情况，因为当发布服务异常时消息就丢失了，如公共对象请求代理体系结构(Common Object Request BrokerArchitecture，CORBA)的通知服务NotifyService就经常存在丢消息的情况；三是消息量问题，当管理容量增加时，消息量也会变大，订阅者会收到很多不必要的消息，而实际上某个告警实例进程只用处理自己管理的网元对象的变化消息；四是采用推模式方式消息上报，让网络变得更加复杂，因为必须在订阅者和消息中间件之间增加反向连接，但是为了保证网络安全，一般不使用反向连接。
发明内容
本发明的主要目的在于提供一种分布式消息处理方法和设备，旨在解决现有技术中消息传送准确性低且容易丢失，消息量较大时造成网络复杂化的技术问题。
第一方面，本发明提供一种分布式消息处理方法，所述分布式消息处理方法包括以下步骤：
消息发布者将发布者信息和Topic名称发送至全局消息管理器，所述全局消息管理器对所述发布者信息和所述Topic名称进行存储；
消息订阅者发送目标Topic名称至所述全局消息管理器，所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者；
所述消息订阅者根据所述主题序号和所述进程文件序号确定目标发布者，将异步拉消息请求发送至所述目标发布者，并接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报。
可选地，所述消息发布者将发布者信息和Topic名称发送至全局消息管理器，所述全局消息管理器对所述发布者信息和所述Topic名称进行存储，包括：
消息发布者采用Topic创建发布者对象，并获取Topic名称和所述发布者对象对应的消息发布进程服务名称；
将所述消息发布进程服务名称作为发布者信息，将所述发布者信息和所述Topic名称发送至全局消息管理器；
所述全局消息管理器对所述发布者信息和所述Topic名称进行存储。
可选地，所述消息发布者采用Topic创建发布者对象之后，所述分布式消息处理方法还包括：
当有消息需要发送时，所述消息发布者获得所述消息的类型和消息Topic名称；
所述消息发布者采用所述发布者对象发送消息，所述发布者对象根据所述类型和所述消息Topic名称对所述消息进行不同的处理。
可选地，所述消息发布者采用所述发布者对象发送消息，所述发布者对象根据所述类型和所述消息Topic名称对所述消息进行不同的处理，包括：
所述消息发布者采用所述发布者对象发送消息；
所述发布者对象根据所述类型和所述消息Topic名称确定所述消息为文件消息时，将所述文件消息存储至独立的文件中；
所述发布者对象根据所述类型和所述消息Topic名称确定所述消息为覆盖式消息时，根据所述覆盖式消息的键对已缓存消息进行替换或增加。
可选地，所述消息订阅者发送目标Topic名称至所述全局消息管理器，所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者，包括：
所述消息订阅者通过目标Topic名称创建订阅对象，并发送所述目标Topic名称至所述全局消息管理器；
所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者；
将目标Topic名称对应的主题序号和进程文件序号记录到所述订阅对象中。
可选地，所述消息订阅者根据所述主题序号和所述进程文件序号确定目标发布者，将异步拉消息请求发送至所述目标发布者，并接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报，包括：
所述消息订阅者将所述主题序号和所述进程文件序号对应的发布者作为目标发布者；
通过异步远程过程调用RPC接口将异步拉消息请求发送至所述目标发布者；
接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报。
可选地，所述通过异步远程过程调用RPC接口将异步拉消息请求发送至所述目标发布者之后，所述分布式消息处理方法还包括：
获取在创建订阅对象时输入的回调对象，从所述回调对象中获取预设回调函数CallBack；
将所述预设回调函数CallBack反馈至所述消息发布者。
可选地，所述接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报，包括：
接收所述目标发布者返回的消息序列，通过独立线程对所述消息序列进行消息上报；
从所述消息序列中获得Topic数量，在所述Topic数量大于预设阈值时，增加消息上报的独立线程，根据所述独立线程对所述消息序列进行消息上报。
可选地，所述消息发布者将发布者信息和Topic名称发送至全局消息管理器，所述全局消息管理器对所述发布者信息和所述Topic名称进行存储之后，所述分布式消息处理方法还包括：
所述全局消息管理器为所述Topic名称分配一个唯一主题序号；
所述全局消息管理器为所述发布者信息分配进程文件序号。
第二方面，本发明还提出一种分布式消息处理设备，所述分布式消息处理设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的分布式消息处理程序，所述分布式消息处理程序配置为实现如上文所述的分布式消息处理方法的步骤。
本发明提出的分布式消息处理方法，通过消息发布者将发布者信息和Topic名称发送至全局消息管理器，所述全局消息管理器对所述发布者信息和所述Topic名称进行存储；消息订阅者发送目标Topic名称至所述全局消息管理器，所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者；所述消息订阅者根据所述主题序号和所述进程文件序号确定目标发布者，将异步拉消息请求发送至所述目标发布者，并接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报；消息发布没有统一的NotifyService，每个发布者只用关注和发布自己需要发布的消息，消息可以被持久化；订阅者只用获取和自己关注的消息，消息的过滤是直接在发布者中就过滤了，不用拉取所有消息后再在订阅者中过滤，减少了带宽；不仅保证了网管功能的正确性和可靠性，更加保证了功能处理的及时性和高效性。
附图说明
图1为本发明实施例方案涉及的硬件运行环境的设备结构示意图；
图2为本发明分布式消息处理方法第一实施例的流程示意图；
图3为本发明分布式消息处理方法第二实施例的流程示意图；
图4为本发明分布式消息处理方法第三实施例的流程示意图；
图5为本发明分布式消息处理方法中的消息格式示意图；
图6为本发明分布式消息处理方法第四实施例的流程示意图；
图7为本发明分布式消息处理方法第五实施例的流程示意图；
图8为本发明分布式消息处理方法第六实施例的流程示意图；
图9为本发明分布式消息处理方法第七实施例的流程示意图。
本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
本发明实施例的解决方案主要是：通过消息发布者将发布者信息和Topic名称发送至全局消息管理器，所述全局消息管理器对所述发布者信息和所述Topic名称进行存储；消息订阅者发送目标Topic名称至所述全局消息管理器，所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者；所述消息订阅者根据所述主题序号和所述进程文件序号确定目标发布者，将异步拉消息请求发送至所述目标发布者，并接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报；消息发布没有统一的通知服务NotifyService，每个发布者只用关注和发布自己需要发布的消息，消息可以被持久化；订阅者只用获取和自己关注的消息，消息的过滤是直接在发布者中就过滤了，不用拉取所有消息后再在订阅者中过滤，减少了带宽；不仅保证了网管功能的正确性和可靠性，更加保证了功能处理的及时性和高效性，解决了现有技术中消息传送准确性低且容易丢失，消息量较大时造成网络复杂化的技术问题。
参照图1，图1为本发明实施例方案涉及的硬件运行环境的设备结构示意图。
如图1所示，该设备可以包括：处理器1001，例如CPU，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如Wi-Fi接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(Non-Volatile Memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。
本领域技术人员可以理解，图1中示出的设备结构并不构成对该设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
如图1所示，作为一种存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及分布式消息处理程序。
本发明设备通过处理器1001调用存储器1005中存储的分布式消息处理程序，并执行以下操作：
消息发布者将发布者信息和Topic名称发送至全局消息管理器，所述全局消息管理器对所述发布者信息和所述Topic名称进行存储；
消息订阅者发送目标Topic名称至所述全局消息管理器，所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者；
所述消息订阅者根据所述主题序号和所述进程文件序号确定目标发布者，将异步拉消息请求发送至所述目标发布者，并接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报。
进一步地，处理器1001可以调用存储器1005中存储的分布式消息处理程序，还执行以下操作：
消息发布者采用Topic创建发布者对象，并获取Topic名称和所述发布者对象对应的消息发布进程服务名称；
将所述消息发布进程服务名称作为发布者信息，将所述发布者信息和所述Topic名称发送至全局消息管理器；
所述全局消息管理器对所述发布者信息和所述Topic名称进行存储。
进一步地，处理器1001可以调用存储器1005中存储的分布式消息处理程序，还执行以下操作：
当有消息需要发送时，所述消息发布者获得所述消息的类型和消息Topic名称；
所述消息发布者采用所述发布者对象发送消息，所述发布者对象根据所述类型和所述消息Topic名称对所述消息进行不同的处理。
进一步地，处理器1001可以调用存储器1005中存储的分布式消息处理程序，还执行以下操作：
所述消息发布者采用所述发布者对象发送消息；
所述发布者对象根据所述类型和所述消息Topic名称确定所述消息为文件消息时，将所述文件消息存储至独立的文件中；
所述发布者对象根据所述类型和所述消息Topic名称确定所述消息为覆盖式消息时，根据所述覆盖式消息的键对已缓存消息进行替换或增加。
进一步地，处理器1001可以调用存储器1005中存储的分布式消息处理程序，还执行以下操作：
所述消息订阅者通过目标Topic名称创建订阅对象，并发送所述目标Topic名称至所述全局消息管理器；
所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者；
将目标Topic名称对应的主题序号和进程文件序号记录到所述订阅对象中。
进一步地，处理器1001可以调用存储器1005中存储的分布式消息处理程序，还执行以下操作：
所述消息订阅者将所述主题序号和所述进程文件序号对应的发布者作为目标发布者；
通过异步远程过程调用RPC接口将异步拉消息请求发送至所述目标发布者；
接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报。
进一步地，处理器1001可以调用存储器1005中存储的分布式消息处理程序，还执行以下操作：
获取在创建订阅对象时输入的回调对象，从所述回调对象中获取预设回调函数CallBack；
将所述预设回调函数CallBack反馈至所述消息发布者。
进一步地，处理器1001可以调用存储器1005中存储的分布式消息处理程序，还执行以下操作：
接收所述目标发布者返回的消息序列，通过独立线程对所述消息序列进行消息上报；
从所述消息序列中获得Topic数量，在所述Topic数量大于预设阈值时，增加消息上报的独立线程，根据所述独立线程对所述消息序列进行消息上报。
进一步地，处理器1001可以调用存储器1005中存储的分布式消息处理程序，还执行以下操作：
所述全局消息管理器为所述Topic名称分配一个唯一主题序号；
所述全局消息管理器为所述发布者信息分配进程文件序号。
本实施例通过上述方案，通过消息发布者将发布者信息和Topic名称发送至全局消息管理器，所述全局消息管理器对所述发布者信息和所述Topic名称进行存储；消息订阅者发送目标Topic名称至所述全局消息管理器，所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者；所述消息订阅者根据所述主题序号和所述进程文件序号确定目标发布者，将异步拉消息请求发送至所述目标发布者，并接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报；消息发布没有统一的通知服务NotifyService，每个发布者只用关注和发布自己需要发布的消息，消息可以被持久化；消息传送准确率高，且不容易丢失，订阅者只用获取和自己关注的消息，消息的过滤是直接在发布者中就过滤了，不用拉取所有消息后再在订阅者中过滤，减少了带宽；不仅保证了网管功能的正确性和可靠性，更加保证了功能处理的及时性和高效性。
基于上述硬件结构，提出本发明分布式消息处理方法实施例。
参照图2，图2为本发明分布式消息处理方法第一实施例的流程示意图。
在第一实施例中，所述分布式消息处理方法包括以下步骤：
步骤S10、消息发布者将发布者信息和Topic名称发送至全局消息管理器，所述全局消息管理器对所述发布者信息和所述Topic名称进行存储。
需要说明的是，所述消息发布者封装了消息发布相关的接口和内部处理，如Report接口，内部会通过远程过程调用接口调用到全局消息管理器，然后处理消息订阅者的远程过程调用接口的请求；所述发布者信息为所述消息发布者的名称或其他可用于身份识别的相关信息，所述Topic名称为消息发布者的主题名称消息，所述消息发布者将所述发布者信息和所述Topic名称发送至全局消息管理器后，所述全局消息管理器能够对所述发布者信息和所述Topic名称进行存储，并进行整理。
进一步地，所述步骤S10之后，所述分布式消息处理方法还包括以下步骤：
所述全局消息管理器为所述Topic名称分配一个唯一主题序号；
所述全局消息管理器为所述发布者信息分配进程文件序号。
可以理解的是，全局消息管理器内部会将Topic名称和服务名称缓存起来，并为Topic分配一个唯一的主题序号TopicNo，发布者服务分配进程文件序号AgentNo，AgentNo在TopicNo下面唯一，当同一Topic有多个发布者时就会在Topic下面存在多个AgentNo，Topic全局唯一，并持久化到本地数据库中；全局消息管理器内部采用Ping线程来检查发布者状态，当发布者有异常时，订阅者创建订阅对象时会返回相应的错误信息。
步骤S20、消息订阅者发送目标Topic名称至所述全局消息管理器，所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者。
需要说明的是，所述消息订阅者封装了消息订阅相关的接口和内部处理，如Subscribe/StartRecv/Unsubscribe/StopRecv/QueryPublisherState等接口，会通过远程过程调用接口调用到所述全局消息管理器；内部会通过远程过程调用接口调用到所述消息发布者，所述全局消息管理器记录了Topic和所述消息发布者的对应关系，是所述消息发布者和所述消息订阅者之间的枢纽，所述目标Topic名称为消息订阅者的主题名称消息，通过将所述目标Topic名称发送至所述全局消息管理器，所述全局消息管理器可以查找到匹配的Topic名称，并返回主题序号和进程文件序号至所述消息订阅者。
步骤S30、所述消息订阅者根据所述主题序号和所述进程文件序号确定目标发布者，将异步拉消息请求发送至所述目标发布者，并接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报。
应当理解的是，所述消息订阅者根据所述主题序号和所述进程文件序号能够从很多消息发布者中确定目标发布者，所述异步拉消息请求为异步的进行消息拉取的请求，通过将所述异步拉消息请求发送至所述目标发布者，能够接受所述目标发布者返回的消息序列，从而更加所述消息序列进行消息上报。
在具体实现中，每条消息都带一个匹配ID，即Topic名称，为了避免订阅者获取不需要关心的消息，通过本实施例，每个实例进程只用关心本进程管理网元的消息，其他消息不用关心，订阅者在拉取消息时，传入自己关心的匹配ID集合，全局消息管理器根据消息匹配ID在订阅者ID集合中查找，如果存在，那么说明是订阅者关心的消息，否者不返回给订阅者。
本实施例通过上述方案，通过消息发布者将发布者信息和Topic名称发送至全局消息管理器，所述全局消息管理器对所述发布者信息和所述Topic名称进行存储；消息订阅者发送目标Topic名称至所述全局消息管理器，所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者；所述消息订阅者根据所述主题序号和所述进程文件序号确定目标发布者，将异步拉消息请求发送至所述目标发布者，并接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报；消息发布没有统一的通知服务NotifyService，每个发布者只用关注和发布自己需要发布的消息，消息可以被持久化；消息传送准确率高，且不容易丢失，订阅者只用获取和自己关注的消息，消息的过滤是直接在发布者中就过滤了，不用拉取所有消息后再在订阅者中过滤，减少了带宽；不仅保证了网管功能的正确性和可靠性，更加保证了功能处理的及时性和高效性。
进一步地，图3为本发明分布式消息处理方法第二实施例的流程示意图，如图3所示，基于第一实施例提出本发明分布式消息处理方法第二实施例，在本实施例中，所述步骤S10具体包括以下步骤：
步骤S11、消息发布者采用Topic创建发布者对象，并获取Topic名称和所述发布者对象对应的消息发布进程服务名称。
需要说明的是，消息发布者的消息发布进程一般采用Topic创建发布者对象，Topic名称和所述发布者对象对应的消息发布进程服务名称为在消息发布者采用Topic创建发布者对象的同时采集的名称数据。
应当理解的是，在发布消息时必须先首先采用Topic来创建发布者对象，为了让订阅者能够根据Topic查询到发布者，创建发布者的同时会将Topic名称和消息发布进程服务名称统一发送给全局消息管理器进行维护，后续订阅者通过Topic名称向全局消息管理器查询对应的消息发布进程服务名称，便于通过统一的远程过程调用(Remote ProcedureCall，RPC)接口拉取消息。
步骤S12、将所述消息发布进程服务名称作为发布者信息，将所述发布者信息和所述Topic名称发送至全局消息管理器。
可以理解的是，所述发布者信息即为所述消息发布进程服务名称，将所述发布者信息和所述Topic名称发送至全局消息管理器后，所述全局消息管理器可以对所述发布者信息和所述Topic名称进行维护；一般通过RPC接口将所述发布者信息和所述Topic名称发送至全局消息管理器。
步骤S13、所述全局消息管理器对所述发布者信息和所述Topic名称进行存储。
应当理解的是，将所述发布者信息和所述Topic名称发送至全局消息管理器后，所述全局消息管理器可以对所述发布者信息和所述Topic名称进行存储和维护，后续订阅者可以通过Topic名称向所述全局消息管理器查询对应的消息发布进程服务名称，即查询发布者信息，便于通过统一的RPC接口拉取消息。
可以理解的是，消息存储分为内存缓存和文件存储，内存缓存表示所有的消息都存储在发布者进程缓存中，当发布者进程异常后，订阅者没有拉取的消息都会丢失，采用缓存消息时，通常需要通过同步数据的逻辑来补偿消息的丢失；而文件存储表示是可靠消息，所有的消息都会持久化到文件中，当发布者进程异常后，订阅者通过消息序号SN可以获取到没有拉取的消息；可靠消息在电信网管中使用非常频繁，因为如果每次由于服务异常做数据同步，可能因为数据量大或者数据比较逻辑复杂导致网管系统启动慢，在一段时间不可用。
本实施例通过上述方案，通过消息发布者采用Topic创建发布者对象，并获取Topic名称和所述发布者对象对应的消息发布进程服务名称；将所述消息发布进程服务名称作为发布者信息，将所述发布者信息和所述Topic名称发送至全局消息管理器；所述全局消息管理器对所述发布者信息和所述Topic名称进行存储，消息发布没有统一的通知服务，每个发布者只用关注和发布自己需要发布的消息，消息可以被持久化；不仅保证了网管功能的正确性和可靠性，更加保证了功能处理的及时性和高效性。
进一步地，图4为本发明分布式消息处理方法第三实施例的流程示意图，如图4所示，基于第二实施例提出本发明分布式消息处理方法第三实施例，在本实施例中，所述步骤S11之后，所述分布式消息处理方法还包括以下步骤：
步骤S111、当有消息需要发送时，所述消息发布者获得所述消息的类型和消息Topic名称。
需要说明的是，所述消息的类型可以是队列消息和覆盖式消息，当然也可以是其他消息类型，本实施例对此不加以限制；当有消息需要发送时，消息发布者采用发布对象发布消息。
可以理解的是，每条消息都有一个序号SN，发布者会维护自己的消息列表，订阅者可以只获取指定SN之后的消息，保证消息的有序处理。
在具体实现中，电信传输网管管理系统一般包含这些功能模块，分别是告警、性能、管理对象配置、业务配置、事件及日志功能模块，某些功能模块之间相互独立，例如告警和性能是不相关的；为了提高系统的可靠性和增加管理容量，电信网管系统将后台服务进程按照功能进行切分，如告警管理进程、性能管理进程、配置管理进程等，这样即使告警管理进程异常也不影响性能的处理；另一方面，网管管理的对象为网元，某些功能进程，如告警管理进程是可以按照网元对象数量切分，通过将所有的管理网元划分成不同的子集，网管每个进程只用管理一部分网元，这样为了增加管理容量，只用增加新的实例进程即可，否则当管理的网元数量为10W级别时，一个告警管理处理所有设备上报的告警会产生延时和积压，最终会影响使用者感知；在进行实例划分后，为了达到消息的高效和可靠，消息格式定义如图5所示，图5为本发明分布式消息处理方法中的消息格式示意图；如图5所示，SN为整形，4字节，表示本条消息的序号，消息订阅者接受到每条消息后可以更新本地记录的SN，下次接受消息时可以从指定的SN开始，必须处理重复和丢失消息；NextSN为整形，4字节，表示本条消息的下一条消息的序号，主要是为了实现内部为了检测消息是否有序；MatchID为整形，4字节，表示消息的匹配ID，订阅者在拉取消息时会传入关注的消息的匹配ID，然后和发布者发布的消息匹配过滤，减少消息量MapKey为整形，4字节，只有覆盖式消息时才需要填写，默认为0。
步骤S112、所述消息发布者采用所述发布者对象发送消息，所述发布者对象根据所述类型和所述消息Topic名称对所述消息进行不同的处理。
可以理解的是，所述消息发布者采用所述发布者对象发送消息，发布对象内部根据消息的类型和Topic名称做不同的处理。
应当理解的是，在进行消息发布的时候，是将消息保存在发布者中等待订阅者来拉取，而没有统一的通知服务NotifyService，避免了单点故障。
需要说明的是，消息分为队列消息和覆盖式消息，队列消息表示所有的消息都是按照顺序存储，上报就是按照加入的顺序上报的；覆盖式消息对于每条消息有唯一键Key，根据Key来覆盖已经存储了的消息，这主要是解决电信网管中告警变化快的问题，如某个管理网元在1s之内上报了1000次告警，每上报一次告警就会触发一次告警灯的计算，然后上报一次告警灯状态。每个管理网元永远只有唯一的最新的告警灯状态，客户也只关心最新的状态，而不用关心中间的变化状态。采用拉消息模式，假设1s拉一次消息，采用覆盖式消息后就只用获取一次消息，并且发布者针对该网元的告警灯消息也只存储一条即可，减少了消息数量。
进一步地，所述步骤S112具体包括以下步骤：
所述消息发布者采用所述发布者对象发送消息；
所述发布者对象根据所述类型和所述消息Topic名称确定所述消息为文件消息时，将所述文件消息存储至独立的文件中；
所述发布者对象根据所述类型和所述消息Topic名称确定所述消息为覆盖式消息时，根据所述覆盖式消息的键对已缓存消息进行替换或增加。
应当理解的是，当有消息需要发送时，消息发布者会采用发布对象发送消息，发布对象内部根据消息的类型和Topic名称做不同的处理，如果是文件消息，那么需要存储到独立的文件中，如果是覆盖式消息，需要将缓存中的消息根据键进行替换或者增加，即根据所述覆盖式消息的键对已缓存消息进行替换或增加。
可以理解的是，消息按照是否可靠可以分为持久化消息和内存消息，而按照类型可以分为队列消息和覆盖式消息，这些都是通过Topic名称附加的前缀来标示的，例如rammap_Topic表示的是内存覆盖式消息，filemap_Topic表示文件覆盖式消息，ramqueue_Topic表示的是内存队列消息，filequeue_Topic表示文件队列消息，所述发布者对象内部实现会针对不同的前缀对不同的消息做不同的处理。
本实施例通过上述方案，通过当有消息需要发送时，所述消息发布者获得所述消息的类型和消息Topic名称；所述消息发布者采用所述发布者对象发送消息，所述发布者对象根据所述类型和所述消息Topic名称对所述消息进行不同的处理；消息发布没有统一的通知服务，每个发布者只用关注和发布自己需要发布的消息，消息可以被持久化；消息传送准确率高，且不容易丢失，订阅者只用获取和自己关注的消息，消息的过滤是直接在发布者中就过滤了，不用拉取所有消息后再在订阅者中过滤，减少了带宽；不仅保证了网管功能的正确性和可靠性，更加保证了功能处理的及时性和高效性。
进一步地，图6为本发明分布式消息处理方法第四实施例的流程示意图，如图6所示，基于第一实施例提出本发明分布式消息处理方法第四实施例，在本实施例中，所述步骤S20具体包括以下步骤：
步骤S21、所述消息订阅者通过目标Topic名称创建订阅对象，并发送所述目标Topic名称至所述全局消息管理器。
需要说明的是，所述消息订阅者一般在启动时就通过目标Topic名称创建订阅对象，创建订阅对象的同时会将所述目标Topic名称至所述全局消息管理器，以利用所述全局消息管理器查询对应的发布者。
步骤S22、所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者。
可以理解的是，所述全局消息管理器在接收到所述目标Topic名称后，会查找与所述目标Topic名称匹配的Topic，并返回对应的主题序号和进程文件序号至所述消息订阅者。
步骤S23、将目标Topic名称对应的主题序号和进程文件序号记录到所述订阅对象中。
在具体实现中，消息订阅者一般在启动时就通过Topic名称创建订阅对象，订阅对象内部通过发送Topic名称至全局消息管理器，所述全局消息管理器通过所述Topic名称进行查询，所述全局消息管理器返回所有的主题序号TopicNo和进程文件序号AgentNo，消息订阅者将目标Topic名称对应的主题序号和进程文件序号记录到订阅对象内部，表示需要从所有进程文件序号AgentNo对应的发布者中拉取消息。
本实施例通过上述方案，通过所述消息订阅者通过目标Topic名称创建订阅对象，并发送所述目标Topic名称至所述全局消息管理器；所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者；将目标Topic名称对应的主题序号和进程文件序号记录到所述订阅对象中，消息发布没有统一的通知服务，每个发布者只用关注和发布自己需要发布的消息，消息可以被持久化；消息传送准确率高，且不容易丢失，订阅者只用获取和自己关注的消息，消息的过滤是直接在发布者中就过滤了，不用拉取所有消息后再在订阅者中过滤，减少了带宽；不仅保证了网管功能的正确性和可靠性，更加保证了功能处理的及时性和高效性。
进一步地，图7为本发明分布式消息处理方法第五实施例的流程示意图，如图7所示，基于第一实施例提出本发明分布式消息处理方法第五实施例，在本实施例中，所述步骤S30具体包括以下步骤：
步骤S31、所述消息订阅者将所述主题序号和所述进程文件序号对应的发布者作为目标发布者。
需要说明的是，所述消息订阅者通过所述主题序号和所述进程文件序号能够从所有消息发布者中确定对应的目标发布者。
步骤S32、通过异步远程过程调用RPC接口将异步拉消息请求发送至所述目标发布者。
可以理解的是，所述消息订阅者在获取消息时是采用统一的RPC接口将异步拉消息请求发送至所述目标发布者，即一般输入消息序号和主题序号对应的异步拉消息请求至所述目标发布者。
步骤S33、接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报。
应当理解的是，在所述消息订阅者输入消息序号和主题序号对应的异步拉消息请求至所述目标发布者后，所述目标发布者会反馈消息序列至所述消息订阅者，所述消息订阅者根据所述消息序列进行消息上报。
本实施例通过上述方案，通过所述消息订阅者将所述主题序号和所述进程文件序号对应的发布者作为目标发布者；通过异步远程过程调用RPC接口将异步拉消息请求发送至所述目标发布者；接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报，消息发布没有统一的通知服务，每个发布者只用关注和发布自己需要发布的消息，消息可以被持久化；消息传送准确率高，且不容易丢失，订阅者只用获取和自己关注的消息，消息的过滤是直接在发布者中就过滤了，不用拉取所有消息后再在订阅者中过滤，减少了带宽；不仅保证了网管功能的正确性和可靠性，更加保证了功能处理的及时性和高效性。
进一步地，图8为本发明分布式消息处理方法第六实施例的流程示意图，如图8所示，基于第五实施例提出本发明分布式消息处理方法第六实施例，在本实施例中，所述步骤S32之后，所述分布式消息处理方法还包括以下步骤：
步骤S321、获取在创建订阅对象时输入的回调对象，从所述回调对象中获取预设回调函数CallBack。
需要说明的是，订阅者在需要订阅消息，必须采用Topic名称创建订阅者对象，创建订阅者对象时，需要输入一个回调对象用于处理订阅者拉取到的消息，例如对上报的消息进行计算或者是展示，所述回调对象中有预设回调函数CallBack。
步骤S322、将所述预设回调函数CallBack反馈至所述消息发布者。
可以理解的是，获得预设回调函数后，可以直接将所述预设回调函数CallBack反馈至所述消息发布者，订阅对象内部会根据Topic名称从全局消息管理器获取所有的发布者服务名称并缓存，后续拉消息时通过统一的拉消息RPC接口从指定的发布者服务获取；拉取消息之后的反馈是通过一个回调对象的预设回调函数CallBack上报给使用者的；使用者需要实现CallBack接口定义的虚函数，然后在创建订阅对象时输入CallBack对象。
本实施例通过上述方案，通过获取在创建订阅对象时输入的回调对象，从所述回调对象中获取预设回调函数CallBack；将所述预设回调函数CallBack反馈至所述消息发布者，能够提高消息传送准确率，且消息不容易丢失，订阅者只用获取和自己关注的消息，消息的过滤是直接在发布者中就过滤了，不用拉取所有消息后再在订阅者中过滤，减少了带宽；不仅保证了网管功能的正确性和可靠性，更加保证了功能处理的及时性和高效性。
进一步地，图9为本发明分布式消息处理方法第七实施例的流程示意图，如图9所示，基于第五实施例提出本发明分布式消息处理方法第七实施例，在本实施例中，所述步骤S33具体包括以下步骤：
步骤S331、接收所述目标发布者返回的消息序列，通过独立线程对所述消息序列进行消息上报。
可以理解的是，消息发布实际上是通过消息订阅者采用统一的RPC接口从发布者中获取的，为了统一处理所有的RPC拉消息请求，消息发布者的发布者进程中采用了至少一个单独的线程；在线程中，根据Topic和所需要获取的消息的序号SN返回消息，一般的，每次最多返回1000条消息，相应的降低了带宽要求。
在具体实现中，消息订阅者的消息订阅进程内部采用至少一个单独的线程来定时拉取所有的订阅者消息；拉取的时间间隔会根据最近是否拉取到了消息进行调整；拉取到消息后通过CallBack反馈。
步骤S332、从所述消息序列中获得Topic数量，在所述Topic数量大于预设阈值时，增加消息上报的独立线程，根据所述独立线程对所述消息序列进行消息上报。
需要说明的是，为了保证消息同主题的顺序上报，每个Topic可以采用一个独立的上报线程，或者所有Topic消息都采用一个线程上报，根据Topic消息量来决定主题是否需要单独创建上报线程，即在所述Topic数量大于预设阈值时，增加消息上报的独立线程，根据所述独立线程对所述消息序列进行消息上报，拉取的该Topic消息会永远投递到单独创建的指定线程。
在具体实现中，发布对象中会缓存上报的所有消息，消息(队列消息时)条数最大为50000条，当超过50000条时会根据SN丢失最先入队列的消息，50000条的限制是根据电信网管及时处理的效率定义的。当存在多个实例进程时，每个实例进程对应的发布者消息条数最大都为50000条。
可以理解的是，发布者内部一般采用线程池来处理本服务收到的所有RPC请求，为了避免当服务本身其他的处理耗时导致拉取消息的RPC无法处理，特开启至少一个单独的线程用于处理拉取消息的RPC请求，当Topic较多时，可能会开启多个线程，但是内部保证同一Topic的拉取RPC请求都分给同一线程，保证消息拉取的顺序。消息拉取每次最多返回1000条消息。
应当理解的是，为了提高拉消息的效率，在订阅者内部采用独立的线程的从发布者获取消息；线程内部拉取的时间间隔会根据最近是否拉取到了消息进行调整，拉取消息的RPC接口采用异步接口，避免阻塞拉取线程；当Topic数量增加时，会自动增加消息拉取线程，每个Topic和拉取线程的绑定关系是固定的；由于消息被拉取后，订阅者肯定需要对消息做一些特性的处理；为了不影响拉取线程和阻塞通信线程，得到消息后采用独立的上报线程来处理；在上报线程中会使用到创建订阅对象时输入的CallBack对象，建议非常耗时的消息处理需要开启单独的处理线程；当Topic数量增加时，会自动增加消息上报线程，每个Topic和上报线程的绑定关系是固定的。
本实施例通过上述方案，通过接收所述目标发布者返回的消息序列，通过独立线程对所述消息序列进行消息上报；从所述消息序列中获得Topic数量，在所述Topic数量大于预设阈值时，增加消息上报的独立线程，根据所述独立线程对所述消息序列进行消息上报；保证消息同主题的顺序上报，避免当服务本身其他的处理耗时导致拉取消息的RPC无法处理，提高了消息上报的速度，提高了拉消息的效率，
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。
Claims (10)
1.一种分布式消息处理方法，其特征在于，所述分布式消息处理方法包括：
消息发布者将发布者信息和Topic名称发送至全局消息管理器，所述全局消息管理器对所述发布者信息和所述Topic名称进行存储；
消息订阅者发送目标Topic名称至所述全局消息管理器，所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者；
所述消息订阅者根据所述主题序号和所述进程文件序号确定目标发布者，将异步拉消息请求发送至所述目标发布者，并接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报。
2.如权利要求1所述的分布式消息处理方法，其特征在于，所述消息发布者将发布者信息和Topic名称发送至全局消息管理器，所述全局消息管理器对所述发布者信息和所述Topic名称进行存储，包括：
消息发布者采用Topic创建发布者对象，并获取Topic名称和所述发布者对象对应的消息发布进程服务名称；
将所述消息发布进程服务名称作为发布者信息，将所述发布者信息和所述Topic名称发送至全局消息管理器；
所述全局消息管理器对所述发布者信息和所述Topic名称进行存储。
3.如权利要求2所述的分布式消息处理方法，其特征在于，所述消息发布者采用Topic创建发布者对象之后，所述分布式消息处理方法还包括：
当有消息需要发送时，所述消息发布者获得所述消息的类型和消息Topic名称；
所述消息发布者采用所述发布者对象发送消息，所述发布者对象根据所述类型和所述消息Topic名称对所述消息进行不同的处理。
4.如权利要求3所述的分布式消息处理方法，其特征在于，所述消息发布者采用所述发布者对象发送消息，所述发布者对象根据所述类型和所述消息Topic名称对所述消息进行不同的处理，包括：
所述消息发布者采用所述发布者对象发送消息；
所述发布者对象根据所述类型和所述消息Topic名称确定所述消息为文件消息时，将所述文件消息存储至独立的文件中；
所述发布者对象根据所述类型和所述消息Topic名称确定所述消息为覆盖式消息时，根据所述覆盖式消息的键对已缓存消息进行替换或增加。
5.如权利要求1所述的分布式消息处理方法，其特征在于，所述消息订阅者发送目标Topic名称至所述全局消息管理器，所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者，包括：
所述消息订阅者通过目标Topic名称创建订阅对象，并发送所述目标Topic名称至所述全局消息管理器；
所述全局消息管理器返回所述目标Topic名称对应的主题序号和进程文件序号至所述消息订阅者；
将目标Topic名称对应的主题序号和进程文件序号记录到所述订阅对象中。
6.如权利要求1-5中任一项所述的分布式消息处理方法，其特征在于，所述消息订阅者根据所述主题序号和所述进程文件序号确定目标发布者，将异步拉消息请求发送至所述目标发布者，并接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报，包括：
所述消息订阅者将所述主题序号和所述进程文件序号对应的发布者作为目标发布者；
通过异步远程过程调用RPC接口将异步拉消息请求发送至所述目标发布者；
接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报。
7.如权利要求6所述的分布式消息处理方法，其特征在于，所述通过异步远程过程调用RPC接口将异步拉消息请求发送至所述目标发布者之后，所述分布式消息处理方法还包括：
获取在创建订阅对象时输入的回调对象，从所述回调对象中获取预设回调函数CallBack；
将所述预设回调函数CallBack反馈至所述消息发布者。
8.如权利要求6所述的分布式消息处理方法，其特征在于，所述接收所述目标发布者返回的消息序列，根据所述消息序列进行消息上报，包括：
接收所述目标发布者返回的消息序列，通过独立线程对所述消息序列进行消息上报；
从所述消息序列中获得Topic数量，在所述Topic数量大于预设阈值时，增加消息上报的独立线程，根据所述独立线程对所述消息序列进行消息上报。
9.如权利要求1-5中任一项所述的分布式消息处理方法，其特征在于，所述消息发布者将发布者信息和Topic名称发送至全局消息管理器，所述全局消息管理器对所述发布者信息和所述Topic名称进行存储之后，所述分布式消息处理方法还包括：
所述全局消息管理器为所述Topic名称分配一个唯一主题序号；
所述全局消息管理器为所述发布者信息分配进程文件序号。
10.一种分布式消息处理设备，其特征在于，所述分布式消息处理设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的分布式消息处理程序，所述分布式消息处理程序配置为实现如权利要求1至9中任一项所述的分布式消息处理方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010851195.6A CN112055061A (zh) | 2020-08-21 | 2020-08-21 | 分布式消息处理方法和设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010851195.6A CN112055061A (zh) | 2020-08-21 | 2020-08-21 | 分布式消息处理方法和设备 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112055061A true CN112055061A (zh) | 2020-12-08 |
Family
ID=73600040
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010851195.6A Pending CN112055061A (zh) | 2020-08-21 | 2020-08-21 | 分布式消息处理方法和设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112055061A (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113098969A (zh) * | 2021-04-09 | 2021-07-09 | 薪得付信息技术(上海)有限公司 | 数据分发方法、装置、系统及电子设备 |
| CN113794597A (zh) * | 2021-09-15 | 2021-12-14 | 中国联合网络通信集团有限公司 | 告警信息处理方法、系统、电子设备及存储介质 |
| CN113992669A (zh) * | 2021-10-25 | 2022-01-28 | 哈尔滨理工大学 | 一种工业内可信消息的分布式数据分发方法 |
| CN115473863A (zh) * | 2022-07-25 | 2022-12-13 | 山东新一代信息产业技术研究院有限公司 | 一种ros与iros的消息桥接方法及系统 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070192325A1 (en) * | 2006-02-01 | 2007-08-16 | Morris Robert P | HTTP publish/subscribe communication protocol |
| US20110131281A1 (en) * | 2009-12-01 | 2011-06-02 | International Business Machines Corporation | Message recall |
| CN108282529A (zh) * | 2018-01-23 | 2018-07-13 | 百度在线网络技术（北京）有限公司 | 发布和订阅数据的系统、方法和装置 |
| CN109857572A (zh) * | 2018-12-29 | 2019-06-07 | 北京百度网讯科技有限公司 | 实现远程调用的方法、装置、设备及计算机可读存储介质 |
-
2020
- 2020-08-21 CN CN202010851195.6A patent/CN112055061A/zh active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070192325A1 (en) * | 2006-02-01 | 2007-08-16 | Morris Robert P | HTTP publish/subscribe communication protocol |
| US20110131281A1 (en) * | 2009-12-01 | 2011-06-02 | International Business Machines Corporation | Message recall |
| CN108282529A (zh) * | 2018-01-23 | 2018-07-13 | 百度在线网络技术（北京）有限公司 | 发布和订阅数据的系统、方法和装置 |
| CN109857572A (zh) * | 2018-12-29 | 2019-06-07 | 北京百度网讯科技有限公司 | 实现远程调用的方法、装置、设备及计算机可读存储介质 |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113098969A (zh) * | 2021-04-09 | 2021-07-09 | 薪得付信息技术(上海)有限公司 | 数据分发方法、装置、系统及电子设备 |
| CN113098969B (zh) * | 2021-04-09 | 2022-12-20 | 薪得付信息技术(上海)有限公司 | 数据分发方法、装置、系统及电子设备 |
| CN113794597A (zh) * | 2021-09-15 | 2021-12-14 | 中国联合网络通信集团有限公司 | 告警信息处理方法、系统、电子设备及存储介质 |
| CN113794597B (zh) * | 2021-09-15 | 2023-05-30 | 中国联合网络通信集团有限公司 | 告警信息处理方法、系统、电子设备及存储介质 |
| CN113992669A (zh) * | 2021-10-25 | 2022-01-28 | 哈尔滨理工大学 | 一种工业内可信消息的分布式数据分发方法 |
| CN115473863A (zh) * | 2022-07-25 | 2022-12-13 | 山东新一代信息产业技术研究院有限公司 | 一种ros与iros的消息桥接方法及系统 |
| CN115473863B (zh) * | 2022-07-25 | 2023-08-08 | 山东新一代信息产业技术研究院有限公司 | 一种ros与iros的消息桥接方法及系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112055061A (zh) | 分布式消息处理方法和设备 | |
| CN112511339B (zh) | 基于多集群的容器监控告警方法、系统、设备及存储介质 | |
| US7366738B2 (en) | Method and system for object cache synchronization | |
| US8090687B2 (en) | Just-in-time publishing via a publish/subscribe messaging system having message publishing controls | |
| CN101252465B (zh) | 告警数据采集方法及其系统中的服务器和客户端 | |
| US8549052B2 (en) | Security event update protocol | |
| CN101222449A (zh) | 发布/订阅系统和方法 | |
| CN103733568A (zh) | 使用客户端-服务器架构的流处理 | |
| US20080071651A1 (en) | Asynchronous events in meta-data driven instrumentation | |
| WO2007040324A1 (en) | Device management method using nodes having additional attribute and device management client thereof | |
| CN106357442A (zh) | 一种服务器集群监控方法及系统 | |
| CN114629883B (zh) | 服务请求的处理方法、装置、电子设备及存储介质 | |
| CN113806651B (zh) | 一种数据缓存方法、装置、服务器及存储介质 | |
| CN115328664A (zh) | 一种消息消费方法、装置、设备及介质 | |
| CN116185895A (zh) | 一种支持多级缓存高并发的实时告警处理方法 | |
| CN114500416A (zh) | 用于最多一次消息投递的投递方法和投递系统 | |
| CN113645260A (zh) | 业务重试方法、装置、存储介质及电子设备 | |
| CN115623071A (zh) | 单机多客户端的发布订阅消息分发方法及系统 | |
| CN116089037A (zh) | 一种异步任务处理实现方法及系统 | |
| US7269618B2 (en) | Server system, client system and difference update system | |
| US7783599B2 (en) | Active data push delivery | |
| CN108881991B (zh) | 弹幕消息分发方法、装置、设备及存储介质 | |
| CN113641385A (zh) | 一种分布式应用参数分发系统 | |
| CN112416975A (zh) | 消息配置方法、电子装置和可读存储介质 | |
| CN110955669A (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 | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20201208 |
|
| RJ01 | Rejection of invention patent application after publication |