CN113626210A - Power grid operation risk early warning information transfer method and storage system - Google Patents
Power grid operation risk early warning information transfer method and storage system Download PDFInfo
- Publication number
- CN113626210A CN113626210A CN202110709127.0A CN202110709127A CN113626210A CN 113626210 A CN113626210 A CN 113626210A CN 202110709127 A CN202110709127 A CN 202110709127A CN 113626210 A CN113626210 A CN 113626210A
- Authority
- CN
- China
- Prior art keywords
- message
- queue
- user
- module
- exchange
- 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
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/55—Push-based network services
-
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0635—Risk analysis of enterprise or organisation activities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/06—Electricity, gas or water supply
-
- 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
- Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
- Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
- Y04S10/00—Systems supporting electrical power generation, transmission or distribution
- Y04S10/50—Systems or methods supporting the power network operation or management, involving a certain degree of interaction with the load-side end user applications
Abstract
The invention relates to a power grid operation risk early warning information transfer method and a storage system, and belongs to the technical field of risk early warning information transfer. The method comprises the steps of message theme management, message subscription, message monitoring, message processing, message production, message pushing, message exception processing and the like. The invention realizes a power grid risk early warning information transfer method based on RabbitMQ + WebSocket + Redis, solves the information transfer of power grid risk early warning transfer, and realizes quasi-real-time message transfer; the system has the advantages that the quasi-real-time reminding of the messages can be realized in each link of the power grid operation risk early warning process flow, the problem that the power grid operation risk early warning information flow needs to be checked manually at regular time in the system is effectively solved, and the working efficiency is greatly improved.
Description
Technical Field
The invention belongs to the technical field of risk early warning information transfer, and particularly relates to a power grid operation risk early warning information transfer method and a storage system.
Background
At present, the informatization construction of a power grid is in a high-speed development stage, the digital transformation becomes a key strategy for future energy and power development, and the informatization of the operation management of the power grid is a key field of the power grid in the digital transformation. In view of the specialty and complexity of the power grid operation management service, a method for pushing messages according to service scenes is urgently needed, and the message pushing method has important significance for the construction of a power grid management system.
The RabbitMQ is open source message middleware following AMQP (advanced message queuing protocol), can be used for storing and forwarding messages in a distributed system, and has excellent usability, expansibility, high availability and the like; WebSocket is a protocol for full-duplex communication on a single TCP connection, and is mainly characterized in that a server can actively push information to a client, and the client can also actively send information to the server, so that the WebSocket is a real two-way equal conversation.
The workload of technical improvement, capital construction and new equipment commissioning brought by the high-speed development of the power grid is greatly increased, the operation mode of the power grid is frequently changed, abnormal operation modes and special operation modes are difficult to avoid, the safe and stable operation of the power grid is threatened, and the operation risk of the power grid plays an important role in the safe and stable operation of the power grid. Circulation of power grid risk early warning information plays a key role in power grid operation risk management; how to transfer the whole process from risk assessment to risk early warning feedback of power grid risk early warning to realize timely message transmission is a problem to be solved by a power grid operation risk management and control system.
At present, a power grid operation management system has various technical achievements, but at present, a quasi-real-time message pushing method based on RabbitMQ, WebSocket and Redis does not exist.
Disclosure of Invention
The invention aims to overcome the defects of the prior art and provides a power grid operation risk early warning information transfer method and a storage system.
In order to achieve the purpose, the technical scheme adopted by the invention is as follows:
a power grid operation risk early warning information transfer method specifically comprises the following steps:
the message center comprises a message theme management module, a message subscription module, a message monitoring module, a message processing module, a message production module, a message pushing module and a message exception processing module;
the power grid operation risk early warning information transfer method comprises the following steps:
step (1), message theme management: managing risk early warning message themes through a message theme management module, wherein all places related to the message themes need to acquire data from the message theme management module, and a user needs to register the message themes in the message theme management module before using the message themes;
step (2), subscribing the message:
(2.1) message topic configuration: configuring default exchange, namely a message topic, through a message subscription module; the type of the default exchange is a fanout type, namely a broadcast mode type; the name of exchange is sys _ msg; all queues need to be bound to the exchange for the first construction; the role of the default exchange is to broadcast system messages;
(2.2) message queue establishment: using cluster mode deployment, naming according to naming rules of the message queue; after a user logs in an application system, a message subscription module assembles a message queue according to a message queue naming rule; inquiring whether the queue exists from the RabbitMQ according to the queue name, and if so, not processing; if the queue does not exist, constructing a new message queue, and binding the new message queue with the default exchange configured in the step (2.1), wherein the RoutengKey of the queue is the user ID of the user;
step (3), message monitoring:
after the message center is started, a SimpleMessageListenerContainer message monitoring container can be automatically created; after the message subscription is finished, the message monitoring module reads the information of a SimpleMessageListenerContainer monitoring container on the current message center server, checks whether the current queue is in the monitoring container, and if the current queue is not in the monitoring container, the message center adds the queue into the monitoring container and restarts monitoring;
step (4), message processing: after the message monitoring module is started, the message monitoring module monitors that the message is in the queue, and then the message processing module is actively called to process the message; the message processing module acquires a queue name, exchange and a routing Key according to the current queue information; analyzing and acquiring a user ID according to a queue naming rule; calling a WebSocket message sending method through a message pushing module, and pushing a message to a client;
step (5), message production:
the message production party produces messages through the message production module, and the produced messages comprise exchange names, RoutengKey and message contents; converting all types of routes into user IDs; querying all queues containing the user IDs in the RabbitMQ through the converted user IDs; binding the inquired queue with exchange, wherein a RouteingKey of the exchange is a corresponding user ID; when the queue is bound with the exchange, inquiring whether the exchange exists or not, if not, constructing the exchange, and then binding the queue with the exchange; after the binding of the queue and the exchange is finished, directly sending a message to the exchange;
step (6), message pushing:
(6.1) after the user logs in the application system through the browser, the browser actively sends a connection request to the message center through WebSocket connection; after receiving the request, the message pushing module authenticates the current connected user according to the received token, and if the current connection is not the system effective connection, the message pushing module automatically disconnects the Websocket connection; if the current connection is a system active connection, then (6.2);
(6.2) the message pushing module inquires whether unprocessed messages exist or not according to the user ID to the redis, if the unprocessed messages exist, the unprocessed messages are pushed to the client preferentially; acquiring a RabbitMQ monitoring container, and if the monitoring container is not started, starting the monitoring container; judging whether the queue containing the user ID is in monitoring, if not, adding the inquired queue into a monitoring container, and restarting monitoring;
(6.3) the message pushing module receives the message pushed by the message monitoring module, and judges whether the message is a message which needs to be received by the current user according to the user ID in the message and the user ID connected with the WebSocket; if so, directly calling a sendMessage method of the WebSocket to push the message to the client; if not, storing the message into a redis cache;
step (7), message exception handling:
(7.1) message unconsumed Process: when the message monitoring module monitors that a queue has messages and WebSocket connection is abnormal, storing the messages in the queue into a redis cache; when the WebSocket connection is normal, the message exception processing module matches KEY containing the user ID in the redis cache through the user ID to acquire a message, then pushes the message to the client, and simultaneously clears the corresponding message in the redis cache;
(7.2) when the Channel connection is abnormal or WebSocket consumption is blocked when the message monitoring module monitors the queue to process the message, the abnormal message is put into the queue again to sleep for 15 seconds, and then the step (3.2) is executed.
Further, it is preferable that in step (1), the subject of the message is used to correspond to the exchange switch of the RabbitMQ.
Further, preferably, in step (2.2), the docker application cluster is used for deployment when the message queue is established;
the naming rule is specifically as follows: user ID + ": "+ apply server IP +" of the currently connected message center node: "+ docker container port number of the currently connected node.
Further, preferably, the message monitoring module monitors the message condition in the message queue, and when a message to be consumed appears in the queue, the message is processed by the message processing module, and then the sending message method sendMessage of WebSocket in the message pushing module is called by the message processing method onMessage in the channelawaremessalistener, and the message is sent to the message pushing module; after the message is sent, the message processing module calls a basicAck method of Channel in the RabbitMQ to confirm that the message is sent to the message pushing module, and simultaneously calls a queueUnbind method of Channel in the RabbitMQ to release the binding relationship between the queue and the theme, and system resources are released.
Further, it is preferable that, in step (4), if the processed message is not a system message, the binding between the queue and the exchange needs to be released after the message processing is completed.
Further, it is preferable that, in step (5), routingkeys are of three types: user ID, organization ID, role ID; and (4) replacing the user ID in the step (2) and the step (4) to the step (7) with an organization ID or a role ID.
Further, in step (6.1), preferably, the request information includes the token information of the user and the message topic to which the user requests subscription.
Further, preferably, in the step (6), after the user is connected to the message pushing module through the step (6.1), if the current connection is valid, the client sends a heartbeat data packet to the message pushing module every 15 seconds, so that the WebSocket is ensured to be continuously valid, and the message can be normally pushed to the client;
in the step (6), after the message pushing module detects that the WebSocket is disconnected, the message monitoring module is controlled to remove the currently monitored queue for monitoring.
Further, it is preferable that, in step (7.1), the KEY when stored in the redis cache is assembled by: UNSEND _ system time value _ user ID.
The invention also provides a power grid operation risk early warning information transfer and storage system, which is stored with a computer program, and is characterized in that the computer program realizes the steps of the power grid operation risk early warning information transfer method when being executed by a processor.
The application system in fig. 1 of the present invention may refer to a power grid operation risk management and control system, but is not limited thereto.
The client is preferably a browser in the invention.
Compared with the prior art, the invention has the beneficial effects that:
the invention realizes a power grid risk early warning information transfer method based on RabbitMQ + WebSocket + Redis, solves the information transfer of power grid risk early warning transfer, and realizes quasi-real-time message transfer; the system has the advantages that the quasi-real-time reminding of the messages can be realized in each link of the power grid operation risk early warning process flow, the problem that the power grid operation risk early warning information flow needs to be checked manually at regular time in the system is effectively solved, and the working efficiency is greatly improved.
Before the method is introduced, after the power grid risk early warning information is transferred to the related responsible persons, the responsible persons in the next link are informed by the phone of each responsible person in the risk early warning transfer link or the responsible persons in the next link update the proxy list at irregular time to obtain related data; after the method is introduced, if the responsible person has the task to be handled, the message center pushes the message to the browser end of the user, and the message automatically pops up in the lower right corner of the application system interface for reminding; the time from production to browser-side display of the message is less than 1 second, the popup reminding time stays for 15 seconds, and a plurality of messages are displayed in a stacked mode. The user can timely know the task condition through the message, and the working efficiency is greatly improved.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to these drawings without creative efforts.
FIG. 1 is a schematic diagram of the overall structure of the present invention;
fig. 2 is a schematic structural diagram of a message center according to the present invention.
Detailed Description
The present invention will be described in further detail with reference to examples.
It will be appreciated by those skilled in the art that the following examples are illustrative of the invention only and should not be taken as limiting the scope of the invention. The specific techniques, connections, conditions, or the like, which are not specified in the examples, are performed according to the techniques, connections, conditions, or the like described in the literature in the art or according to the product specification. The materials, instruments or equipment are not indicated by manufacturers, and all the materials, instruments or equipment are conventional products which can be obtained by purchasing.
As used herein, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It will be understood by those skilled in the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the prior art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
A power grid operation risk early warning information transfer method specifically comprises the following steps:
the message center comprises a message theme management module, a message subscription module, a message monitoring module, a message processing module, a message production module, a message pushing module and a message exception processing module;
the power grid operation risk early warning information transfer method comprises the following steps:
step (1), message theme management: managing risk early warning message themes through a message theme management module, wherein all places related to the message themes need to acquire data from the message theme management module, and a user needs to register the message themes in the message theme management module before using the message themes;
step (2), subscribing the message:
(2.1) message topic configuration: configuring default exchange, namely a message topic, through a message subscription module; the type of the default exchange is a fanout type, namely a broadcast mode type; the name of exchange is sys _ msg; all queues need to be bound to the exchange for the first construction; the role of the default exchange is to broadcast system messages;
(2.2) message queue establishment: using cluster mode deployment, naming according to naming rules of the message queue; after a user logs in an application system, a message subscription module assembles a message queue according to a message queue naming rule; inquiring whether the queue exists from the RabbitMQ according to the queue name, and if so, not processing; if the queue does not exist, constructing a new message queue, and binding the new message queue with the default exchange configured in the step (2.1), wherein the RoutengKey of the queue is the user ID of the user;
step (3), message monitoring:
after the message center is started, a SimpleMessageListenerContainer message monitoring container can be automatically created; after the message subscription is finished, the message monitoring module reads the information of a SimpleMessageListenerContainer monitoring container on the current message center server, checks whether the current queue is in the monitoring container, and if the current queue is not in the monitoring container, the message center adds the queue into the monitoring container and restarts monitoring;
step (4), message processing: after the message monitoring module is started, the message monitoring module monitors that the message is in the queue, and then the message processing module is actively called to process the message; the message processing module acquires a queue name, exchange and a routing Key according to the current queue information; analyzing and acquiring a user ID according to a queue naming rule; calling a WebSocket message sending method through a message pushing module, and pushing a message to a client;
step (5), message production:
the message production party produces messages through the message production module, and the produced messages comprise exchange names, RoutengKey and message contents; converting all types of routes into user IDs; querying all queues containing the user IDs in the RabbitMQ through the converted user IDs; binding the inquired queue with exchange, wherein a RouteingKey of the exchange is a corresponding user ID; when the queue is bound with the exchange, inquiring whether the exchange exists or not, if not, constructing the exchange, and then binding the queue with the exchange; after the binding of the queue and the exchange is finished, directly sending a message to the exchange;
step (6), message pushing:
(6.1) after the user logs in the application system through the browser, the browser actively sends a connection request to the message center through WebSocket connection; after receiving the request, the message pushing module authenticates the current connected user according to the received token, and if the current connection is not the system effective connection, the message pushing module automatically disconnects the Websocket connection; if the current connection is a system active connection, then (6.2);
(6.2) the message pushing module inquires whether unprocessed messages exist or not according to the user ID to the redis, if the unprocessed messages exist, the unprocessed messages are pushed to the client preferentially; acquiring a RabbitMQ monitoring container, and if the monitoring container is not started, starting the monitoring container; judging whether the queue containing the user ID is in monitoring, if not, adding the inquired queue into a monitoring container, and restarting monitoring;
(6.3) the message pushing module receives the message pushed by the message monitoring module, and judges whether the message is a message which needs to be received by the current user according to the user ID in the message and the user ID connected with the WebSocket; if so, directly calling a sendMessage method of the WebSocket to push the message to the client; if not, storing the message into a redis cache;
step (7), message exception handling:
(7.1) message unconsumed Process: when the message monitoring module monitors that a queue has messages and WebSocket connection is abnormal, storing the messages in the queue into a redis cache; when the WebSocket connection is normal, the message exception processing module matches KEY containing the user ID in the redis cache through the user ID to acquire a message, then pushes the message to the client, and simultaneously clears the corresponding message in the redis cache;
(7.2) when the Channel connection is abnormal or WebSocket consumption is blocked when the message monitoring module monitors the queue to process the message, the abnormal message is put into the queue again to sleep for 15 seconds, and then the step (3.2) is executed.
Preferably, in step (1), the subject of the message is used to correspond to the exchange switch of the RabbitMQ.
Preferably, in the step (2.2), the docker application cluster is used for deployment when the message queue is established;
the naming rule is specifically as follows: user ID + ": "+ apply server IP +" of the currently connected message center node: "+ docker container port number of the currently connected node.
Preferably, the message monitoring module monitors the message condition in the message queue, when a message to be consumed appears in the queue, the message is processed by the message processing module, then a message sending method sendMessage of WebSocket in the message pushing module is called by a message processing method onMessage in ChannelAwareMessageLister, and the message is sent to the message pushing module; after the message is sent, the message processing module calls a basicAck method of Channel in the RabbitMQ to confirm that the message is sent to the message pushing module, and simultaneously calls a queueUnbind method of Channel in the RabbitMQ to release the binding relationship between the queue and the theme, and system resources are released.
Preferably, in step (4), if the processed message is not a system message, the binding between the queue and the exchange needs to be released after the message processing is completed.
Preferably, RoutingKey is of three types: user ID, organization ID, role ID; and (4) replacing the user ID in the step (2) and the step (4) to the step (7) with an organization ID or a role ID.
Preferably, in step (6.1), the request information includes the token information of the user and the message topic to which the user requests subscription.
Preferably, in the step (6), after the user is connected to the message pushing module through the step (6.1), if the current connection is valid, the client sends a heartbeat data packet to the message pushing module every 15 seconds, so that the WebSocket is ensured to be continuously valid, and the message can be normally pushed to the client;
in the step (6), after the message pushing module detects that the WebSocket is disconnected, the message monitoring module is controlled to remove the currently monitored queue for monitoring.
Preferably, in step (7.1), the KEY when stored in the redis cache is assembled by: UNSEND _ system time value _ user ID.
The invention also provides a power grid operation risk early warning information transfer and storage system, which is stored with a computer program, and is characterized in that the computer program realizes the steps of the power grid operation risk early warning information transfer method when being executed by a processor.
In the invention, a message cluster is deployed by using a docker container: a container deployed by the docker application;
the message center uses RabbitMQ message middleware: RabbitMQ is open source message middleware that follows AMQP (advanced message queuing protocol); RabbitMQ uses several key knowledge points:
(1) exchange exchanger: corresponding to the message subject of the message center, exchange has three types:
center-to-side DIRECT: any message sent to Direct Exchange is forwarded to Queue specified in RouteKey;
in front of TOPIC: any message sent to the Topic Exchange is forwarded to all Queue concerned about the specified Topic in RouteKey;
in the central area FANOUT: any message sent to Fanout Exchange is forwarded to all Queue bound (Binding) with that Exchange.
(2) The device comprises a Queue message Queue and a RabbitMQ internal object, wherein the RabbitMQ internal object is used for storing messages, a message producer produces messages and finally delivers the messages to the Queue, the Queue needs to be bound with an exchange, and one exchange can bind a plurality of queues; the message consumption end acquires the message in the Queue by monitoring the Queue;
message pushing uses WebSocket: WebSocket is a protocol for full-duplex communication on a single TCP connection, and is used for data exchange between a client and a server;
message caching uses Redis: the high-performance cache database is used for storing abnormal message data;
the method mainly comprises the following modules:
the system comprises a message theme management module, a message subscription module, a message production module, a message monitoring module, a message processing module, a message pushing module and a message exception processing module.
The specific steps of message production and pushing are as follows:
1. the method comprises the steps that message theme management is realized in a message center, a risk early warning message theme is managed through a message theme management module, data must be acquired from the message theme management module in places related to the message theme, such as subscription and production of subsequent messages, and a user needs to register the message theme in the message theme management before using the message theme; the subject of the message is used to correspond to the exchange switch of the RabbitMQ;
2. and (3) generating a message queue:
(1) the message center configures default exchange (message subject), wherein the type of the default exchange is fanout (broadcast mode) type, and the name of the exchange is sys _ msg; all queues need to be bound to the exchange for the first construction; the role of the default exchange (message topic) is to broadcast system messages;
(2) message Queue establishment (Queue):
in the middle of the message queue naming rules: the message center uses docker application cluster deployment (also applicable to other types of cluster modes), and in order to enable a plurality of consumption terminals to consume messages of the same topic at the same time, the naming rule of the message queue is as follows: user ID + ": "+ apply server IP +" of the currently connected message center node: a docker container port number of "+ current connection node; for example: testUser01:192.168.11.1: 8009; (this is done so that when the message center processes a message and pushes it to an application via WebSocket, it defaults that all messages fetched from queues containing the same user ID need to be pushed to the ID user;)
After the user logs in the application system in the driving area:
(a) the message center assembles a message queue according to a message queue naming rule;
(b) the user inquires whether the queue exists from the RabbitMQ according to the queue name, and if the queue exists, the processing is not carried out; if the queue does not exist, a new message queue needs to be constructed, the message queue needs to be bound with the default exchange (message subject) configured in the step (1), and the routingKey of the queue is the user ID of the user;
3. message monitoring:
(1) the method comprises the following steps: after the message center is started, the system automatically creates a SimpleMessageListenerContainer message monitoring container.
(2) After step 2 (after the message subscription is completed), the message center reads the information of the SimpleMessageListenerContainer monitoring container on the current message center server, checks whether the current queue is in the monitoring container, and if the current queue is not in the monitoring container, the message center adds the queue into the monitoring container and restarts the monitoring;
4. message processing:
after the message monitor is started, the message monitor monitors that a message exists in the queue and can actively call a message processing service to process the message;
acquiring a queue name, exchange and a routing Key according to current queue information by an edge message processing class;
analyzing and acquiring a user ID according to a queue naming rule; pushing the message to a client by calling a WebSocket message sending method (when the WebSocket sends the message, whether a user currently connected with the WebSocket is a user receiving the message or not is judged according to a user ID);
if the message is not a system message (sys _ msg default exchange), the binding of the queue and the exchange needs to be released after the message processing is completed so as not to occupy channel resources of the RabbitMQ all the time;
5. message production:
the message center provides a message production interface to produce a message to a message producer, and the message is sent to exchange.
(1) The information production interface information comprises (exchange name (message subject name), routing Key (routing information) and message content, wherein the routing information comprises three types, namely user ID, organization ID and role ID); this example uses the user ID type.
(2) The message production interface firstly converts all types of routes into user IDs;
(3) the message production interface queries all queues containing the user ID in the RabbitMQ through the converted user ID in the step (2);
(4) the message production interface binds the queue queried in the step (3) with exchange, wherein the routing Key (routing information) of the exchange is the user ID in the step (2); when the queue is bound with the exchange, whether the exchange exists is inquired, the exchange does not need to be constructed first, and then the queue is bound with the exchange;
(5) after the binding of the queue and the exchange is finished, directly sending a message to the exchange;
6. message pushing:
(1) after a user logs in a system through a browser, the browser actively sends a connection request to a message center through WebSocket connection, wherein the request information comprises user token information, a message theme (the theme is limited to the message theme managed in the step 1) requested to be subscribed by the user and the like; after receiving the request, the message center authenticates the current connection user according to the received token (judges whether the current connection is an effective connection or not, and prevents a malicious request), and if the current connection is not the effective connection of the system, the message center automatically disconnects the WebSocket connection;
(2) if the current connection is a system active connection:
if the unprocessed message exists in the redis according to the user ID, the unprocessed message is preferentially pushed to the client side if the unprocessed message exists;
acquiring a RabbitMQ monitoring container in the middle, and if the monitoring container is not started, starting the monitoring container; judging whether the queue containing the user ID is in monitoring, if not, adding the inquired queue into a monitoring container, and restarting monitoring;
(3) message push
The message pushing module receives a message pushed by the message monitoring module, and judges whether the message is a message which needs to be received by a current user according to the user ID in the message and the user ID connected with the Websocket; if the message is directly pushed, if the message is not stored in a redis cache.
(4) Websocket connection assurance
In order to ensure the effectiveness of the application and the Websocket of the message center, the application sends a Websocket connection message to the message center every 15 seconds to perform connection heartbeat detection, so that the Websocket is ensured to be always in effective connection.
(5) After detecting that the WebSocket is disconnected, the message center needs to remove monitoring from the currently monitored queue;
7. message exception handling
(1) Message unconsumed processing: when the message monitoring module monitors that a queue has messages, but the connection between the application and the message center WebSocket is abnormal, the system stores the messages in the queue into redis, wherein keys during the storage of the redis are assembled in the following mode: UNSEND _ system time value _ user ID; after the application is normally connected with the message center WebSocket, the message center acquires a message by matching a KEY containing a user ID from the user ID to the redis, then pushes the message to the client, and simultaneously clears the corresponding message in the redis;
(2) the message monitoring module monitors the conditions that Channel connection is abnormal or WebSocket consumption is blocked when the queue performs message processing, and the message center puts abnormal messages into the queue again until the dormancy time is up and then calls the message monitoring and processing module again to perform message processing;
the foregoing shows and describes the general principles, essential features, and advantages of the invention. It will be understood by those skilled in the art that the present invention is not limited to the embodiments described above, which are described in the specification and illustrated only to illustrate the principle of the present invention, but that various changes and modifications may be made therein without departing from the spirit and scope of the present invention, which fall within the scope of the invention as claimed. The scope of the invention is defined by the appended claims and equivalents thereof.
Claims (10)
1. A power grid operation risk early warning information transfer method is characterized by comprising the following steps:
the message center comprises a message theme management module, a message subscription module, a message monitoring module, a message processing module, a message production module, a message pushing module and a message exception processing module;
the power grid operation risk early warning information transfer method comprises the following steps:
step (1), message theme management: managing risk early warning message themes through a message theme management module, wherein all places related to the message themes need to acquire data from the message theme management module, and a user needs to register the message themes in the message theme management module before using the message themes;
step (2), subscribing the message:
(2.1) message topic configuration: configuring default exchange, namely a message topic, through a message subscription module; the type of the default exchange is a fanout type, namely a broadcast mode type; the name of exchange is sys _ msg; all queues need to be bound to the exchange for the first construction; the role of the default exchange is to broadcast system messages;
(2.2) message queue establishment: using cluster mode deployment, naming according to naming rules of the message queue; after a user logs in an application system, a message subscription module assembles a message queue according to a message queue naming rule; inquiring whether the queue exists from the RabbitMQ according to the queue name, and if so, not processing; if the queue does not exist, constructing a new message queue, and binding the new message queue with the default exchange configured in the step (2.1), wherein the RoutengKey of the queue is the user ID of the user;
step (3), message monitoring:
after the message center is started, a SimpleMessageListenerContainer message monitoring container can be automatically created; after the message subscription is finished, the message monitoring module reads the information of a SimpleMessageListenerContainer monitoring container on the current message center server, checks whether the current queue is in the monitoring container, and if the current queue is not in the monitoring container, the message center adds the queue into the monitoring container and restarts monitoring;
step (4), message processing: after the message monitoring module is started, the message monitoring module monitors that the message is in the queue, and then the message processing module is actively called to process the message; the message processing module acquires a queue name, exchange and a routing Key according to the current queue information; analyzing and acquiring a user ID according to a queue naming rule; calling a WebSocket message sending method through a message pushing module, and pushing a message to a client;
step (5), message production:
the message production party produces messages through the message production module, and the produced messages comprise exchange names, RoutengKey and message contents; converting all types of routes into user IDs; querying all queues containing the user IDs in the RabbitMQ through the converted user IDs; binding the inquired queue with exchange, wherein a RouteingKey of the exchange is a corresponding user ID; when the queue is bound with the exchange, inquiring whether the exchange exists or not, if not, constructing the exchange, and then binding the queue with the exchange; after the binding of the queue and the exchange is finished, directly sending a message to the exchange;
step (6), message pushing:
(6.1) after the user logs in the application system through the browser, the browser actively sends a connection request to the message center through WebSocket connection; after receiving the request, the message pushing module authenticates the current connected user according to the received token, and if the current connection is not the system effective connection, the message pushing module automatically disconnects the Websocket connection; if the current connection is a system active connection, then (6.2);
(6.2) the message pushing module inquires whether unprocessed messages exist or not according to the user ID to the redis, if the unprocessed messages exist, the unprocessed messages are pushed to the client preferentially; acquiring a RabbitMQ monitoring container, and if the monitoring container is not started, starting the monitoring container; judging whether the queue containing the user ID is in monitoring, if not, adding the inquired queue into a monitoring container, and restarting monitoring;
(6.3) the message pushing module receives the message pushed by the message monitoring module, and judges whether the message is a message which needs to be received by the current user according to the user ID in the message and the user ID connected with the WebSocket; if so, directly calling a sendMessage method of the WebSocket to push the message to the client; if not, storing the message into a redis cache;
step (7), message exception handling:
(7.1) message unconsumed Process: when the message monitoring module monitors that a queue has messages and WebSocket connection is abnormal, storing the messages in the queue into a redis cache; when the WebSocket connection is normal, the message exception processing module matches KEY containing the user ID in the redis cache through the user ID to acquire a message, then pushes the message to the client, and simultaneously clears the corresponding message in the redis cache;
(7.2) when the Channel connection is abnormal or WebSocket consumption is blocked when the message monitoring module monitors the queue to process the message, the abnormal message is put into the queue again to sleep for 15 seconds, and then the step (3.2) is executed.
2. The power grid operation risk early warning information transfer method according to claim 1, characterized in that: in step (1), the subject of the message is used to correspond to the exchange switch of the RabbitMQ.
3. The power grid operation risk early warning information transfer method according to claim 1, characterized in that: in the step (2.2), a docker application cluster is used for deployment when a message queue is established;
the naming rule is specifically as follows: user ID + ": "+ apply server IP +" of the currently connected message center node: "+ docker container port number of the currently connected node.
4. The power grid operation risk early warning information transfer method according to claim 1, characterized in that:
the message monitoring module monitors the message condition in the message queue, when a message to be consumed appears in the queue, the message is processed by the message processing module, then a message sending method sendMessage of WebSocket in the message pushing module is called by a message processing method onMessage in ChannelAwareMessalistener, and the message is sent to the message pushing module; after the message is sent, the message processing module calls a basicAck method of Channel in the RabbitMQ to confirm that the message is sent to the message pushing module, and simultaneously calls a queueUnbind method of Channel in the RabbitMQ to release the binding relationship between the queue and the theme, and system resources are released.
5. The power grid operation risk early warning information transfer method according to claim 1, characterized in that: in the step (4), if the processed message is not a system message, the binding between the queue and the exchange needs to be released after the message processing is completed.
6. The power grid operation risk early warning information transfer method according to claim 1, characterized in that: in step (5), RoutingKey has three types: user ID, organization ID, role ID; and (4) replacing the user ID in the step (2) and the step (4) to the step (7) with an organization ID or a role ID.
7. The power grid operation risk early warning information transfer method according to claim 1, characterized in that: in the step (6.1), the request information includes the token information of the user and the message topic which the user requests to subscribe.
8. The power grid operation risk early warning information transfer method according to claim 1, characterized in that: in the step (6), after the user is connected to the message pushing module through the step (6.1), if the current connection is effective connection, the client sends a heartbeat data packet to the message pushing module every 15 seconds, so that the WebSocket is ensured to be continuously effective, and the message can be normally pushed to the client;
in the step (6), after the message pushing module detects that the WebSocket is disconnected, the message monitoring module is controlled to remove the currently monitored queue for monitoring.
9. The power grid operation risk early warning information transfer method according to claim 1, characterized in that: in the step (7.1), the KEY stored in the redis cache is assembled in the following way: UNSEND _ system time value _ user ID.
10. A power grid operation risk early warning information circulation storage system, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the power grid operation risk early warning information circulation method according to any one of claims 1 to 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110709127.0A CN113626210B (en) | 2021-06-25 | 2021-06-25 | Power grid operation risk early warning information transfer method and storage system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110709127.0A CN113626210B (en) | 2021-06-25 | 2021-06-25 | Power grid operation risk early warning information transfer method and storage system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113626210A true CN113626210A (en) | 2021-11-09 |
| CN113626210B CN113626210B (en) | 2022-11-15 |
Family
ID=78378391
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110709127.0A Active CN113626210B (en) | 2021-06-25 | 2021-06-25 | Power grid operation risk early warning information transfer method and storage system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113626210B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111770029A (en) * | 2020-06-17 | 2020-10-13 | 南京泰治自动化技术有限公司 | Dynamic queue forwarding method, system and storage medium based on RabbitMQ and ActiveMQ |
| CN112702190A (en) * | 2020-12-11 | 2021-04-23 | 广东电力通信科技有限公司 | Regional alarm message pushing method and system based on message queue |
-
2021
- 2021-06-25 CN CN202110709127.0A patent/CN113626210B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111770029A (en) * | 2020-06-17 | 2020-10-13 | 南京泰治自动化技术有限公司 | Dynamic queue forwarding method, system and storage medium based on RabbitMQ and ActiveMQ |
| CN112702190A (en) * | 2020-12-11 | 2021-04-23 | 广东电力通信科技有限公司 | Regional alarm message pushing method and system based on message queue |
Non-Patent Citations (2)
| Title |
|---|
| 赵志宇等: "RabbitMQ在输变电监测中的应用研究", 《中国战略新兴产业》 * |
| 雷宝龙等: "基于发布订阅模式的消息转发服务设计", 《江苏科技信息》 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113626210B (en) | 2022-11-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107465767B (en) | Data synchronization method and system | |
| EP2485443A1 (en) | System and method for managing multiple queues of non-persistent messages in a networked environment | |
| EP1320229A2 (en) | Method and device for messaging | |
| US7624147B2 (en) | Efficient notification of new electronic mail arrival | |
| US20100094985A1 (en) | Http push to simulate server-initiated sessions | |
| WO2005121991A2 (en) | Personal messaging proxy | |
| CN106210049B (en) | Cluster communication method and system based on message queue | |
| CN102239731A (en) | Method for extending battery life in a wireless device | |
| US10637960B2 (en) | Method for bridging publish/subscribe brokers for guaranteed low-latency delivery | |
| CA2707536A1 (en) | Processing of network content and services for mobile or fixed devices | |
| US10027563B2 (en) | Using status inquiry and status response messages to exchange management information | |
| CN112187903B (en) | Message pushing method and device and message service system | |
| US10834033B2 (en) | Method and system for transferring messages between messaging systems | |
| CN108182121A (en) | In a kind of Android control large-size screen monitors system module between communication means and system | |
| CN116319732A (en) | Message queue centralized configuration management system and method based on RabbitMQ | |
| US7543030B2 (en) | Peer-to-peer communication for instant messaging between different instant message application types | |
| US10063648B2 (en) | Relaying mobile communications | |
| CN113507498A (en) | Government affair hall device data exchange method and model | |
| CN113626210B (en) | Power grid operation risk early warning information transfer method and storage system | |
| US8924486B2 (en) | Method and system for aggregating communications | |
| CN113965628A (en) | Message scheduling method, server and storage medium | |
| CN116800787A (en) | Vehicle-mounted communication method and system based on Ethernet communication protocol | |
| JP2009515474A (en) | Independent message store and message transport agent | |
| WO2017197944A1 (en) | Notification message prompting method among terminals, and terminal | |
| EP1649393B1 (en) | Providing modular telephony service |
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 |