CN116319732A - 一种基于RabbitMQ的消息队列集中配置管理系统及方法 - Google Patents

一种基于RabbitMQ的消息队列集中配置管理系统及方法 Download PDF

Info

Publication number
CN116319732A
CN116319732A CN202211091878.1A CN202211091878A CN116319732A CN 116319732 A CN116319732 A CN 116319732A CN 202211091878 A CN202211091878 A CN 202211091878A CN 116319732 A CN116319732 A CN 116319732A
Authority
CN
China
Prior art keywords
client
steps
method comprises
following
configserver
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
Application number
CN202211091878.1A
Other languages
English (en)
Inventor
张帅
高洋
田磊
黄习瑞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Benxi Steel Group Information Automation Co ltd
Original Assignee
Benxi Steel Group Information Automation Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Benxi Steel Group Information Automation Co ltd filed Critical Benxi Steel Group Information Automation Co ltd
Priority to CN202211091878.1A priority Critical patent/CN116319732A/zh
Publication of CN116319732A publication Critical patent/CN116319732A/zh
Pending legal-status Critical Current

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/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • 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/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种基于RabbitMQ的消息队列集中配置管理系统及方法，系统包括：消息队列配置管理模块、消息队列主机本体端、消息队列客户端、协调服务模块和实际数据传输模块；方法包括以下步骤：Client和Agent向Zookeeper注册，并选出master；Client和Agent向ConfigServer取得发行订阅关系；Client和Agent依据取得的订阅关系，通过RabbitMQ进行数据发送，本发明一种基于RabbitMQ的消息队列集中配置管理系统及方法，采用SpringBoot调用RabbitMQ接口，通过Zookeeper进行分布式应用调度，在保证常规信息交换平台的基本功能，又扩展实现了集中配置管理、大文件传输、接收端并发接收、消息数据全流程追踪等功能，满足了系统整合的各种需求，提升了整合效率，降低整合成本。

Description

一种基于RabbitMQ的消息队列集中配置管理系统及方法
技术领域
本发明涉及信息系统整合领域，具体为一种基于RabbitMQ的消息队列集中配置管理系统及方法。
背景技术
随着信息化的蓬勃发展，数据与信息交换需求不断扩张，如果不对系统间的接口方式进行统一规划，任由各信息系统使用自己原生开发的消息传递工具进行系统对接，会导致未来系统的可维护性极差，故障诊断难度加大，且总体性能大大降低。
当前市场上主流的数据交换产品包括RabbitMQ、ActiveMQ、RocketMQ、ZeroMQ等，但是这些解决方案存在如下弊端：
1、数据交换产品作为系统间数据交换的工具，通常是面向IT技术人员，对业务用户的操作支持不是很友好；
2、数据交换产品主要是由各被集成系统向数据交换平台发起连接，配置信息散落在各个业务系统，缺少集中配置管理，同时也缺少对被集成系统的运行状态监控；
3、目前这些数据交换产品不支持大文件传输，或仅支持小文件以字符流的方式进行传输，传输效率低；
4、消息的传输过程在被整合系统和数据交换系统之间天然的割裂开，缺少全流程的穿透式的数据追踪。
5、目前的数据交换产品是全部强迫必须按数据的发送顺序去消化，按顺序消化的代价是无法添加机器并行处理，事实上并不是所有数据都需要有顺序性(如主数据、会计凭证)等问题。
发明内容
本发明的目的在于提供一种基于RabbitMQ的消息队列集中配置管理系统及方法，以解决上述背景技术中提出的问题。
为实现上述目的，本发明提供如下技术方案：一种基于RabbitMQ的消息队列集中配置管理系统，系统包括：消息队列配置管理模块、消息队列主机本体端、消息队列客户端、协调服务模块和实际数据传输模块；
所述消息队列配置管理模块，即ConfigServer，提供用户设定所有相关配置的服务，负责提供Client、Agent发行订阅关系，负责接收数据追踪数据，是集中配置管理方法实现的核心组件；
所述消息队列主机本体端，即Agent，与Host发送数据的Client，对数据传输方式进行二次封装，更易于系统调用，可将电文数据格式与Map类型自动转换；
所述消息队列客户端，即Client，负责与异质系统整合发送数据的客户端，主要提供数据库与文件两大类数据交换方式；
所述协调服务模块，即Zookeeper，协调服务，可供服务达成HA效果，从多结点的Client中选出主/备，从多结点的Agent中选出主/备，实现ConfigServer中查看Client运行状态。
所述实际数据传输模块，即RabbitMQ，负责实际数据传输，实现持久化，HA数据备份增加可靠度。
一种基于RabbitMQ的消息队列集中配置管理方法，包括以下步骤：
步骤1：Client和Agent向Zookeeper注册，并选出master；
步骤2：Client和Agent向ConfigServer取得发行订阅关系；
步骤3：Client和Agent依据取得的订阅关系，通过RabbitMQ进行数据发送。
优选的，所述ConfigServer主要负责用户配置发行/订阅端时同步到RabbitMQ的队列当中，并且每当有异动时通知Client或Agent去更新自己的设定，提供了信息跳过的功能及数据追踪的纪录，所述ConfigServer的运行过程包括：
①：Client或Agent启动时会去zk的
/mq/client/OVERALL/{nodeId_instance_time}
注册一个节点，该节点就是让ConfigServer可以查询有多少Client存活以及该Client的master是谁，而Agent上采用单一接收模式也可以透过zk查询出目前是哪个instance(runtime)负责处理接收；
②：ConfigServer会将所有发行订阅关系记载在自身的DB中，以及会记录数据追踪的日志；
③：每当用户在ConfigServer上有新删修队列，或是绑定不同的发行订阅关系时都会透过API去更新RabbitMQ上真实的队列状态；
④：每当有更新队列状态时，要告知相关的Client或Agent来更新Config，这边也是透过RabbitMQ发送更新信息，当Client接收到之后再主动来到ConfigServer更新自身状态；
⑤：Client端会到ConfigServer更新自身状态，主要只有启动时以及接收到更新信号时才会来做更新；
⑥：Client的流程，当确认自身的发行订阅关系后，Client则可以开始对RabbitMQ发送或者接收信息；
⑦：Client或Agent启动时会去zk的
/mq/client/OVERALL/{nodeId_instance_time}
注册一个节点，该节点就是让ConfigServer可以查询有多少Client存活以及该Client的master是谁，而Agent上采用单一接收模式也可以透过zk查询出目前是哪个instance(runtime)负责处理接收。
优选的，所述Agent是埋藏在AP中的运行服务，主要也是负责与ConfigServer和RabbitMQ的交握与沟通，所述ConfigServer的运行过程包括：
①：Agent启动会去zk的
/mq/client/OVERALL/{nodeId_instance_time}注册一个节点，该节点就是让ConfigServer可以查询有多少Agent存活的地方，以及若Agent若采用单一接收模式，会到zk的/mq/client/{nodeId}/{queueId}抢占Master，抢到Master的可以运行，没抢到的则以slave状态存活；
②：ConfigServer会时时在zk监控/mq/client/OVERALL/随时查看是否有新的client或者agent加入，并更新状态；
③：Agent至ConfigServer询问自己(nodeId)需要发送的发行端(Pub)及订阅端(Sub)为何；
④：针对自己所需要处理的订阅端，会从设定中找出要执行的class，每当收到信息时就会启动该class并将data给进该class中，发行端则是等待撰写程序有调用到put时建立，并发送信息；
⑤：发行端(Pub)往RabbitMQ指定的nodeId_queueId的exchange发送，而监听nodeId_queueId的queue做接收。
优选的，所述Client是透过文件系统或者数据表中读取数据，并将数据送往指定的Queue去，所述Client的运行过程包括：
①：Client启动会去zk的
/mq/client/OVERALL/{nodeId_instance_time}注册一个节点，该节点就是让ConfigServer可以查询有多少Client存活的地方。以及Client会到zk的/mq/client/{nodeId}抢占master，抢到master的可以运行，没抢到的则以slave状态存活；
②：Config Server会时时在zk监控/mq/client/OVERALL/随时查看是否有新的client或者agent加入，并更新状态；
③：Client至ConfigServer询问自己(nodeId)需要发送的发行端(Pub)及订阅端(Sub)为何；
④：针对自己所需要处理的发行端，从数据库或是文件系统中找到数据，并往RabbitMQ发送，或是监听接收端收到RabbitMQ的数据后存到相对应的数据库或者文件系统中；
⑤：发行端(Pub)往RabbitMQ指定的nodeId_queueId的exchange发送，而监听nodeId_queueId的queue做接收。
优选的，所述系统大文件传输的运行过程包括：
①：Client或Agent启动时会去zk的
/mq/client/OVERALL/{nodeId_instance_time}
注册一个节点，该节点就是让ConfigServer可以查询有多少Client存活，目前是哪个instance(runtime)负责处理接收。
②：Client与Agent至Config Server询问自己(nodeId)需要发送的发行端(Pub)及订阅端(Sub)为何；
③：Client与Agent至Config Server询问自己(nodeId)需要发送的发行端(Pub)及订阅端(Sub)为何；
④：AP调用Agent封装的接口通过sftp协议上传大文件到sftp服务器；
⑤：Agent依据流程2获得的发行订阅关系，将文件地址通过RabbitMQ进行传输；
⑥：Client依据流程3获得的发行订阅关系，从RabbitMQ接收文件地址；
⑦：Client根据接收到的文件地址到sftp服务器进行文件下载；
⑧：Client将大文件接收成功或失败的信息通过RabbitMQ返回到发送端；
⑨：Client将大文件接收成功或失败的信息通过RabbitMQ返回到发送端。
与现有技术相比，本发明的有益效果是：
实现消息队列配置集中管理，并且通过配置管理对相关信息进行授权管理，同时可以监控客户端的运行状态；
实现大文件、大批量数据的交换模式，在异质系统交换过程中只需将文件或数据表的参考地址作为交换标的，比起目前必须将数据逐笔拆解与追踪的做法，有效降低整体的运算开销，进而提高吞吐量；
支持消息接收端的并行消化策略。本发明实现了接收端数据队列的分类处理，可以通过配置设置单一处理模式，用于保证电文数据的接收顺序，也可以对不需要顺序的数据队列设置多机器的并行处理模式，提高传输量以及吞吐量。
实现全流程数据追踪，实现了一个清晰的全流程数据监控，传输发生异常时，第一时间告警相关人员马上处理，将异常带来的损失降至最低。
附图说明
图1为本发明的消息队列集中配置管理方法整体实现流程图；
图2为本发明的configserver端运行原理图；
图3为本发明的agent端运行原理图；
图4为本发明的client端运行原理图；
图5为本发明的大文件传输实现原理图；
图6为本发明的消息发行端和订阅端的并发示意图；
图7为本发明的数据传输全流程追踪示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
请参阅图1-7，本发明提供了一种基于RabbitMQ的消息队列集中配置管理系统，系统包括：消息队列配置管理模块、消息队列主机本体端、消息队列客户端、协调服务模块和实际数据传输模块；
消息队列配置管理模块，即ConfigServer，提供用户设定所有相关配置的服务，负责提供Client、Agent发行订阅关系，负责接收数据追踪数据，是集中配置管理方法实现的核心组件，消息队列配置管理模块，通过配置中心统一提供异质系统间发行/订阅端消息队列建立、消息队列关联关系建立。同时实现交互消息的数据跟踪；
消息队列主机本体端，即Agent，与Host发送数据的Client，对数据传输方式进行二次封装，更易于系统调用，可将电文数据格式与Map类型自动转换，主机本体端，为当前系统，并且需要与异质系统进行数据交互的信息系统，对数据传输方式进行二次封装，更易于系统调用，可将电文数据格式与Map类型自动转换；
消息队列客户端，即Client，负责与异质系统整合发送数据的客户端，主要提供数据库与文件两大类数据交换方式，客户端，为与当前系统不同，并且需要与当前应用系统进行数据交互的各种异质信息系统，通过消息队列可以实现主数据库与文件两大类数据的交互；
协调服务模块，即Zookeeper，协调服务，可供服务达成HA效果，从多结点的Client中选出主/备，从多结点的Agent中选出主/备，实现ConfigServer中查看Client运行状态。
实际数据传输模块，即RabbitMQ，负责实际数据传输，实现持久化，HA数据备份增加可靠度。
一种基于RabbitMQ的消息队列集中配置管理方法，包括以下步骤：
步骤1：Client和Agent向Zookeeper注册，并选出master；
步骤2：Client和Agent向ConfigServer取得发行订阅关系；
步骤3：Client和Agent依据取得的订阅关系，通过RabbitMQ进行数据发送。
ConfigServer主要负责用户配置发行/订阅端时同步到RabbitMQ的队列当中，并且每当有异动时通知Client或Agent去更新自己的设定，提供了信息跳过的功能及数据追踪的纪录，ConfigServer的运行过程包括：
①：Client或Agent启动时会去zk的
/mq/client/OVERALL/{nodeId_instance_time}
注册一个节点，该节点就是让ConfigServer可以查询有多少Client存活以及该Client的master是谁，而Agent上采用单一接收模式也可以透过zk查询出目前是哪个instance(runtime)负责处理接收；
②：ConfigServer会将所有发行订阅关系记载在自身的DB中，以及会记录数据追踪的日志；
③：每当用户在ConfigServer上有新删修队列，或是绑定不同的发行订阅关系时都会透过API去更新RabbitMQ上真实的队列状态；
④：每当有更新队列状态时，要告知相关的Client或Agent来更新Config，这边也是透过RabbitMQ发送更新信息，当Client接收到之后再主动来到ConfigServer更新自身状态；
⑤：Client端会到ConfigServer更新自身状态，主要只有启动时以及接收到更新信号时才会来做更新；
⑥：Client的流程，当确认自身的发行订阅关系后，Client则可以开始对RabbitMQ发送或者接收信息；
⑦：Client或Agent启动时会去zk的
/mq/client/OVERALL/{nodeId_instance_time}
注册一个节点，该节点就是让ConfigServer可以查询有多少Client存活以及该Client的master是谁，而Agent上采用单一接收模式也可以透过zk查询出目前是哪个instance(runtime)负责处理接收。
Agent是埋藏在AP中的运行服务，主要也是负责与ConfigServer和RabbitMQ的交握与沟通，使用者只需要专注于写程序调用Agent的方法就可以传输及接收信息，ConfigServer的运行过程包括：
①：Agent启动会去zk的
/mq/client/OVERALL/{nodeId_instance_time}注册一个节点，该节点就是让ConfigServer可以查询有多少Agent存活的地方，以及若Agent若采用单一接收模式，会到zk的/mq/client/{nodeId}/{queueId}抢占Master，抢到Master的可以运行，没抢到的则以slave状态存活；
②：ConfigServer会时时在zk监控/mq/client/OVERALL/随时查看是否有新的client或者agent加入，并更新状态；
③：Agent至ConfigServer询问自己(nodeId)需要发送的发行端(Pub)及订阅端(Sub)为何；
④：针对自己所需要处理的订阅端，会从设定中找出要执行的class，每当收到信息时就会启动该class并将data给进该class中，发行端则是等待撰写程序有调用到put时建立，并发送信息；
⑤：发行端(Pub)往RabbitMQ指定的nodeId_queueId的exchange发送，而监听nodeId_queueId的queue做接收。
Client是透过文件系统或者数据表中读取数据，并将数据送往指定的Queue去，Client的运行过程包括：
①：Client启动会去zk的
/mq/client/OVERALL/{nodeId_instance_time}注册一个节点，该节点就是让ConfigServer可以查询有多少Client存活的地方。以及Client会到zk的/mq/client/{nodeId}抢占master，抢到master的可以运行，没抢到的则以slave状态存活；
②：Config Server会时时在zk监控/mq/client/OVERALL/随时查看是否有新的client或者agent加入，并更新状态；
③：Client至ConfigServer询问自己(nodeId)需要发送的发行端(Pub)及订阅端(Sub)为何；
④：针对自己所需要处理的发行端，从数据库或是文件系统中找到数据，并往RabbitMQ发送，或是监听接收端收到RabbitMQ的数据后存到相对应的数据库或者文件系统中；
⑤：发行端(Pub)往RabbitMQ指定的nodeId_queueId的exchange发送，而监听nodeId_queueId的queue做接收。
系统间大文件交换过程只需将文件的参考地址作为交换标的，系统大文件传输的运行过程包括：
①：Client或Agent启动时会去zk的
/mq/client/OVERALL/{nodeId_instance_time}
注册一个节点，该节点就是让ConfigServer可以查询有多少Client存活，目前是哪个instance(runtime)负责处理接收。
②：Client与Agent至Config Server询问自己(nodeId)需要发送的发行端(Pub)及订阅端(Sub)为何；
③：Client与Agent至Config Server询问自己(nodeId)需要发送的发行端(Pub)及订阅端(Sub)为何；
④：AP调用Agent封装的接口通过sftp协议上传大文件到sftp服务器；
⑤：Agent依据流程2获得的发行订阅关系，将文件地址通过RabbitMQ进行传输；
⑥：Client依据流程3获得的发行订阅关系，从RabbitMQ接收文件地址；
⑦：Client根据接收到的文件地址到sftp服务器进行文件下载；
⑧：Client将大文件接收成功或失败的信息通过RabbitMQ返回到发送端；
⑨：Client将大文件接收成功或失败的信息通过RabbitMQ返回到发送端。
具体使用时，本发明一种基于RabbitMQ的消息队列集中配置管理系统及方法，集群架构赋予系统HA及负载平衡的能力，Server可按需扩充，Server之间有互备策略，架构中某一台故障二部影响整体服务，达到高可用。本发明分别在两端都部署了负载平衡器，策略性地将流量引导至不同的Server，将数据分布在多个不同的消化端，达到负载平衡的效果；
数据在交换过程中所流过的每一站，皆留下清楚的履历，何时送出，何时收到，何时堵塞有异常，都被清楚记录下来。过去虽然在Server有完整记录，但是数据追踪的过程必须由IT人员协助分析，数据送到第三方系统之后，整个追踪流程就断了。本发明实现的是一个清晰的全流程数据监控，用户不必游走于AP画面与数据交换系统，而只需要在其原始的操作页面即可进行穿透式的数据跟踪，数据流程的所有信息清楚被揭露；
本发明还实现自我监控状况监控功能，包括client心跳监控，流速监控，传输异常监控等，让所有异常情况能第一时间告警相关人员马上处理，将异常带来的损失降至最低；
综上所述，本发明采用SpringBoot调用RabbitMQ接口，通过Zookeeper进行分布式应用调度，在保证常规信息交换平台的基本功能，又扩展实现了集中配置管理、大文件传输、接收端并发接收、消息数据全流程追踪等功能，满足了系统整合的各种需求，提升了整合效率，降低整合成本。
尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (6)

1.一种基于RabbitMQ的消息队列集中配置管理系统，其特征在于，系统包括：消息队列配置管理模块、消息队列主机本体端、消息队列客户端、协调服务模块和实际数据传输模块；
所述消息队列配置管理模块，即ConfigServer，提供用户设定所有相关配置的服务，负责提供Client、Agent发行订阅关系，负责接收数据追踪数据，是集中配置管理方法实现的核心组件；
所述消息队列主机本体端，即Agent，与Host发送数据的Client，对数据传输方式进行二次封装，更易于系统调用，可将电文数据格式与Map类型自动转换；
所述消息队列客户端，即Client，负责与异质系统整合发送数据的客户端，主要提供数据库与文件两大类数据交换方式；
所述协调服务模块，即Zookeeper，协调服务，可供服务达成HA效果，从多结点的Client中选出主/备，从多结点的Agent中选出主/备，实现ConfigServer中查看Client运行状态。
所述实际数据传输模块，即RabbitMQ，负责实际数据传输，实现持久化，HA数据备份增加可靠度。
2.根据权利要求1所述的一种基于RabbitMQ的消息队列集中配置管理方法，其特征在于，包括以下步骤：
步骤1：Client和Agent向Zookeeper注册，并选出master；
步骤2：Client和Agent向ConfigServer取得发行订阅关系；
步骤3：Client和Agent依据取得的订阅关系，通过RabbitMQ进行数据发送。
3.根据权利要求1所述的一种基于RabbitMQ的消息队列集中配置管理系统，其特征在于：所述ConfigServer主要负责用户配置发行/订阅端时同步到RabbitMQ的队列当中，并且每当有异动时通知Client或Agent去更新自己的设定，提供了信息跳过的功能及数据追踪的纪录，所述ConfigServer的运行过程包括：
①：Client或Agent启动时会去zk的/mq/client/OVERALL/{nodeId_instance_time}
注册一个节点，该节点就是让ConfigServer可以查询有多少Client存活以及该Client的master是谁，而Agent上采用单一接收模式也可以透过zk查询出目前是哪个instance(runtime)负责处理接收；
②：ConfigServer会将所有发行订阅关系记载在自身的DB中，以及会记录数据追踪的日志；
③：每当用户在ConfigServer上有新删修队列，或是绑定不同的发行订阅关系时都会透过API去更新RabbitMQ上真实的队列状态；
④：每当有更新队列状态时，要告知相关的Client或Agent来更新Config，这边也是透过RabbitMQ发送更新信息，当Client接收到之后再主动来到ConfigServer更新自身状态；
⑤：Client端会到ConfigServer更新自身状态，主要只有启动时以及接收到更新信号时才会来做更新；
⑥：Client的流程，当确认自身的发行订阅关系后，Client则可以开始对RabbitMQ发送或者接收信息；
⑦：Client或Agent启动时会去zk的
/mq/client/OVERALL/{nodeId_instance_time}
注册一个节点，该节点就是让ConfigServer可以查询有多少Client存活以及该Client的master是谁，而Agent上采用单一接收模式也可以透过zk查询出目前是哪个instance(runtime)负责处理接收。
4.根据权利要求1所述的一种基于RabbitMQ的消息队列集中配置管理系统，其特征在于：所述Agent是埋藏在AP中的运行服务，主要也是负责与ConfigServer和RabbitMQ的交握与沟通，所述ConfigServer的运行过程包括：
①：Agent启动会去zk的
/mq/client/OVERALL/{nodeId_instance_time}注册一个节点，该节点就是让ConfigServer可以查询有多少Agent存活的地方，以及若Agent若采用单一接收模式，会到zk的/mq/client/{nodeId}/{queueId}抢占Master，抢到Master的可以运行，没抢到的则以slave状态存活；
②：ConfigServer会时时在zk监控/mq/client/OVERALL/随时查看是否有新的client或者agent加入，并更新状态；
③：Agent至ConfigServer询问自己(nodeId)需要发送的发行端(Pub)及订阅端(Sub)为何；
④：针对自己所需要处理的订阅端，会从设定中找出要执行的class，每当收到信息时就会启动该class并将data给进该class中，发行端则是等待撰写程序有调用到put时建立，并发送信息；
⑤：发行端(Pub)往RabbitMQ指定的nodeId_queueId的exchange发送，而监听nodeId_queueId的queue做接收。
5.根据权利要求1所述的一种基于RabbitMQ的消息队列集中配置管理系统，其特征在于：所述Client是透过文件系统或者数据表中读取数据，并将数据送往指定的Queue去，所述Client的运行过程包括：
①：Client启动会去zk的
/mq/client/OVERALL/{nodeId_instance_time}注册一个节点，该节点就是让ConfigServer可以查询有多少Client存活的地方。以及Client会到zk的/mq/client/{nodeId}抢占master，抢到master的可以运行，没抢到的则以slave状态存活；
②：Config Server会时时在zk监控/mq/client/OVERALL/随时查看是否有新的client或者agent加入，并更新状态；
③：Client至ConfigServer询问自己(nodeId)需要发送的发行端(Pub)及订阅端(Sub)为何；
④：针对自己所需要处理的发行端，从数据库或是文件系统中找到数据，并往RabbitMQ发送，或是监听接收端收到RabbitMQ的数据后存到相对应的数据库或者文件系统中；
⑤：发行端(Pub)往RabbitMQ指定的nodeId_queueId的exchange发送，而监听nodeId_queueId的queue做接收。
6.根据权利要求1所述的一种基于RabbitMQ的消息队列集中配置管理系统，其特征在于：所述系统大文件传输的运行过程包括：
①：Client或Agent启动时会去zk的
/mq/client/OVERALL/{nodeId_instance_time}
注册一个节点，该节点就是让ConfigServer可以查询有多少Client存活，目前是哪个instance(runtime)负责处理接收。
②：Client与Agent至Config Server询问自己(nodeId)需要发送的发行端(Pub)及订阅端(Sub)为何；
③：Client与Agent至Config Server询问自己(nodeId)需要发送的发行端(Pub)及订阅端(Sub)为何；
④：AP调用Agent封装的接口通过sftp协议上传大文件到sftp服务器；
⑤：Agent依据流程2获得的发行订阅关系，将文件地址通过RabbitMQ进行传输；
⑥：Client依据流程3获得的发行订阅关系，从RabbitMQ接收文件地址；
⑦：Client根据接收到的文件地址到sftp服务器进行文件下载；
⑧：Client将大文件接收成功或失败的信息通过RabbitMQ返回到发送端；
⑨：Client将大文件接收成功或失败的信息通过RabbitMQ返回到发送端。
CN202211091878.1A 2022-09-07 2022-09-07 一种基于RabbitMQ的消息队列集中配置管理系统及方法 Pending CN116319732A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211091878.1A CN116319732A (zh) 2022-09-07 2022-09-07 一种基于RabbitMQ的消息队列集中配置管理系统及方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211091878.1A CN116319732A (zh) 2022-09-07 2022-09-07 一种基于RabbitMQ的消息队列集中配置管理系统及方法

Publications (1)

Publication Number Publication Date
CN116319732A true CN116319732A (zh) 2023-06-23

Family

ID=86820929

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211091878.1A Pending CN116319732A (zh) 2022-09-07 2022-09-07 一种基于RabbitMQ的消息队列集中配置管理系统及方法

Country Status (1)

Country Link
CN (1) CN116319732A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116668493A (zh) * 2023-07-25 2023-08-29 森智明信息科技南京有限公司 一种分布式场景下mqtt物联网设备的消息处理系统
CN117114695A (zh) * 2023-10-19 2023-11-24 本溪钢铁（集团）信息自动化有限责任公司 基于钢铁行业智能客服的交互方法及装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116668493A (zh) * 2023-07-25 2023-08-29 森智明信息科技南京有限公司 一种分布式场景下mqtt物联网设备的消息处理系统
CN116668493B (zh) * 2023-07-25 2023-10-24 森智明信息科技南京有限公司 一种分布式场景下mqtt物联网设备的消息处理系统
CN117114695A (zh) * 2023-10-19 2023-11-24 本溪钢铁（集团）信息自动化有限责任公司 基于钢铁行业智能客服的交互方法及装置
CN117114695B (zh) * 2023-10-19 2024-01-26 本溪钢铁（集团）信息自动化有限责任公司 基于钢铁行业智能客服的交互方法及装置

Similar Documents

Publication Publication Date Title
CN116319732A (zh) 一种基于RabbitMQ的消息队列集中配置管理系统及方法
US7886295B2 (en) Connection manager, method, system and program product for centrally managing computer applications
US7694178B2 (en) Method, apparatus and computer program product for transaction recovery
CN100407627C (zh) 一种实现端到端文件共享的系统及方法
CN102710593B (zh) 一种图形聚合中的消息分发方法及装置、系统
CN112788074B (zh) 数据发送方法、处理方法、接收方法及其设备、存储介质
CN107528891B (zh) 一种基于WebSocket的自动集群方法及其系统
CN112711635B (zh) 一种分布式物联设备跨区域数据一致性的方法和服务集群
CN101262369B (zh) 调度服务器的主备实现方法及调度服务器
CN108712457A (zh) 基于Nginx反向代理的后端服务器动态负载调整方法及装置
CN112422684B (zh) 目标消息的处理方法及装置、存储介质、电子装置
CN113391979A (zh) 监控数据展示的处理方法、设备、系统及存储介质
CN110636127A (zh) 一种各信息数据间的通信处理方法及系统
CN107071067B (zh) 一种基于Cgo的高性能证券行情接入系统和方法
CN114338769B (zh) 访问请求的处理方法及装置
CN111309691A (zh) 基于总线架构的数据共享交换系统和交换方法
CN114461424A (zh) 单元化部署架构下的单元间服务发现方法、装置及系统
CN116266145A (zh) 一种处理调用的方法、系统和设备
CN114244678A (zh) 多协议告警设备接入方法及系统
JP2006031491A (ja) アプリケーション間連携システム
CN115102854B (zh) 微服务的远程过程调用路由管理控制方法、系统及设备
CN114884948B (zh) 一种数据处理系统
CN104298750B (zh) 用于实时系统通信的更新处理方法及装置
CN115865651B (zh) 一种数据采集方法、装置、电子设备及存储介质
CN113626210B (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