Message delivery method, device and storage medium

Abstract

The application discloses a message delivery method, device and storage medium, and relates to the technical field of information transmission. The message delivery method comprises the following steps: acquiring the message type of a message, wherein the message type comprises real-time messages and high-concurrency messages; if the message is a high-concurrency message, acquiring the backlog quantity of the high-concurrency message; and delivering the high-concurrency message to a process center through a target channel according to the numerical relationship between the backlog quantity and a preset threshold, wherein the target channel comprises an HTTP channel and a message queue channel. The application can meet the real-time requirement of a business scenario.

Description

Technical Field

[0001] This application relates to the field of information transmission technology, and in particular to a message delivery method, device and storage medium. Background Technology

[0002] Currently, to ensure messages are delivered accurately and completely from producers to consumers, an asynchronous approach based on message queues can be used. However, to guarantee message reliability, message queues introduce mechanisms such as persistent storage, replica acknowledgment, and queue scheduling, which significantly increases end-to-end message latency, making it difficult to meet the real-time requirements of business scenarios. Summary of the Invention

[0003] The main purpose of this application is to provide a message delivery method, device, and storage medium, which aims to solve the technical problem that message queues cannot meet the real-time requirements of business scenarios.

[0004] To achieve the above objectives, this application provides a message delivery method, which includes: The message type to retrieve messages includes real-time messages and high-concurrency messages; If the message is a high-concurrency message, get the backlog of high-concurrency messages; Based on the numerical relationship between the backlog and a preset threshold, high-concurrency messages are delivered to the process center through target channels, including HTTP channels and message queue channels.

[0005] In one embodiment, the message type for obtaining the message includes: Retrieve the message type pre-configured for the message; If no message type is pre-configured, the rule engine parses the configured static rules to obtain the parsed rules; The parsed rules are sorted according to priority, and the message body is matched against the sorted rules in turn. If a match is found, the matched message type is taken as the message type.

[0006] In one embodiment, after obtaining the message type of the message, which includes real-time messages and high-concurrency messages, the method further includes: If the message is a real-time message, it will be delivered to the process center via an HTTP channel.

[0007] In one embodiment, based on the numerical relationship between the backlog quantity and a preset threshold, high-concurrency messages are delivered to the process center through a target channel. The target channel includes an HTTP channel and a message queue channel, including: Determine whether the backlog of high-concurrency messages exceeds a preset threshold; If the backlog exceeds the preset threshold, high-concurrency messages will be delivered to the process center via HTTP channel; If the backlog does not exceed the preset threshold, high-concurrency messages will be delivered to the process center through the message queue channel.

[0008] In one embodiment, after delivering high-concurrency messages to the process center via a message queue channel, the process includes: Periodically analyze historical data within a preset time period, count the number of messages per minute, and calculate the average message volume and standard deviation. The time period is divided into peak period, normal period and off-peak period; Based on the average message volume and standard deviation, the thresholds corresponding to peak periods, normal periods and idle periods are determined respectively, resulting in peak period threshold, normal period threshold and idle period threshold; Based on the time period corresponding to the current moment, select the corresponding target threshold from the peak period threshold, normal period threshold and idle period threshold, and use the target threshold as the new preset threshold; Among them, the peak period threshold is greater than the normal period threshold, and the normal period threshold is greater than the idle period threshold.

[0009] In one embodiment, after delivering high-concurrency messages to the process center via a message queue channel, the process further includes: If the submission to the process center is successful, record the latest process session identifier for the normal consumption status of each service process; If delivery to the process center fails, the message is marked as a message queue sending failure and the message is recorded in the local table. The message queue delivery is retried three times by a scheduled task. If successful, the message enters the message queue and is then delivered to the process center through the message queue. If all three attempts fail, the message will be delivered to the process center via the HTTP channel.

[0010] In one embodiment, if all three attempts fail, after delivering the message to the process center via the HTTP channel, the process further includes: When the process center receives a message that should have been delivered through the message queue channel via the HTTP channel, it records the message identifier and uses the message identifier as the minimum failure identifier. Obtain the latest process session identifier for the normal consumption status of each service process, and use the process session identifier as the maximum success identifier; The process center sends the compensation range between the maximum success identifier and the minimum failure identifier to the business service. The business service then re-delivers all exception messages within the compensation range to the process center via the HTTP channel. The compensation range is the message identifier range that is greater than the maximum success identifier and less than the minimum failure identifier.

[0011] In one embodiment, after delivering the message to the process center via an HTTP channel, the process further includes: If the interface response from the process center fails, the message will be stored in a local table. The system automatically retryes after a preset time interval using a scheduled task, reads messages from the local table, and delivers the messages to the process center via an HTTP channel.

[0012] In addition, to achieve the above objectives, this application also provides a message delivery device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the above message delivery method.

[0013] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, and stores a program implementing the message delivery method on the computer-readable storage medium. The program implementing the message delivery method is executed by a processor to implement the steps of the above message delivery method.

[0014] This application provides a message delivery method. The method involves obtaining the message type, which includes real-time messages and high-concurrency messages; if the message is a high-concurrency message, the method obtains the backlog of high-concurrency messages; and based on the relationship between the backlog and a preset threshold, the high-concurrency message is delivered to the process center through a target channel, which may include an HTTP channel or a message queue channel. By automatically routing high-concurrency messages to either an HTTP channel or a message queue channel based on the relationship between the backlog and the preset threshold, the method achieves channel switching for high-concurrency messages during congestion, meeting the real-time message delivery requirements of business scenarios. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating an embodiment of the message delivery method of this application. Figure 2 A flowchart illustrating the rule matching engine provided in Embodiment 2 of the message delivery method of this application; Figure 3 This is a schematic diagram of the rule parsing process provided in Embodiment 2 of the message delivery method of this application; Figure 4 This is a schematic diagram of the MQ channel delivery process provided in Embodiment Six of the Message Delivery Method of this Application; Figure 5 This is a schematic diagram of the MQ abnormal state process provided in Embodiment 7 of the message delivery method of this application; Figure 6 This is a schematic diagram of the HTTP channel delivery process provided in Embodiment 8 of the message delivery method of this application; Figure 7 A simplified flowchart illustrating the message delivery method provided in this application; Figure 8 This is a schematic diagram of the message delivery device in the embodiments of this application.

[0018] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0020] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0021] Currently, to ensure messages are delivered accurately and completely from producers to consumers, an asynchronous approach based on message queues can be used. However, to guarantee message reliability, message queues introduce mechanisms such as persistent storage, replica acknowledgment, and queue scheduling, which significantly increases end-to-end message latency, making it difficult to meet the real-time requirements of business scenarios.

[0022] The main solution of this application is as follows: First, the message type is obtained, including real-time messages and high-concurrency messages. If the message is a high-concurrency message, the backlog of high-concurrency messages is obtained. Then, based on the relationship between the backlog and a preset threshold, the high-concurrency message is delivered to the process center through a target channel, including an HTTP channel and a message queue channel. By selecting the automatic routing of high-concurrency messages to either the HTTP channel or the message queue channel based on the relationship between the backlog and the preset threshold, channel switching for high-concurrency messages during congestion is achieved, meeting the real-time message delivery requirements of business scenarios.

[0023] It should be noted that the executing entity in this embodiment can be a message delivery device, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a message delivery device capable of performing the above functions. This embodiment does not specifically limit this. The following uses a message delivery device as the executing entity as an example to describe this embodiment and the following embodiments.

[0024] Based on this, Embodiment 1 of this application proposes a message delivery method, please refer to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the message delivery method of this application. The message delivery method includes steps S10 to S30: Step S10: Obtain the message type of the message. The message type includes real-time messages and high-concurrency messages.

[0025] In this embodiment, message type refers to a classification label set to distinguish the real-time requirements and concurrency characteristics of messages; real-time message refers to a message that is sensitive to real-time performance and requires low-latency response; high-concurrency message refers to a message with a large message volume, relatively low real-time requirements but requires high-throughput reliable transmission.

[0026] As an optional implementation, the message type is actively configured by the business party.

[0027] Specifically, the system reserves a type field for messages, which the business side specifies the value of when constructing the message based on its business needs. The system directly reads the value of this field as the message type, without the need for additional rule matching or inference. The business side can directly specify the message type through the reserved field, quickly obtaining the message type without additional calculations, thus reducing the system's computational overhead.

[0028] Specifically, the system calls the rule engine to parse the pre-configured static rules, obtaining a set of parsed rules. The rule engine then sorts the parsed rules according to priority from high to low, and matches the message body against the sorted rules sequentially. If the message body matches the current rule's condition, subsequent matching immediately stops, and the message type corresponding to the current rule is taken as the message type. If no condition is matched after traversing all rules, the message is classified as a high-concurrency message according to the default strategy. By parsing static rules and automatically matching them according to priority through the rule engine, automated message type identification and intelligent routing are achieved.

[0029] Step S20: If the message is a high-concurrency message, obtain the backlog of high-concurrency messages.

[0030] In this embodiment, the backlog refers to the total number of messages that have been successfully received in the MQ (Message Queue) but have not yet been consumed by the process center, which is used to reflect the current load pressure and congestion level of the MQ channel in real time.

[0031] As an optional implementation, the backlog of high-concurrency messages can be queried directly through the message queue management interface.

[0032] Specifically, when a message is identified as a high-concurrency message and initially routed to the MQ channel, the system calls the management interface provided by the MQ server, such as RabbitMQ's `rabbitAdmin.getQueueInfo(queueName).getMessageCount()` method, to directly obtain the number of messages in the message queue. This number represents the current backlog in the MQ channel. Obtaining the message queue count directly through the native management interface provided by the message middleware is simple, accurate, and accurately reflects the current backlog and load pressure of the MQ channel.

[0033] As an alternative implementation, the backlog of high-concurrency messages is obtained through a self-maintaining method based on Redis (Remote Dictionary Server) atomic counters.

[0034] Specifically, the system maintains a counter using Redis's atomic increment method when a message is successfully delivered, and maintains the same counter using an atomic decrement method when the message is successfully consumed by the process center. By calculating the current value of this counter in real time, the real-time backlog of the message queue can be obtained. Maintaining the counter using Redis's atomic increment and decrement operations offers strong versatility and portability, enabling real-time calculation and acquisition of the backlog of any MQ queue, providing real-time data support for channel switching decisions.

[0035] Step S30: Based on the numerical relationship between the backlog quantity and the preset threshold, high-concurrency messages are delivered to the process center through the target channel, which includes the HTTP channel and the message queue channel.

[0036] In this embodiment, the HTTP channel refers to a synchronous message delivery channel implemented based on the HTTP / HTTPS protocol, which has the characteristics of low-latency synchronous response, and messages can be delivered to the process center immediately without queuing; the message queue channel refers to an asynchronous message delivery channel implemented based on a message queue, which has the characteristics of persistence and high reliability.

[0037] As an optional implementation, high-concurrency messages are delivered to the process center through the target channel based on the numerical relationship between the backlog quantity and a fixed preset threshold.

[0038] Specifically, the system retrieves the current backlog of messages in the MQ queue and compares it to a fixed, preset threshold. If the backlog exceeds the threshold, it indicates that the MQ channel is overloaded, and the system switches high-concurrency messages to the HTTP channel, where the business service synchronously sends them to the process center via HTTP / HTTPS protocol. If the backlog does not exceed the threshold, it indicates that the MQ channel is under normal load, and the system delivers high-concurrency messages through the MQ channel for asynchronous consumption by the process center. By setting a fixed backlog threshold as the criterion for channel switching, messages can be quickly routed to the process center through the appropriate target channel.

[0039] As another optional implementation, based on the numerical relationship between the backlog quantity and a preset threshold, high-concurrency messages are delivered to the process center through the target channel, wherein the preset threshold is periodically statistically analyzed and updated based on historical message delivery records.

[0040] Specifically, historical message delivery records within a preset time period are analyzed periodically. Message volume is counted at a minute-by-minute granularity, and the average message volume μ and standard deviation σ are calculated based on the message volume obtained at this time-granularity. Then, the time intervals are sorted from largest to smallest by message count, with the top 10% of intervals designated as peak periods, the bottom 30% as idle periods, and the remaining intervals as normal periods. The peak period threshold = μ + 2σ, the normal period threshold = μ, and the idle period threshold = μ - 2σ. These thresholds for each time period serve as the backlog thresholds for subsequent messages. When a message is identified as a high-concurrency message, the system obtains the current backlog quantity in the target MQ queue and selects the corresponding backlog threshold based on the current time period. The backlog quantity is compared with this target threshold. If the backlog quantity exceeds the target threshold, it indicates that the MQ channel is overloaded in the current time period, and the high-concurrency message is switched to the HTTP channel for delivery; if the backlog quantity does not exceed the target threshold, it indicates that the MQ channel is under normal load, and the high-concurrency message is delivered through the MQ channel. By regularly analyzing historical message delivery records and dynamically updating the backlog threshold, the backlog threshold can adapt to the periodic changes in business traffic, thus improving the system's adaptability to different traffic patterns.

[0041] This embodiment provides a message delivery method. First, it obtains the message type, including real-time messages and high-concurrency messages. If the message is a high-concurrency message, it obtains the backlog of high-concurrency messages. Based on the relationship between the backlog and a preset threshold, the high-concurrency message is delivered to the process center through a target channel, including an HTTP channel and a message queue channel. By selecting the automatic routing of high-concurrency messages to either the HTTP channel or the message queue channel based on the relationship between the backlog and the preset threshold, channel switching for high-concurrency messages during congestion is achieved, meeting the real-time message delivery requirements of business scenarios.

[0042] Based on Embodiment 1, in Embodiment 2 of this application, the content that is the same as or similar to that in Embodiment 1 can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2 This is a flowchart illustrating the rule matching engine provided in Embodiment 2 of the message delivery method of this application. First, the data structure of the message body is parsed, and the rules are prioritized. Then, the message content is matched with the rules according to priority and output to obtain the message type. The message type includes: Step S11: Obtain the message type pre-configured for the message.

[0043] Step S12: If the message type is not pre-configured, the configured static rules are parsed by the rule engine to obtain the parsed rules.

[0044] In this embodiment, a rule engine refers to a system component used to execute and maintain business rules. It can parse and match preset rules according to a predetermined priority, thereby automatically outputting decision results. Static rules refer to a pre-configured set of matching conditions. The rule engine determines the message type corresponding to a message by parsing static rules.

[0045] As one implementation method, please refer to Figure 3 , Figure 3 This is a schematic diagram of the rule parsing process provided in Embodiment 2 of the message delivery method of this application. The system first obtains external rule configuration files from the configuration center. The rule loader reads and parses these rule configuration files and stores the parsed rules in the rule cache. After receiving a message to be delivered, the system first obtains the message type pre-configured for the message, where the message type is specified by the business party through a reserved type field in the message. If the business party has not pre-specified the message type, the rule engine parses the configured static rules to obtain the parsed rules, where the static rules include at least field matching rules and source identification rules. Parsing the static rules through the rule engine provides a basis for subsequent matching according to rule priority.

[0046] Step S13: Sort the parsed rules according to priority, and match the message body of the message with the sorted rules in turn. If a match is found, the matched message type is taken as the message type of the message.

[0047] As one implementation method, the parsed rules are sorted from highest to lowest priority. The message body is then matched against the sorted rules sequentially, starting with the highest priority rule and comparing each rule one by one. If the message body matches the current rule's condition, subsequent matching stops immediately, and the message type corresponding to the current rule is taken as the message type. If no condition is matched after traversing all rules, the message is identified as a high-concurrency message and routed to the MQ channel according to the default strategy. For example, rule matching is performed according to the priority order of field matching and source identification. Field matching checks whether the message body contains specific field data. If the message body contains fields related to VIP user information, it is marked as a real-time message. If the message body contains key fields of high-frequency processes such as overtime or clock-in / out, it is marked as a high-concurrency message. If the message type is not determined after field matching, the source is identified based on the upstream service or interface type. If the message comes from upstream services such as attendance services or process tracking services, it is marked as a high-concurrency message. By using a priority-based matching mechanism, important rules are identified first, while messages that do not match the rules are also delivered correctly, thus achieving automated and intelligent message type-aware routing.

[0048] Furthermore, the static rules used for matching can be configured and modified according to business scenarios. Business users or operations personnel can flexibly define and dynamically adjust the rule set based on their own business's real-time requirements, message sources, field characteristics, traffic characteristics, and system load. They can also set matching priority orders for different rules based on business importance. By flexibly configuring static rules and their priorities, message type-aware routing can adapt to the real-time requirements and traffic characteristics of different business scenarios, achieving intelligent matching of message delivery channels.

[0049] In this embodiment, the static rules are parsed and matched according to priority by the rule engine, realizing automatic inference of message type and intelligent routing. The delivery channel can be adaptively selected according to message characteristics without the need for manual configuration by the business side, which improves the flexibility and accuracy of message delivery.

[0050] Based on any of the above embodiments of this application, Embodiment 3 of this application proposes a message delivery method, which can be referred to the above description and will not be repeated hereafter. In addition, after obtaining the message type (including real-time messages and high-concurrency messages), the method further includes: Step S101: If the message is a real-time message, deliver the real-time message to the process center via the HTTP channel.

[0051] As one implementation method, if the identified message type is a real-time message, the real-time message is delivered via an HTTP channel. The business service, acting as the message producer, synchronously sends the serialized real-time message to the interface address provided by the process center via the HTTP / HTTPS protocol. Due to the low-latency synchronous response characteristic of the HTTP channel, real-time messages do not need to queue in an MQ queue and can be delivered to the process center and consumed immediately. By leveraging the low-latency synchronous response characteristic of the HTTP channel, real-time messages can be delivered to the process center immediately without queuing in an MQ queue, achieving both low-latency delivery and high reliability assurance for real-time messages.

[0052] In this embodiment, by confirming that the message type is a real-time message, the message is delivered directly through the HTTP channel to the process center, which can obtain a low-latency response and meet the timeliness requirements of real-time business scenarios for message delivery.

[0053] Based on any of the above embodiments of this application, Embodiment 4 of this application proposes a message delivery method, which can be referred to the above description and will not be repeated hereafter. Based on this, according to the numerical relationship between the backlog quantity and a preset threshold, high-concurrency messages are delivered to the process center through a target channel. The target channel includes an HTTP channel and a message queue channel, including: Step S31: Determine whether the backlog of high-concurrency messages exceeds a preset threshold.

[0054] Step S32: If the backlog exceeds a preset threshold, the high-concurrency message will be delivered to the process center via the HTTP channel.

[0055] Step S33: If the backlog does not exceed the preset threshold, the high-concurrency messages will be delivered to the process center through the message queue channel.

[0056] As one implementation method, if the message type is a high-concurrency message, it is temporarily scheduled to be delivered through a message queue channel, and the current backlog of the target MQ queue is obtained. If the backlog exceeds a preset threshold, it indicates that the MQ processing capacity has reached a bottleneck. To avoid messages waiting in the MQ for a long time, the high-concurrency message is automatically switched to the HTTP channel, and the business service synchronously sends it to the process center via HTTP / HTTPS protocol, thereby utilizing the low latency characteristics of HTTP to release messages in a timely manner and prevent the MQ latency from amplifying indefinitely. If the backlog does not exceed the preset threshold, it indicates that the MQ is currently under normal load, and the high-concurrency message is sent to the MQ queue for asynchronous consumption by the process center. Through backlog-aware dynamic routing decisions, high-concurrency messages can be automatically routed to the HTTP channel when the MQ is congested, and normally use the MQ channel when the MQ is idle, achieving a dynamic balance between system throughput and timeliness.

[0057] In this embodiment, by comparing the backlog of MQ messages with a dynamic threshold, an adaptive routing decision is automatically made between the MQ channel and the HTTP channel for high-concurrency messages, thereby simultaneously meeting the message delivery requirements of low latency, high throughput, and high reliability.

[0058] Based on Embodiment 4 of this application, Embodiment 5 of this application proposes a message delivery method, which can be referred to the above description and will not be repeated hereafter. Based on this, after delivering high-concurrency messages to the process center through the message queue channel, the method includes: Step S331: Periodically analyze historical data within a preset time period, count the number of messages per minute, and calculate the average message volume and standard deviation.

[0059] In this embodiment, the average message volume μ refers to the arithmetic mean of the number of messages counted per minute within a preset time period, which is used to reflect the overall average level of message delivery within that time period; the standard deviation σ refers to the measure of the degree of deviation between the message volume of each minute and the average value, which is used to reflect the degree of fluctuation and dispersion of the message volume around the average value. The larger the standard deviation, the more severe the traffic fluctuation.

[0060] As one implementation method, historical data within a preset time period is analyzed periodically. For example, an analysis task for recent historical message delivery records is automatically triggered every morning. This extracts all message delivery records from the past preset number of days, such as the last 7 or 30 days, from message delivery logs or a database, and groups these records by timestamp at a minute-by-minute granularity. For each minute-level time interval, the total number of messages actually delivered within that interval is counted, resulting in a numerical sequence of message counts. Then, the arithmetic mean of all message counts in this sequence is calculated, representing the average level of message delivery within that time period. Simultaneously, the standard deviation of all message counts is calculated to represent the degree of dispersion of message counts around the average value. By calculating the minute-by-minute average message count and standard deviation, which describe the characteristics of historical message traffic, a data foundation is provided for subsequent time period division and threshold generation.

[0061] Step S332: Divide the time period into peak period, normal period and idle period.

[0062] Step S333: Based on the average message volume and standard deviation, determine the thresholds corresponding to peak period, normal period and idle period respectively, and obtain the peak period threshold, normal period threshold and idle period threshold.

[0063] Step S334: Based on the time period corresponding to the current moment, select the corresponding target threshold from the peak period threshold, normal period threshold, and idle period threshold, and use the target threshold as the new preset threshold.

[0064] Among them, the peak period threshold is greater than the normal period threshold, and the normal period threshold is greater than the idle period threshold.

[0065] As one implementation method, each time interval within a preset time period is sorted, such as by the number of messages per minute from largest to smallest. The top 10% of time intervals are selected as peak periods, the bottom 30% as idle periods, and the remaining time intervals as normal periods. Based on the average message volume μ and standard deviation σ, thresholds corresponding to peak periods, normal periods, and idle periods are determined, resulting in peak period thresholds = μ + 2σ, normal period thresholds = μ, and idle period thresholds = μ - 2σ. Then, based on the current time period, a target threshold is selected from the peak period threshold, normal period threshold, and idle period threshold. This target threshold is used as a new preset threshold for comparing and judging the number of high-concurrency message backlogs at subsequent times, thereby achieving adaptive switching between the MQ channel and the HTTP channel. By automatically adjusting the MQ backlog threshold based on historical data, it can adapt to the periodic changes in business traffic without manual intervention.

[0066] In this embodiment, by generating dynamic thresholds based on historical data volume statistics and selecting corresponding backlog thresholds according to time periods, a dynamic balance is achieved where the message queue (MQ) is automatically routed to the HTTP channel when congested and normally uses the MQ channel when the MQ is idle, thereby simultaneously meeting the message delivery requirements of low latency, high throughput, and high reliability.

[0067] Based on Embodiment 4 of this application, Embodiment 6 of this application proposes a message delivery method, which can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a schematic diagram of the MQ channel delivery process provided in Embodiment Six of the message delivery method of this application. First, an attempt is made to deliver the message to the MQ. If the delivery is successful, the process flows directly to the process center and the latest process session ID is recorded. If the MQ delivery fails, the message is recorded in the local message table, and a retry mechanism is triggered. If the retry fails after three attempts, the message is delivered via the HTTP channel, and the abnormal delivery situation and the smallest process session ID under this process category are recorded. After delivering high-concurrency messages to the process center through the message queue channel, the process also includes: Step S335: If the submission to the process center is successful, record the latest process session identifier of the normal consumption status of each service process.

[0068] In this embodiment, the process session identifier refers to the ID used to uniquely identify a message or a process session in the message or process session data. It records the latest sequential position of each service process being normally consumed in the process center.

[0069] As one implementation method, when a business service delivers high-concurrency messages to the process center via the MQ channel and the process center successfully consumes them, the process center records the latest process session identifier of each service process's normal consumption status. This identifier reflects the sequential position of the last message that has been normally consumed by the MQ. By recording the latest process session identifier of each service process's normal consumption, a boundary anchor point is provided for message compensation during subsequent MQ anomalies, avoiding the huge overhead of retransmitting all data.

[0070] Step S336: If delivery to the process center fails, mark the message as a message queue sending failure and record the message in the local table.

[0071] Step S337: Retry message queue delivery three times via a scheduled task. If successful, the message enters the message queue and is then delivered to the process center via the message queue.

[0072] Step S338: If all three attempts fail, the message is delivered to the process center via the HTTP channel.

[0073] As one implementation method, when a business service delivers high-concurrency messages to the process center via the MQ channel, if delivery fails, the message is marked as an MQ delivery failure message, and metadata such as message content, message identifier, failure reason, and retry count are recorded in a local table, such as a local message table created based on a relational database like TDSQL. A scheduled task then periodically scans the local table for MQ delivery failure messages and automatically retryes MQ delivery. If a retry is successful, the message enters the MQ queue normally and is consumed by the process center. After successful consumption, the latest process session identifier recording the normal consumption status of each service process is updated, and the entire process returns to the normal delivery mode of the MQ channel. If the scheduled task retryes the same message three times consecutively and still fails, the message is sent to the process center via the HTTP channel. By using a scheduled task to perform a limited number of retries for MQ delivery failure messages, normal message delivery can be automatically restored after temporary fault recovery, avoiding unnecessary channel switching.

[0074] In this embodiment, the message delivery system is retried three times via a scheduled task using the MQ channel. If the retry fails, the system automatically downgrades to the HTTP channel. This ensures that high-concurrency messages can be reliably transmitted asynchronously when the MQ channel is normal, and automatically downgrades to prevent message loss when the MQ channel is abnormal, thus improving the reliability of message delivery.

[0075] Based on Embodiment Six of this application, Embodiment Seven of this application proposes a message delivery method, which can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 5 , Figure 5This is a schematic diagram of the MQ abnormal state process provided in Embodiment 7 of the message delivery method of this application. The business service sends the message to the MQ. If the MQ consumption fails, it is transferred to the process center. After processing by the process center, the data is stored via TDSQL (Tencent Distributed SQL) and synchronized to MongoDB (MongoDB document database) via CDC (Change Data Capture). At the same time, the session ID of MQ consumption and HTTP delivery is returned to the business service via the HTTP value completion mechanism. If all three attempts fail, after delivering the message to the process center via the HTTP channel, the process also includes: Step S40: When the process center receives a message that should have been delivered through the message queue channel via the HTTP channel, it records the message identifier of the message and uses the message identifier as the minimum failure identifier.

[0076] Step S50: Obtain the latest process session identifier for the normal consumption status of each service process, and use the process session identifier as the maximum success identifier.

[0077] In step S60, the process center sends the compensation range between the maximum success identifier and the minimum failure identifier to the business service. The business service then re-delivers all abnormal messages in the compensation range to the process center via the HTTP channel. The compensation range is the message identifier range that is greater than the maximum success identifier and less than the minimum failure identifier.

[0078] In this embodiment, the maximum success identifier refers to the process session identifier of the last message normally consumed by the process center through the MQ channel, serving as the lower bound of the message loss range during MQ anomalies; the minimum failure identifier refers to the message identifier of the first message that the process center received through the HTTP channel and should have been delivered through the MQ channel, serving as the upper bound of the message loss range during MQ anomalies.

[0079] As one implementation, when a business service delivers high-concurrency messages to the process center via the MQ channel, and after three failed retries by the scheduled task, it switches to delivery via the HTTP channel. When the process center receives a message that should have been delivered via the MQ channel via the HTTP channel—that is, a message delivered via the HTTP channel after three failed retries by the scheduled task—it determines that the MQ has encountered an anomaly. At this point, the process center records the message identifier of the currently received message, using this identifier as the minimum failure identifier, marking the upper bound of the message loss range during the MQ anomaly. Simultaneously, the process center obtains the latest process session identifier of each service process's normal consumption status, using this session identifier as the maximum success identifier, marking the last position of messages normally consumed before the MQ anomaly, i.e., the lower bound of the message loss range. Then, a compensation interval between the maximum success identifier and the minimum failure identifier is sent to the business service. This compensation interval is the range of message identifiers greater than the maximum success identifier and less than the minimum failure identifier. Based on this compensation interval, the business service re-delivers all abnormal messages within this interval to the process center via the HTTP channel. After the process center completes consumption, it updates the maximum success identifier.

[0080] For example, the process center successfully consumes a message with process session identifier 100 via MQ, meaning the maximum success identifier is 100. If the MQ service then crashes, the business service fails to deliver messages with identifiers 101-200 to MQ. After three failed retries via a scheduled task, delivery is switched to an HTTP channel. When the process center receives a message with ID=101 via the HTTP channel, it detects an MQ anomaly and records the minimum failure identifier as 101. Because the MQ anomaly persists, the business service continues to deliver messages with IDs 102-200 to the process center via HTTP. Each time the process center receives a message that should have originated from MQ via HTTP, it updates the minimum failure identifier; for example, when it receives a message with ID=200, the minimum failure identifier is updated to 200. If the MQ service subsequently recovers, the process center sends the final compensation range (100, 200) to the business service, which then re-delivers messages with identifiers 101-199 to the process center via the HTTP channel. After the process center finishes consuming the message, it updates the maximum success identifier to 200. The entire compensation process avoids the huge overhead of retransmitting all data by recording two boundary values: the maximum success flag and the minimum failure flag, thus achieving automatic compensation during MQ failures.

[0081] In this embodiment, by recording only the maximum success identifier and the minimum failure identifier as boundary values, the message loss range during MQ anomalies can be accurately defined. All abnormal messages within the compensation range are batch retransmitted through the HTTP channel, avoiding the huge overhead of retransmitting all data and achieving zero message loss and automatic compensation throughout the entire process during MQ failures.

[0082] Based on Embodiments 3 or 4 of this application, Embodiment 8 of this application proposes a message delivery method, which can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 6 , Figure 6 This is a schematic diagram of the HTTP channel delivery process provided in Embodiment 8 of the message delivery method of this application. If the HTTP channel delivery is successful, it directly enters the process center, and subsequently undergoes TDSQL persistence and synchronization to MongoDB via CDC. If the HTTP delivery fails, the data is recorded in the local message table and a continuous retry mechanism is triggered. After a successful retry, it also enters the process center to complete the subsequent data storage and synchronization chain. After delivering the message to the process center via the HTTP channel, the process also includes: Step S100: If the interface response from the process center fails, store the message in a local table.

[0083] As one implementation method, when a business service delivers real-time or high-concurrency messages to the process center via an HTTP channel, if the interface response from the process center fails, the business service stores metadata such as the message content, message identifier, failure reason, and number of retries of the failed message in a local table, such as a local message table created based on a relational database like TDSQL, to ensure that messages are not lost. By persistently storing failed HTTP delivery messages in a local table, it ensures that messages are not lost when the interface is abnormal or the service fails, providing a reliable data foundation for subsequent automatic retries.

[0084] In step S200, a scheduled task automatically retryes every preset time, reads messages from the local table, and delivers the messages to the process center via the HTTP channel.

[0085] As one implementation method, a scheduled task periodically scans the local table for HTTP delivery failure messages. Every preset time interval, it automatically reads messages awaiting retry from the local table and re-delivers them to the process center via the HTTP channel. If the retry is successful, the process center consumes the message normally and deletes it from the local table or marks it as successfully delivered. If the retry still fails, the message is retained in the local table and retried in the next scheduled period until the message is successfully delivered to the process center via the HTTP channel. By automatically reading retries from the local table via a scheduled task, automatic recovery from HTTP channel delivery failures is achieved.

[0086] In this embodiment, by using a scheduled task to automatically retry when the HTTP channel interface fails to respond, the message is ensured not to be lost and can be successfully delivered to the process center, thereby improving the reliability of HTTP channel message delivery.

[0087] For example, to help understand the technical concept or principle of the message delivery method after combining this embodiment with the above embodiments, please refer to Figure 7 , Figure 7 A simplified flowchart of the message delivery method provided in this application is shown below: After a business service initiates a message, the rule engine first determines the message type. If it's a real-time message, it's sent directly via the HTTP channel. If it's a high-concurrency message, a threshold check is performed. When the queue backlog exceeds a preset threshold, it automatically switches to the HTTP channel to send the message to the process center to alleviate queue pressure. If the threshold is not exceeded, the message is sent to the process center via the MQ channel. By using the rule engine for message type-aware routing and threshold-based queue backlog checks, real-time messages use the low-latency HTTP channel, high-concurrency messages are automatically routed to the HTTP channel when the MQ is congested, and adaptive dynamic routing is used when the MQ is idle. This maintains a balance between low latency, high throughput, and high reliability, fully meeting the real-time message delivery requirements of various business scenarios.

[0088] This application provides a message delivery device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the message delivery method in Embodiment 1 above.

[0089] The following is for reference. Figure 8 The diagram illustrates a structural schematic of a message delivery device suitable for implementing embodiments of this application. The message delivery device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablets, and in-vehicle terminals, as well as fixed terminals such as digital TVs and desktop computers. Figure 8 The message delivery device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0090] like Figure 8As shown, the message delivery device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the message delivery device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the message delivery device to communicate wirelessly or wiredly with other devices to exchange data. Although message delivery devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0091] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0092] The message delivery device provided in this application, employing the message delivery method described in the above embodiments, can solve the technical problem that message queues are insufficient to meet the real-time requirements of business scenarios. Compared with the prior art, the beneficial effects of the message delivery device provided in this application are the same as those of the message delivery device provided in the above embodiments, and other technical features of this message delivery device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0093] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0094] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0095] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the message delivery method in the above embodiments.

[0096] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), or any suitable combination thereof.

[0097] The aforementioned computer-readable storage medium may be included in the message delivery device; or it may exist independently and not assembled into the message delivery device.

[0098] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the message delivery device, the message delivery device: obtains the message type of the message, including real-time messages and high-concurrency messages; if the message is a high-concurrency message, obtains the backlog of high-concurrency messages; and according to the numerical relationship between the backlog and a preset threshold, delivers the high-concurrency message to the process center through a target channel, including an HTTP channel and a message queue channel.

[0099] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0100] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0101] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0102] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described message delivery method. This solves the technical problem that message queues are unable to meet the real-time requirements of business scenarios. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the message delivery method provided in the above embodiments, and will not be repeated here.

[0103] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the message delivery method described above.

[0104] The computer program product provided in this application can solve the technical problem that message queues are difficult to meet the real-time requirements of business scenarios. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the message delivery method provided in the above embodiments, and will not be repeated here.

[0105] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A message delivery method, characterized in that, The message delivery method includes: The message type for obtaining messages includes real-time messages and high-concurrency messages; If the message is a high-concurrency message, obtain the backlog of the high-concurrency messages; Based on the numerical relationship between the backlog quantity and a preset threshold, the high-concurrency messages are delivered to the process center through target channels, including HTTP channels and message queue channels.

2. The message delivery method as described in claim 1, characterized in that, The message types for obtaining messages include: Obtain the message type pre-configured for the message; If the message type is not pre-configured, the configured static rules are parsed by the rule engine to obtain the parsed rules; The parsed rules are sorted according to priority, and the message body of the message is matched with the sorted rules in turn. If a match is found, the matched message type is taken as the message type of the message.

3. The message delivery method as described in claim 1, characterized in that, The message type for obtaining messages, after including real-time messages and high-concurrency messages, also includes: If the message is a real-time message, the real-time message is delivered to the process center via the HTTP channel.

4. The message delivery method as described in claim 1, characterized in that, Based on the numerical relationship between the backlog quantity and a preset threshold, the high-concurrency messages are delivered to the process center through a target channel. The target channel includes an HTTP channel and a message queue channel, including: Determine whether the backlog of the high-concurrency messages exceeds the preset threshold; If the backlog exceeds the preset threshold, the high-concurrency message will be delivered to the process center via the HTTP channel; If the backlog does not exceed the preset threshold, the high-concurrency message is delivered to the process center through the message queue channel.

5. The message delivery method as described in claim 4, characterized in that, After the high-concurrency message is delivered to the process center through the message queue channel, the following steps are included: Periodically analyze historical data within a preset time period, count the number of messages per minute, and calculate the average message volume and standard deviation. The time period is divided into peak period, normal period and off-peak period; Based on the average message volume and the standard deviation, the thresholds corresponding to the peak period, the normal period, and the idle period are determined respectively, thus obtaining the peak period threshold, the normal period threshold, and the idle period threshold; Based on the time period corresponding to the current moment, select the corresponding target threshold from the peak period threshold, the normal period threshold, and the idle period threshold, and use the target threshold as the new preset threshold; Wherein, the peak period threshold is greater than the normal period threshold, and the normal period threshold is greater than the idle period threshold.

6. The message delivery method as described in claim 4, characterized in that, After delivering the high-concurrency message to the process center through the message queue channel, the process further includes: If the delivery to the process center is successful, the latest process session identifier of the normal consumption status of each service process is recorded; If delivery to the process center fails, the message is marked as a message queue sending failure and the message is recorded in the local table. The message queue delivery is retried three times by a scheduled task. If successful, the message enters the message queue and is then delivered to the process center through the message queue. If all three attempts fail, the message is delivered to the process center via the HTTP channel.

7. The message delivery method as described in claim 6, characterized in that, If all three attempts fail, after delivering the message to the process center via the HTTP channel, the process further includes: When the process center receives the message that should have been delivered through the message queue channel via the HTTP channel, it records the message identifier of the message and uses the message identifier as the minimum failure identifier. Obtain the latest process session identifier for the normal consumption status of each service process, and use the process session identifier as the maximum success identifier; The process center sends the compensation interval between the maximum success identifier and the minimum failure identifier to the business service. The business service then re-delivers all abnormal messages in the compensation interval to the process center via the HTTP channel. The compensation interval is a message identifier range that is greater than the maximum success identifier and less than the minimum failure identifier.

8. The message delivery method as described in claim 3 or 4, characterized in that, After delivering the message to the process center via the HTTP channel, the process also includes: If the interface response of the process center fails, the message will be stored in a local table. The system automatically retryes after a preset time interval via a scheduled task, reads the message from the local table, and delivers the message to the process center via the HTTP channel.

9. A message delivery device, characterized in that, The message delivery device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the message delivery method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the message delivery method as described in any one of claims 1 to 8.

Images