Communication method, system and device of APP-MQ-PMTS

Abstract

The invention relates to the technical field of financial services, and discloses an APP-MQ-PMTS communication method, system and device, and the key points of the technical scheme are that the method comprises the following steps: establishing a cross communication connection between an APP and an MQ, and establishing a cross communication connection between the MQ and a PMTS to form communication channels, each communication channel comprising a transmitting line and a receiving line; setting and running a detection task, a sending guard task and a receiving guard task for the communication channel, wherein the detection task is used for regularly detecting the state of the communication channel; the sending guarding task is used for regularly checking the state of the sending line and closing the sending line and restarting the sending line when the sending line is unavailable; the receiving guard task is used for regularly checking the state of the receiving line and closing and restarting the receiving line when the receiving line is unavailable; and under the condition that the detection task, the sending guarding task and the receiving guarding task are continuously operated in the communication channel, executing a service sending process and a service receiving process.

Description

Technical Field

[0001] The present invention relates to the technical field of financial services, and more specifically, to an APP-MQ-PMTS communication method, system and device. Background Art

[0002] Compared with the first-generation payment system, the second-generation China Modern Payment System (CNAPS2) has upgraded its communication mode. The communication modules originally built into each payment system have been extracted separately to form an independent communication platform - PMTS (Payment Message Transmission Platform). This platform is dedicated to message transmission and message processing between systems. Both the participants' own internal systems and the payment application systems deployed in the NPC (National Processing Center) & CCPC (City Clearing Processing Center) can transmit messages through PMTS.

[0003] The participant access software (PMTS-MBFE) is responsible for receiving messages from the participant's internal system and forwarding them to PMTS-CCPC, and forwarding messages from PMTS-CCPC to the participant's internal business system. Application docking mainly refers to the docking between the internal system and PMTS-MBFE. The current version provides two docking methods. One of the modes is the QQ mode, that is, the internal system is docked with the PMTS-MBFE middleware through the middleware.

[0004] Most organizations deploy QQ in the mode of APP→MQ→PMTS, deploy multiple servers at each node, and establish a "high availability" mode with multiple parallel lines. This solution has certain defects: there is a lack of effective detection mechanism between the lines of nodes, and the message congestion can only be detected by monitoring the depth of the Q node message queue. Message congestion does not necessarily mean that the line is faulty, but may be a temporary influx of large traffic. At this time, manual intervention is required for query analysis and processing, which has low timeliness. Summary of the invention

[0005] The purpose of the present invention is to provide an APP-MQ-PMTS communication method, system and device, which can achieve true high availability, deploy multiple servers at each node, and establish parallel and cross lines between APP, MQ and PMTS, and use a timing detection mechanism to regularly check the health status of each line, so as to achieve the purpose of timely discovery of faulty nodes, automatic shielding of faulty lines, timing detection of all lines, and automatic restoration of lines after the faulty nodes are restored.

[0006] The above technical objectives of the present invention are achieved through the following technical solutions: A communication method of APP-MQ-PMTS, comprising the following steps:

[0007] Establish a cross communication connection between APP and MQ, and establish a cross communication connection between MQ and PMTS, so as to form several communication channels between APP-MQ-PMTS, each of which includes a sending line and a receiving line;

[0008] Set and run a detection task, a sending guard task and a receiving guard task for the communication channel. The detection task is used to regularly detect the communication channel status; the sending guard task is used to regularly check the sending line status, and when the sending line is unavailable, close the sending line and restart it; the receiving guard task is used to regularly check the receiving line status, and when the receiving line is unavailable, close the receiving line and restart it;

[0009] When the detection task, the sending guard task and the receiving guard task are continuously running in the communication channel, the business sending process and the business receiving process are executed.

[0010] As a preferred technical solution of the present invention, each MQ includes a local queue and a remote queue. The local queue is used for the APP to receive messages from the PMTS, and the remote queue is used for the APP to send messages to the PMTS.

[0011] As a preferred technical solution of the present invention, each MQ creates a local queue for receiving detection and a remote queue for sending detection. The remote queue for sending detection is used for APP to send detection messages to PMTS, and the local queue for receiving detection is used to store APP's detection results of PMTS.

[0012] As a preferred technical solution of the present invention, when an APP obtains that the channel status is available, it is recorded through the database and shared among all APPs. When a message needs to be sent, one of all available communication channels is selected to send the message according to the record in the database. When a message needs to be received, all available lines are monitored according to the record in the database.

[0013] As a preferred technical solution of the present invention, the detection task is: after sending a detection message on each communication channel and receiving a reply to the detection message, judging and recording the state of the communication channel according to the reply to the detection message.

[0014] As a preferred technical solution of the present invention, in the detection task, the APP periodically sends a detection message through the detection queue corresponding to each communication channel, and attaches the channel name. After receiving the reply to the detection message, the current communication channel status is judged to be available through the channel name and source initiating node name in the detection message reply.

[0015] As a preferred technical solution of the present invention, the sending process: according to the available status of all communication lines, the currently available communication lines are cyclically used to send business messages, and according to the sending status of the business messages, the available status of the current communication lines is updated;

[0016] In the receiving process, a thread task for receiving business messages is set for each communication line. The APP continuously monitors business messages on each available communication line, and receives and processes business messages when they exist.

[0017] As a preferred technical solution of the present invention, the sending guard task is: regularly obtaining the timestamp of the last time the communication line received the detection message, judging whether it exceeds the preset first time, if not, executing the detection task, if exceeded, recording the current communication line as unavailable, triggering an alarm operation, and closing the MQ connection of the current communication line to the preset second time, re-creating the MQ connection of the current communication line, and executing the detection task.

[0018] The receiving daemon task is to receive and read the detection message on the communication line. If the reading is abnormal, the detection receiving daemon task will be re-executed after the preset third time. If the read detection message is a detection request message, the corresponding sending line will be selected for reply. If the read detection message is a response message of the detection message, the last detection message reception timestamp of the corresponding sending line will be recorded according to the source application node name and channel name in the message, and written into the database.

[0019] As a preferred technical solution of the present invention, when the status of the communication channel is unavailable, an alarm operation is triggered.

[0020] An APP-MQ-PMTS communication system, comprising:

[0021] The channel creation module is used to establish a cross communication connection between APP and MQ, and between MQ and PMTS, forming several communication channels between APP-MQ-PMTS, each of which includes a sending line and a receiving line;

[0022] The detection setting module is used to set and run the detection task, the sending guard task and the receiving guard task for the communication channel. The detection task is used to regularly detect the communication channel status; the sending guard task is used to regularly check the sending line status, and when the sending line is unavailable, close the sending line and restart it; the receiving guard task is used to regularly check the receiving line status, and when the receiving line is unavailable, close the receiving line and restart it;

[0023] The business execution module is used to execute the business sending process and the business receiving process when the detection task, the sending guardian task and the receiving guardian task are continuously running in the communication channel.

[0024] An APP-MQ-PMTS communication device includes: a processor and a memory, wherein the memory stores a computer program executable by the processor, and the processor implements the above method when executing the computer program.

[0025] In summary, the present invention has the following beneficial effects: establishing parallel and cross channel lines between nodes, making full use of server resources. Real-time detection of channel line health status, automatic isolation of faulty lines, and reduction of transaction failure rate. Automatic recovery of faulty lines, reduction of manual intervention, and improvement of time efficiency.

[0026] It can reduce the complexity of daily system maintenance and reduce the transaction failure rate caused by system downtime maintenance or restart maintenance.

[0027] The solution of the present invention can achieve true high availability. Multiple servers are deployed at each node, and parallel and cross lines are established between APP, MQ and PMTS. A timing detection mechanism is used to regularly check the health status of each line, so that faulty nodes can be discovered in time, faulty lines can be automatically shielded, all lines can be detected regularly, and lines can automatically resume connection after faulty nodes are restored. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 This is a schematic diagram of the APP-MQ-PMTS connection of the present invention;

[0029] Figure 2 It is a transmission line diagram between APP-MQ-PMTS of the present invention;

[0030] Figure 3 It is a receiving line diagram between APP-MQ-PMTS of the present invention;

[0031] Figure 4 It is a schematic diagram of the service sending process of the present invention;

[0032] Figure 5 It is a schematic diagram of the service receiving process of the present invention;

[0033] Figure 6 It is a schematic diagram of sending an application node fault message of the present invention;

[0034] Figure 7 It is a schematic diagram of receiving an application node fault message of the present invention;

[0035] Figure 8 It is a schematic diagram of sending a local MQ service failure of the present invention;

[0036] Fig. 9 It is a schematic diagram of receiving a local MQ service failure of the present invention. DETAILED DESCRIPTION

[0037] The present invention is further described in detail below in conjunction with the accompanying drawings.

[0038] The present invention provides an APP-MQ-PMTS communication method, comprising the following steps:

[0039] like Figure 1 As shown, a cross communication connection is established between APP and MQ, and a cross communication connection is established between MQ and PMTS, forming several communication channels between APP-MQ-PMTS, each communication channel includes a sending line and a receiving line; the sending line and the receiving line, such as Figure 2 and 3 shown.

[0040] Specifically, each MQ contains a local queue and a remote queue. The local queue is used for the APP to receive messages from the PMTS, and the remote queue is used for the APP to send messages to the PMTS.

[0041] Specifically, each MQ creates a local queue for receiving detections and a remote queue for sending detections. The remote queue for sending detections is used for the APP to send detection messages to the PMTS, and the local queue for receiving detections is used to store the APP's detection results for the PMTS.

[0042] Set up and run detection tasks, sending daemon tasks and receiving daemon tasks for the communication channel. The detection task is used to regularly detect the status of the communication channel; the sending daemon task is used to regularly check the status of the sending line, and when the sending line is unavailable, close the sending line and restart it; the receiving daemon task is used to regularly check the status of the receiving line, and when the receiving line is unavailable, close the receiving line and restart it;

[0043] The detection task is: send a detection message on each communication channel, and after receiving the reply of the detection message, judge the status of the communication channel according to the reply of the detection message and record it. In the detection task, the APP sends a detection message through the detection queue corresponding to each communication channel at a fixed time, and attaches the channel name, and after receiving the reply of the detection message, judge the current communication channel status as available according to the channel name and source initiating node name in the reply of the detection message.

[0044] The sending daemon task is: regularly obtain the timestamp of the last time the communication line received the detection message, and determine whether it exceeds the preset first time. If not, execute the detection task. If it exceeds, record the current communication line as unavailable, trigger an alarm operation, and close the MQ connection of the current communication line until the preset second time, then re-create the MQ connection of the current communication line and execute the detection task.

[0045] Specifically, for each sending line, the daemon task of the sending thread is started. The thread daemon task of the sending line will periodically check the timestamp of the last received detection message of the corresponding sending line to determine whether it has timed out. If it has timed out, the sending line will be marked as unavailable and a notification will be triggered to the relevant personnel. If the sending line is unavailable, the MQ connection of the sending line will be closed, and after waiting for a period of time, the MQ connection of the sending line will be re-created, and the detection sending process will be restarted; if the sending line is available, the detection message will be sent regularly, and the application node name and the corresponding channel name will be attached; if an exception is thrown when sending the detection message, the line will be changed to unavailable, and the MQ connection of the sending line will be closed. After waiting for a period of time, the MQ connection of the sending line will be re-created, and the detection sending process will be restarted.

[0046] The receiving daemon task is to receive and read the detection message on the communication line. If the reading is abnormal, the detection receiving daemon task will be re-executed after the preset third time. If the read detection message is a detection request message, the corresponding sending line will be selected for reply. If the read detection message is a response message of the detection message, the last detection message reception timestamp of the corresponding sending line will be recorded according to the source application node name and channel name in the message, and written into the database.

[0047] For each local queue that receives incoming messages, start the daemon thread task for receiving incoming messages. The daemon task for receiving incoming messages establishes an MQ connection and reads the probe message. If an exception occurs during reading, wait for a period of time and restart the probe receiving process. If the probe message read is a probe request message sent by the other party, select the corresponding sending channel and reply; if the probe message read is a response message to the probe message sent by the other party to our party, then according to the original application node name and channel name in the message, record the last probe message reception timestamp of the corresponding sending line, and write the information into the database, waiting for the next time to send the probe message to determine whether the line is set as unavailable due to a timeout response.

[0048] When an APP obtains that the channel status is available, it records it in the database and shares it among all APPs. When a message needs to be sent, one of all available communication channels is selected to send the message according to the records in the database. When a message needs to be received, all available lines are monitored according to the records in the database.

[0049] When the status of the communication channel is unavailable, an alarm operation is triggered.

[0050] When the detection task, the sending guard task and the receiving guard task are continuously running in the communication channel, the business sending process and the business receiving process are executed.

[0051] like Figure 4 As shown in the figure, the business sending process: according to the available status of all communication lines, the currently available communication lines are used cyclically to send business messages, and the available status of the current communication line is updated according to the sending status of the business messages; specifically, in the business sending process, when sending MQ messages, the line subscript X of the last message sent is obtained from the database cache, and then the next sending line is obtained through X+1. The obtained line is judged according to the available status of the sending line. If it is available, it is sent according to the current line. If it is not available, the next available sending line is selected cyclically, and it is sent according to the remote queue corresponding to the sending line and whether the transaction belongs to real-time or batch business. According to different categories of remote queues. If all queues are unavailable, the relevant personnel are notified, and an exception is thrown, and the sending of this transaction fails. If the sending line is obtained, but an exception is thrown when sending, the sending queue is immediately marked as unavailable, and the relevant personnel are notified.

[0052] Furthermore, as shown in the docking diagram of QQ mode, taking App1 as an example, the sending queue has four lines 1, 2, 3, and 4 that can be sent, then set the subscripts 0, 1, 2, and 3 respectively, and loop through the sending lines. For example, the first subscript 0 is sent according to line 1, and the next transaction is sent according to line 2 with subscript 1. If the current sending line status is unavailable, the next subscript sending line is taken in a loop for sending. If all line statuses are unavailable, the relevant personnel are notified.

[0053] like Figure 5As shown, in the business receiving process, a thread task for receiving business messages is set for each communication line respectively. The APP continuously listens for business messages on each available communication line, and receives and processes business messages when they exist. Specifically, a thread task for receiving incoming messages is started for each receiving line (pointing to the local queue). The receiving thread creates an MQ connection for receiving incoming messages, and continuously reads messages in a loop, and puts them into the background thread pool for processing. The thread pool uses a synchronous queue, and the read messages immediately enter the processing flow. After a maximum of 1 message is read, the processing flow is not entered. If an exception is thrown when reading the message, the MQ connection for receiving the incoming message is closed. After waiting for a period of time, the MQ connection for receiving the incoming message is recreated, and the above process is repeated.

[0054] Corresponding to the above method, the present invention also provides an APP-MQ-PMTS communication system, including:

[0055] The channel creation module is used to establish a cross communication connection between APP and MQ, and between MQ and PMTS, forming several communication channels between APP-MQ-PMTS, each of which includes a sending line and a receiving line;

[0056] The detection setting module is used to set and run detection tasks, sending daemon tasks and receiving daemon tasks for the communication channel. The detection task is used to regularly detect the status of the communication channel; the sending daemon task is used to regularly check the status of the sending line, and when the sending line is unavailable, close the sending line and restart it; the receiving daemon task is used to regularly check the status of the receiving line, and when the receiving line is unavailable, close the receiving line and restart it;

[0057] The business execution module is used to execute the business sending process and the business receiving process when the detection task, the sending guardian task and the receiving guardian task are continuously running in the communication channel.

[0058] An APP-MQ-PMTS communication device includes: a processor and a memory, wherein the memory stores a computer program executable by the processor, and the processor implements the above method when executing the computer program.

[0059] The technical advantages of the method, system and device of the present invention are: establishing two types of channel lines, parallel and cross, between each node, making full use of server resources. It can detect the health status of the channel line in real time, automatically isolate the faulty line, and reduce the transaction failure rate. It can realize automatic recovery of the faulty line, reduce manual intervention, and improve timeliness.

[0060] It can reduce the complexity of daily system maintenance and reduce the transaction failure rate caused by system downtime maintenance or restart maintenance.

[0061] The solution of the present invention can achieve true high availability. Multiple servers are deployed at each node, and parallel and cross lines are established between APP, MQ and PMTS. A timing detection mechanism is used to regularly check the health status of each line, so that faulty nodes can be discovered in time, faulty lines can be automatically shielded, all lines can be detected regularly, and lines can automatically resume connection after faulty nodes are restored.

[0062] As an embodiment of the present invention, taking two APPs, two MQs, and two PMTSs corresponding to QQ mode as an example, cross-connection communication is performed between the application and the MQ, and cross-connection communication is performed between the MQ and the PMTS, forming 8 communication channels.

[0063] Each APP creates 4 sending lines and 1 detection line corresponding to the MQ queue. Each APP application has 4 sending lines available, and 2 APP applications have a total of 8 sending lines, which are:

[0064]

[0065] The sending lines and their corresponding relationships are as follows:

[0066]

[0067] The following is an embodiment of the present invention when an application node fails:

[0068] Fault description: App1 service fails, including service stop, process freeze, etc. Application node failure affects the sending and receiving lines, such as Figure 6 and 7 shown.

[0069] Detection method: For reciprocal business, because App1 is based on Spring Cloud microservice design and its registration status in Consul has been offline, the reciprocal business transactions will not be distributed to the App1 service by the gateway service.

[0070] For incoming account services, App1 will no longer actively consume MQ messages. The receiving queue service of App2 will obtain the messages of BBMSA_1 and BBMSA_2 local queues of MQ1 service to ensure that the incoming account services are not affected.

[0071] Fault recovery: If the App1 service is stopped, start the service. During the service startup process, ensure that the service starts normally and successfully, and then obtain the MQ message for processing. This can avoid the situation where the service has not been fully started after obtaining the message, affecting transaction processing and causing transaction abnormalities.

[0072] If the App1 service is idle or down, the heartbeat monitoring mechanism of Consul will be used to monitor the status of the application node. If the service is detected to be abnormal, Consul will be notified to synchronize the node status to unavailable. Then the consumer will synchronize the application node status regularly and stop distributing transactions to the service to avoid system abnormalities in remittance-related businesses.

[0073] The following is an embodiment of the present invention when the local MQ service fails:

[0074] Fault description: 1. The MQ1 service fails. For the outbound lines, the connection status of lines 1, 2, 5, and 6 is abnormal. The line status of lines 1, 2, 5, and 6 is set to unavailable.

[0075] 2. For incoming services, there is a detection mechanism between PMTS1, PMTS2 and MQ1, MQ2. As shown in the following figure, through the detection mechanism, PMTS1 will regard MQ1 as an unavailable service and will not send messages to the BBMSA_1 and BBMSA_2 local queues of the MQ1 service:

[0076] MQ node failure affects both the sending and receiving lines, such as Figure 8 and 9 shown.

[0077] Detection method: By sending detection messages to line channels 1, 2, 5, and 6, if any sending abnormality occurs, the channel will be closed in time; by sending business messages to line channels 1, 2, 5, and 6, if any sending abnormality occurs, the channel will be closed in time; if more than 2 lines are closed, a notification will be triggered to the relevant personnel, indicating that there is a problem with the MQ service node or PMTS node failure.

[0078] Fault recovery: 1. Restart the MQ queue manager and confirm that the queue manager and queues have been restored. Through the detection mechanism, the status of each channel is restored to ensure smooth sending and receiving of outgoing and incoming business.

[0079] The above is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.

Claims

1. An APP-MQ-PMTS communication method, characterized in that: The steps include: Establish a cross communication connection between APP and MQ, and establish a cross communication connection between MQ and PMTS, so as to form several communication channels between APP-MQ-PMTS, each of which includes a sending line and a receiving line; Set and run a detection task, a sending daemon task and a receiving daemon task for the communication channel. The detection task is used to regularly detect the status of the communication channel; the sending daemon task is used to regularly check the status of the sending line, and when the sending line is unavailable, close the sending line and restart it; The receiving daemon task is used to periodically check the status of the receiving line, and when the receiving line is unavailable, shut down the receiving line and restart it; When the detection task, the sending guard task and the receiving guard task are continuously running in the communication channel, the business sending process and the business receiving process are executed.

2. The APP-MQ-PMTS communication method according to claim 1, characterized in that: Each MQ creates a local queue for receiving detections and a remote queue for sending detections. The remote queue for sending detections is used by the APP to send detection messages to the PMTS, and the local queue for receiving detections is used to store the APP's detection results for the PMTS.

3. The APP-MQ-PMTS communication method according to claim 2, characterized in that: When an APP obtains that the channel status is available, it records it in the database and shares it among all APPs. When a message needs to be sent, one of all available communication channels is selected to send the message according to the records in the database. When a message needs to be received, all available lines are monitored according to the records in the database.

4. The APP-MQ-PMTS communication method according to claim 3, characterized in that: The detection task is: send a detection message on each communication channel, and after receiving the reply of the detection message, determine the status of the communication channel and record it according to the reply of the detection message.

5. The APP-MQ-PMTS communication method according to claim 4, characterized in that: In the detection task, the APP periodically sends a detection message through the detection queue corresponding to each communication channel, and attaches the channel name. After receiving the reply to the detection message, it determines whether the current communication channel status is available based on the channel name and source initiator node name in the detection message reply.

6. The communication method of APP-MQ-PMTS according to claim 5, characterized in that: sending Process: According to the available status of all communication lines, the currently available communication lines are used cyclically to send business messages, and the available status of the current communication lines is updated according to the sending status of the business messages; In the receiving process, a thread task for receiving business messages is set for each communication line. The APP continuously monitors business messages on each available communication line, and receives and processes business messages when they exist.

7. The APP-MQ-PMTS communication method according to claim 6, characterized in that: The sending daemon task is: regularly obtain the timestamp of the last time the communication line received the detection message, and determine whether it exceeds the preset first time. If not, execute the detection task. If it exceeds, record the current communication line as unavailable, trigger an alarm operation, and close the MQ connection of the current communication line until the preset second time, then re-create the MQ connection of the current communication line and execute the detection task. The receiving guard task is: receiving and reading the detection message on the communication line. If the reading is abnormal, the detection receiving guard task is re-executed after a preset third time; If the probe message read is a probe request message, the corresponding sending line is selected to reply; If the probe message read is a response message of the probe message, the last probe message reception timestamp of the corresponding sending line is recorded according to the source application node name and channel name in the message, and written into the database.

8. The APP-MQ-PMTS communication method according to claim 7, characterized in that: When the status of the communication channel is unavailable, an alarm operation is triggered.

9. An APP-MQ-PMTS communication system, characterized by: include: The channel creation module is used to establish a cross communication connection between APP and MQ, and between MQ and PMTS, forming several communication channels between APP-MQ-PMTS, each of which includes a sending line and a receiving line; The detection setting module is used to set and run the detection task, the sending daemon task and the receiving daemon task for the communication channel. The detection task is used to regularly detect the status of the communication channel; the sending daemon task is used to regularly check the status of the sending line, and when the sending line is unavailable, close the sending line and restart it; The receiving daemon task is used to periodically check the status of the receiving line, and when the receiving line is unavailable, shut down the receiving line and restart it; The business execution module is used to execute the business sending process and the business receiving process when the detection task, the sending guardian task and the receiving guardian task are continuously running in the communication channel.

10. An APP-MQ-PMTS communication device, characterized in that: include: A processor and a memory, wherein the memory stores a computer program executable by the processor, and when the processor executes the computer program, the method according to any one of claims 1 to 8 is implemented.

Images