Multi-thread message interaction management and control method, device, equipment, medium and product
By constructing a two-layer storage structure of TopicA and TopicB and multi-threaded parallel processing, combined with channel adaptation proxy and delay queue management, the problem caused by the difference in channel carrying capacity in traditional rate limiting methods is solved, achieving efficient traffic control and business stability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-01-06
- Publication Date
- 2026-04-07
AI Technical Summary
Traditional rate limiting methods ignore the differences in carrying capacity among different third-party channels, which can easily lead to channel congestion, message transmission delays, and service crashes in high-concurrency scenarios, affecting business continuity and user experience.
By splitting messages through middleware and building a two-layer storage structure of TopicA and TopicB, combined with multi-threaded parallel processing and channel adaptation proxy, traffic is monitored and fine-grained rate limiting and delay queue management are performed based on third-party channel types, and the delay time is dynamically adjusted.
It enables traffic control based on the characteristics of third-party channels, reducing channel crashes and resource waste, improving message push efficiency, and ensuring business continuity and stability.
Smart Images
Figure CN121814698A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, device, medium and product for managing multi-threaded message interaction. Background Technology
[0002] In today's high-concurrency systems, flow control is a key means of ensuring stable service operation. Traditional rate limiting methods typically use fixed thresholds to restrict traffic. However, this approach ignores the differences in the carrying capacity of different third-party channels. In high-concurrency scenarios, it is easy to exceed the carrying capacity limits of some channels, causing problems such as channel congestion and message transmission delays. In severe cases, it can even lead to channel service crashes, directly impacting business continuity and user experience. Therefore, there is an urgent need to provide a method that can manage messages based on the characteristics of different channels. Summary of the Invention
[0003] In view of the above-mentioned defects or deficiencies in the related technologies, the purpose of this application is to provide a multi-threaded message interaction management method, device, equipment, medium and product, which can manage messages according to different channel characteristics, reduce the probability of channel congestion, message transmission delay and other problems, and effectively ensure the continuity and stability of business.
[0004] To achieve the above objectives, this application provides the following solution: Firstly, this application provides a multi-threaded message interaction management method, comprising: receiving pending messages from various business scenarios through middleware, splitting the pending messages according to business type and sending them to different queues of Topic A; extracting a first message from the different queues of Topic A, splitting the first message according to the third-party channel type corresponding to different business messages, and sending the split messages to different queues of Topic B; extracting a second message from the different queues of Topic B in a multi-threaded parallel manner, and sending the second message to the corresponding channel adaptation proxy; the channel adaptation proxy and the third-party channel type are one-to-one; sending messages to the corresponding third-party channel through the channel adaptation proxy; monitoring the message traffic sent by the channel adaptation proxy within a set time window, and determining whether the message traffic sent by each of the channel adaptation proxies within the set time window triggers rate limiting; if rate limiting is triggered, sending messages to the corresponding delayed queue through the channel adaptation proxy; if rate limiting is not triggered, continuing to send messages to the corresponding third-party channel through the channel adaptation proxy.
[0005] Optionally, monitoring the message traffic sent by the channel adapter agent within a set time window and determining whether the message traffic sent by each channel adapter agent within the set time window triggers rate limiting includes: obtaining the traffic threshold of each third-party channel set by the rate limiting platform; comparing the traffic threshold of each third-party channel with the message traffic sent by the corresponding channel adapter agent within the set time window to determine whether rate limiting is triggered.
[0006] Optionally, after sending a message to the corresponding delay queue through the channel adapter proxy, the method further includes: setting a delay time for the messages in each delay queue through a ReSet mechanism; when the waiting time of a message in any delay queue is equal to the corresponding delay time, sending the message of the corresponding delay queue to the corresponding TopicB queue, and waiting to retrieve it again in chronological order.
[0007] Optionally, the method further includes: monitoring the number of message sending failures in each of the delay queues; dynamically adjusting the delay time of each delay queue based on the number of message sending failures in each of the delay queues to obtain the current delay time of each delay queue.
[0008] Optionally, the step of sending the message in the corresponding delay queue to the corresponding TopicB queue when the waiting time of the message in any delay queue is equal to the corresponding delay time, and waiting to retrieve it again in chronological order, includes: sending the message in the corresponding delay queue to the corresponding TopicB queue when the waiting time of the message in any delay queue is equal to the current delay time, and waiting to retrieve it again in chronological order.
[0009] Optionally, the message middleware is any one of RocketMQ, RabbitMQ, or Kafka.
[0010] Secondly, this application provides a multi-threaded message interaction management device, comprising: The receiving and splitting module is used to receive messages to be processed in various business scenarios through middleware, and split the messages to be processed according to business type and send them to different queues of TopicA. The extraction and splitting module is used to extract the first message from different queues of TopicA, split the first message according to the third-party channel type corresponding to different business messages, and send the split messages to different queues of TopicB. The extraction and sending module is used to extract the second message from different queues of the TopicB in a multi-threaded parallel manner, and send the second message to the corresponding channel adaptation proxy; the channel adaptation proxy corresponds one-to-one with the third-party channel type; The first sending module is used to send messages to the corresponding third-party channel through the channel adapter proxy; The traffic monitoring module is used to monitor the message traffic sent by the channel adaptation agent within a set time window, and to determine whether the message traffic sent by each of the channel adaptation agents within the set time window triggers rate limiting. The second sending module is used to send a message to the corresponding delay queue through the channel adapter if rate limiting is triggered. The third sending module is used to continue sending messages to the corresponding third-party channel through the channel adapter proxy if rate limiting is not triggered.
[0011] Thirdly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the multi-threaded message interaction management method described in any one of the above.
[0012] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the multi-threaded message interaction management method described above.
[0013] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the multi-threaded message interaction management method described above.
[0014] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application provides a multi-threaded message interaction management method, apparatus, device, medium, and product. It receives messages to be processed in various business scenarios through middleware, splits these messages according to business type, and sends them to different queues in Topic A. It extracts a first message from the different queues in Topic A, splits the first message according to the third-party channel type corresponding to different business messages, and sends the split messages to different queues in Topic B. It extracts a second message from the different queues in Topic B using a multi-threaded parallel approach and sends the second message to the corresponding channel adaptation proxy. The channel adaptation proxy then sends the message to the corresponding third-party channel. This allows for the construction of a two-layer storage structure: Topic A split by business type + Topic B split by channel type. Combined with multi-threaded parallel processing of messages from different channels, it not only achieves peak smoothing and buffering at the receiving end but also improves message push efficiency, solving the problems of chaotic message classification and inefficient processing in traditional methods. By monitoring the message traffic sent by channel adaptation proxies within a set time window and determining whether the message traffic sent by each channel adaptation proxy within the set time window triggers rate limiting; if rate limiting is triggered, messages are sent to the corresponding delayed queue through the channel adaptation proxy; if rate limiting is not triggered, messages continue to be sent to the corresponding third-party channel through the channel adaptation proxy. This solves the limitation of traditional rate limiting, which only limits the rate at the message receiving end, by focusing on the message sending stage. It splits messages according to the third-party channel type and matches the corresponding channel adaptation proxy according to the actual carrying capacity of the third-party channel, realizing refined traffic control based on the characteristics of the adapted channel. This reduces the probability of resource waste or channel crashes caused by fixed thresholds, effectively ensuring the continuity and stability of business. Attached Figure Description
[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0016] Figure 1 A flowchart illustrating a multi-threaded message interaction management method provided in an embodiment of this application; Figure 2 A flowchart illustrating a multi-threaded message interaction management method provided in another embodiment of this application; Figure 3 A message processing diagram illustrating a multi-threaded message interaction management method provided in another embodiment of this application; Figure 4 A schematic diagram of the functional modules of a multi-threaded message interaction management device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation
[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0018] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0019] In one exemplary embodiment, such as Figure 1 As shown, a multi-threaded message interaction management method is provided. This method is executed by a computer device, specifically by a terminal or server alone, or by both a terminal and a server. In this embodiment, the method is described using a server as an example, and includes the following steps S101 to S107. Wherein: Step S101: Receive messages to be processed in various business scenarios through middleware, and split the messages to be processed according to business type and send them to different queues of TopicA.
[0020] In the example embodiment, a message middleware is a message transmission tool that focuses on sending and receiving data and integrates various subsystems in a distributed system using an efficient and reliable asynchronous message passing mechanism. The message middleware in this application embodiment is any one of RocketMQ, RabbitMQ, or Kafka.
[0021] It should be noted that the message middleware receives various business messages and stores them in different queues within TopicA (storage is split according to different business needs), achieving high-performance reception (peak shaving) and ensuring that temporary message storage does not result in loss, providing a reliable data foundation for subsequent processing. In other words, this application achieves peak shaving through asynchronous processing and the buffering effect of message queues (TopicA queues). Each business data item in this application has a topic (which can also be understood as a business identifier). Items with the same topic are placed in the same queue; that is, data with the same business identifier are placed in the same queue within TopicA. The different queues within TopicA act as buffers. When the system receives a large number of requests, they are temporarily stored in these message queues instead of being processed directly. These messages are consumed gradually according to the system's processing capacity, reducing system congestion.
[0022] Step S102: Extract the first message from different queues of TopicA, split the first message according to the third-party channel type corresponding to different business messages, and send the split messages to different queues of TopicB.
[0023] It should be noted that the embodiments of this application are mainly applied to banking business, and the third-party channel types are different types such as Bank A channel, Bank B channel, Bank C channel, etc.
[0024] Step S103: Extract the second message from different queues of TopicB using a multi-threaded parallel approach, and send the second message to the corresponding channel adapter proxy.
[0025] It should be noted that the channel adaptation proxy corresponds one-to-one with the third-party channel type.
[0026] Step S104: Send a message to the corresponding third-party channel through the channel adaptation proxy.
[0027] Step S105: Monitor the message traffic sent by the channel adapter agent within the set time window, and determine whether the message traffic sent by each channel adapter agent within the set time window triggers rate limiting.
[0028] Optionally, obtain the traffic threshold of each third-party channel set by the rate limiting platform; compare the traffic threshold of each third-party channel with the message traffic sent by the corresponding channel adapter proxy within the set time window to determine whether rate limiting is triggered.
[0029] Step S106: If rate limiting is triggered, a message is sent to the corresponding delay queue through the channel adaptation proxy.
[0030] In step S107, if rate limiting is not triggered, continue to send messages to the corresponding third-party channel through the channel adaptation proxy.
[0031] In conjunction with the above embodiments, the channel adaptation proxy in this application is an intermediate component that matches third-party channels and rate limiting platforms. Its core function is to achieve adaptation, transmission, and rate limiting coordination between the internal processing link of messages and external third-party channels. Specifically, the channel adaptation proxy acts as a bridge in the message sending process. The channel adaptation proxy corresponds one-to-one with a specific type of third-party channel (such as the B bank channel, the A bank channel, etc.). That is, for each type of third-party channel (such as the A bank channel), a dedicated channel adaptation proxy is configured to ensure that the message can accurately match the transmission protocol, interface specification, and other requirements of the corresponding third-party channel.
[0032] The channel adaptation proxy receives messages from TopicB (a message cache queue split by channel) from multiple threads, adapts the message format and parameters to make them conform to the receiving standards of the target third-party channel, and then sends the adapted message to the third-party channel (e.g., sending the transaction message of Bank A channel to the third-party service of Bank A through the Bank A channel adaptation proxy).
[0033] The channel adaptation proxy and the rate limiting platform work together for management. Specifically, the channel adaptation proxy works in real time with the rate limiting platform to receive the dynamic traffic thresholds set by the rate limiting platform for the corresponding third-party channels (e.g., 300 messages / second for Bank A channel and 200 messages / second for Bank B channel). At the same time, it reports its message sending traffic within the set time window to the rate limiting platform. The rate limiting platform then determines whether the rate limiting rules have been triggered. If rate limiting is triggered, the channel adaptation proxy redirects the messages to a delayed queue. If not, it continues to transmit messages to the third-party channels.
[0034] In some embodiments, after step S106, the method may further include steps S1061 to S1062, wherein: Step S1061: Set the delay time for messages in each delay queue using the ReSet mechanism; Step S1062: When the waiting time of a message in any delay queue is equal to the corresponding delay time, the message in the corresponding delay queue is sent to the corresponding TopicB queue, and waits to be retrieved again in chronological order.
[0035] It should be noted that the delay time is set according to the type of third-party channel corresponding to the delay queue. For example, if the traffic threshold of Bank A channel is 300 messages / second, then the delay time of the delay queue corresponding to Bank A channel can be set to 10 seconds; if the traffic threshold of Bank B channel is 200 messages / second, then the delay time of the delay queue corresponding to Bank A channel can be set to 5 seconds.
[0036] In some embodiments, in order to dynamically adjust the delay time of the delay queue, the method may further include: monitoring the number of message sending failures in each delay queue; dynamically adjusting the delay time of each delay queue based on the number of message sending failures in each delay queue, to obtain the current delay time of each delay queue.
[0037] It should be noted that the delay time of messages in the delay queue in this application embodiment can gradually increase with the number of message sending failures. For example, the delay time corresponding to the first sending failure is 1 second, the delay time corresponding to the second sending failure is 5 seconds, the delay time corresponding to the third sending failure is 10 seconds, and the delay time of subsequent sending failures is set according to the same increasing rule.
[0038] In some embodiments, after dynamically adjusting the delay time, step S108 may further include: when the waiting time of a message in any delay queue is equal to the current delay time, sending the message of the corresponding delay queue to the corresponding TopicB queue, and waiting to retrieve it again in chronological order.
[0039] It should be noted that after the message from the corresponding delayed queue is sent to the corresponding TopicB queue, the message from the delayed queue has a higher processing priority than the first message extracted from the corresponding TopicA queue. The messages from the delayed queue are processed according to the order in which they were initially extracted.
[0040] By implementing steps S101 to S207 above, the middleware receives messages to be processed under various business scenarios, splits the messages according to business type, and sends them to different queues of TopicA; by extracting the first message from different queues of TopicA, splitting the first message according to the third-party channel type corresponding to different business messages, and sending the split messages to different queues of TopicB; by extracting the second message from different queues of TopicB in a multi-threaded parallel manner, and sending the second message to the corresponding channel adaptation proxy; by sending the message to the corresponding third-party channel through the channel adaptation proxy; a two-layer storage structure of TopicA split by business + TopicB split by channel can be constructed, and by combining multi-threaded parallel processing of messages from different channels, not only can peak shaving and buffering be achieved at the receiving end, but message push efficiency can also be improved, solving the problems of chaotic message classification and inefficient processing in traditional methods; By monitoring the message traffic sent by channel adaptation proxies within a set time window and determining whether the message traffic sent by each channel adaptation proxy within the set time window triggers rate limiting; if rate limiting is triggered, messages are sent to the corresponding delayed queue through the channel adaptation proxy; if rate limiting is not triggered, messages continue to be sent to the corresponding third-party channel through the channel adaptation proxy. This solves the limitation of traditional rate limiting, which only limits the rate at the message receiving end, by focusing on the message sending stage. It splits messages according to the third-party channel type and matches the corresponding channel adaptation proxy according to the actual carrying capacity of the third-party channel, realizing refined traffic control based on the characteristics of the adapted channel. This reduces the probability of resource waste or channel crashes caused by fixed thresholds, effectively ensuring the continuity and stability of business.
[0041] In another exemplary embodiment of this application, in order to achieve end-to-end rate limiting and dynamic threshold control, such as... Figure 2 As shown, the method may include steps S201 to S2027. Wherein: Step S201: Receive messages to be processed in various business scenarios through middleware, and split the messages to be processed according to business type and send them to different queues of TopicA. Step S202: Extract the first message from different queues of TopicA, split the first message according to the third-party channel type corresponding to different business messages, and send the split messages to different queues of TopicB. Step S203: Extract the second message from different queues of TopicB using a multi-threaded parallel approach, and send the second message to the corresponding channel adapter proxy. Step S204: Send a message to the corresponding third-party channel through the channel adaptation proxy; Step S205: Monitor the message traffic sent by the channel adapter agent within the set time window, and determine whether the message traffic sent by each channel adapter agent within the set time window triggers rate limiting. Step S206: If rate limiting is not triggered, send a message to the corresponding delay queue through the channel adaptation proxy; Step S207: If rate limiting is triggered, a message is sent to the corresponding delay queue through the channel adaptation proxy; Step S208: When the waiting time of a message in any delay queue is equal to the corresponding delay time, the message in the corresponding delay queue is sent to the corresponding TopicB queue and waited to be retrieved again in chronological order. Step S209: Monitor the number of message sending failures in each delay queue; and dynamically adjust the delay time of each delay queue based on the number of message sending failures in each delay queue to obtain the current delay time of each delay queue. Step S210: When the waiting time of a message in any delay queue is equal to the current delay time, the message in the corresponding delay queue is sent to the corresponding TopicB queue, and waits to be retrieved again in chronological order.
[0042] Combination Figure 3Understandably, for example, the operations side pushes transaction messages from different channels to the message center (server) through a message middleware. Then, step S1 is executed, where the message center (server) receives the transaction messages through the message middleware and stores them uniformly in topic A. Next, step S2 is executed, where the message center (server) categorizes the transaction messages in topic A according to channel type (Bank A, Bank B, Bank C, Bank D, etc.) and stores them in different queues in topic B. For example, transaction messages from Bank A are stored in queue t1 of topic B, those from Bank B in queue t2, those from Bank C in queue t3, those from Bank D in queue t4, and so on. Then, step S... 3. Use multiple threads to retrieve transaction messages from different queues in topic B, and send the messages to different third-party channels through different channel adapters. For example, after retrieving transaction messages from queues t1, t2, t3, and t4 of topic B using multiple threads, send the transaction messages from queue t1 to bank A of the third-party channel through channel adapter 1; send the transaction messages from queue t2 to bank B of the third-party channel through channel adapter 2; send the transaction messages from queue t3 to bank C of the third-party channel through channel adapter 3; and send the transaction messages from queue t4 to bank D of the third-party channel through channel adapter 4, etc.
[0043] The above describes the normal message processing scenario (non-rate-limited). In other abnormal scenarios (rate-limited), if a transaction message fails to send, it is placed in a delay queue. Once the delay expires, it is sent again. If it fails again, this process continues. Specifically, step S4 is executed to determine if the transaction message from the channel adapter is rate-limited. If so, the message is placed in the delay queue. Then, step S5 is executed to determine if the current delay time in the delay queue has expired. If so, expired transaction messages are added to different queues in topicB. Then, step S3 is executed, and this process repeats until all request information has been processed.
[0044] It should be noted that the situations in which the transaction message sending fails in this application embodiment include: 1. There are 10 servers in the third-party channel, which can receive and process 300 transaction messages per second. If one server fails, the channel can only handle 270 messages per second, and the remaining 30 messages will fail to be received. 2. Due to brief network fluctuations (within a few seconds), the transaction message failed to be sent. 3. The message volume is too large, triggering the rate limiting platform and causing the transaction message to fail to be sent.
[0045] Delayed queue: Each time a transaction message fails to send, the delay time is extended to alleviate pressure on the message center. For example: If an account transaction message fails to be sent on the first attempt, wait 1 second before resending. If a transaction message fails to be sent on the second attempt, a 5-second delay will occur before resending. If an account transaction message fails to be sent on the third attempt, a 10-second delay will be applied before resending. If the capacity of each third-party channel changes, the rate limiting threshold of the rate limiting platform can be adjusted, and the sending volume per second of the message center can be adjusted appropriately to prevent the service of the third-party channel from crashing.
[0046] For example: Bank A supports 300 transaction messages per second, so the rate limiting platform can configure Bank A's channel adapter proxy to 300 / s. If Bank A's server upgrades or malfunctions, causing a change in capacity, the rate limiting platform's rate limiting configuration can be modified. For instance, Bank A's rate limiting threshold 1 can be adjusted from 300 / s to 227 / s, meaning Bank A's channel adapter proxy can be configured to 227 / s. Bank B's server supports 200 transaction messages per second, so the rate limiting platform can configure Bank B's channel adapter proxy to 200 / s. Bank C's server supports 817 transaction messages per second, so the rate limiting platform can configure Bank C's channel adapter proxy to 817 / s.
[0047] It should be noted that this application's Figure 3 The thresholds 1, 2, and 3 of the rate limiting platform correspond one-to-one with the channel adaptation proxy.
[0048] Through the above embodiments, this application can overcome the limitations of traditional rate limiting only at the message receiving end, focusing on the message sending stage. It dynamically sets exclusive rate limiting thresholds based on the actual carrying capacity of third-party channels (such as the processing capacity per second of different bank channels), achieving refined traffic control adapted to channel characteristics and avoiding resource waste or channel crashes caused by fixed thresholds. By constructing a two-layer storage structure of "TopicA split by business + TopicB split by channel" through message middleware, combined with multi-threaded parallel processing of messages from different channels, it achieves both peak shaving and buffering at the receiving end and improves message push efficiency, solving the problems of chaotic message classification and inefficient processing in traditional methods. By introducing a delayed queue and Reset mechanism, for messages that trigger rate limiting or fail to send (such as third-party server failures or network jitter scenarios), the delayed sending time is extended in a step-by-step manner according to the number of failures (1s→5s→10s…), balancing system pressure and message delivery rate, and avoiding repeated impact on the channel. By integrating four aspects—message middleware (peak shaving + storage), multithreading (parallel processing), dynamic rate limiting (threshold adaptation), and delay queues—a message channel management system covering the entire process from receiving to classification, sending, rate limiting, and retrying is formed. This system adapts to diverse business scenarios and differences in third-party channels, effectively ensuring business continuity and stability.
[0049] Based on the same inventive concept, this application also provides a multi-threaded message interaction management device for implementing the multi-threaded message interaction management method described above. The solution provided by this device is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more embodiments of the multi-threaded message interaction management device provided below can be found in the limitations of the multi-threaded message interaction management method described above, and will not be repeated here.
[0050] In one exemplary embodiment, such as Figure 4 As shown, a multi-threaded message interaction management device is provided. The multi-threaded message interaction management device 400 includes: a receiving and splitting module 401, an extraction and splitting module 402, an extraction and sending module 403, a first sending module 404, a traffic monitoring module 405, a second sending module 406, and a third sending module 407; wherein, The receiving and splitting module 401 is used to receive messages to be processed in various business scenarios through middleware, and split the messages to be processed according to business type and send them to different queues of TopicA. The extraction and splitting module 402 is used to extract the first message from different queues of TopicA, split the first message according to the third-party channel type corresponding to different business messages, and send the split messages to different queues of TopicB. The extraction and sending module 403 is used to extract the second message from different queues of TopicB in a multi-threaded parallel manner and send the second message to the corresponding channel adapter proxy; the channel adapter proxy corresponds one-to-one with the third-party channel type; The first sending module 404 is used to send messages to the corresponding third-party channel through the channel adaptation proxy; The traffic monitoring module 405 is used to monitor the message traffic sent by the channel adapter agent within a set time window, and to determine whether the message traffic sent by each channel adapter agent within the set time window triggers rate limiting. The second sending module 406 is used to send a message to the corresponding delay queue through the channel adapter if rate limiting is triggered. The third sending module 407 is used to continue sending messages to the corresponding third-party channel through the channel adapter proxy if rate limiting is not triggered.
[0051] As an optional implementation, the traffic monitoring module 405 is specifically used to obtain the traffic threshold of each third-party channel set by the traffic limiting platform; compare the traffic threshold of each third-party channel with the message traffic sent by the corresponding channel adapter proxy within a set time window, and determine whether traffic limiting is triggered.
[0052] As an optional implementation, the multi-threaded message interaction management device 400 also includes a fourth sending module, which is used to set the delay time for messages in each delay queue through the ReSet mechanism; when the waiting time of a message in any delay queue is equal to the corresponding delay time, the message of the corresponding delay queue is sent to the corresponding TopicB queue, and waits to be retrieved again in chronological order.
[0053] As an optional implementation, the multi-threaded message interaction management device 400 also includes a monitoring module, which monitors the number of message sending failures in each delay queue; and dynamically adjusts the delay time of each delay queue based on the number of message sending failures in each delay queue to obtain the current delay time of each delay queue.
[0054] As an optional implementation, the fourth sending module is further specifically used to send the message of the corresponding delay queue to the corresponding TopicB queue when the waiting time of the message in any delay queue is equal to the current delay time, and wait to be retrieved again in chronological order.
[0055] As an optional implementation, the message middleware can be any one of RocketMQ, RabbitMQ, or Kafka.
[0056] This implementation method involves receiving messages to be processed from various business scenarios through middleware, splitting the messages according to business type, and sending them to different queues in TopicA. First messages are extracted from different queues in TopicA, split according to the third-party channel type corresponding to different business messages, and sent to different queues in TopicB. Second messages are extracted from different queues in TopicB using a multi-threaded parallel approach and sent to the corresponding channel adaptation proxy. Messages are then sent to the corresponding third-party channels through the channel adaptation proxy. This allows for the construction of a two-layer storage structure: TopicA split by business type + TopicB split by channel type. Combined with multi-threaded parallel processing of messages from different channels, this not only achieves peak shaving and buffering at the receiving end but also improves message push efficiency, solving the problems of chaotic message classification and inefficient processing in traditional methods. By monitoring the message traffic sent by channel adaptation proxies within a set time window and determining whether the message traffic sent by each channel adaptation proxy within the set time window triggers rate limiting; if rate limiting is triggered, messages are sent to the corresponding delayed queue through the channel adaptation proxy; if rate limiting is not triggered, messages continue to be sent to the corresponding third-party channel through the channel adaptation proxy. This solves the limitation of traditional rate limiting, which only limits the rate at the message receiving end, by focusing on the message sending stage. It splits messages according to the third-party channel type and matches the corresponding channel adaptation proxy according to the actual carrying capacity of the third-party channel, realizing refined traffic control based on the characteristics of the adapted channel. This reduces the probability of resource waste or channel crashes caused by fixed thresholds, effectively ensuring the continuity and stability of business.
[0057] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 5 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores multi-threaded message interaction management data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a multi-threaded message interaction management method.
[0058] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0059] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.
[0060] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.
[0061] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.
[0062] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.
[0063] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).
[0064] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.
[0065] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0066] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A multi-threaded message interaction management method, characterized in that, The multi-threaded message interaction management method includes: The middleware receives messages to be processed from various business scenarios and splits the messages to be processed according to business type, sending them to different queues of TopicA. Extract the first message from different queues of TopicA, split the first message according to the third-party channel type corresponding to different business messages, and send the split messages to different queues of TopicB. The second message is extracted from different queues of TopicB using a multi-threaded parallel approach, and then sent to the corresponding channel adaptation proxy; the channel adaptation proxy corresponds one-to-one with the third-party channel type. Send messages to the corresponding third-party channel through the channel adapter proxy; Monitor the message traffic sent by the channel adapter agent within a set time window, and determine whether the message traffic sent by each of the channel adapter agents within the set time window triggers rate limiting; If rate limiting is triggered, a message is sent to the corresponding delay queue through the channel adapter proxy; If rate limiting is not triggered, messages will continue to be sent to the corresponding third-party channel through the channel adapter proxy.
2. The multi-threaded message interaction management method according to claim 1, characterized in that, The monitoring of message traffic sent by the channel adapter proxies within a set time window, and the determination of whether the message traffic sent by each channel adapter proxies within the set time window triggers rate limiting, includes: Obtain the traffic thresholds for each third-party channel set by the rate limiting platform; The traffic threshold of each third-party channel is compared with the message traffic sent by the corresponding channel adapter within a set time window to determine whether rate limiting is triggered.
3. The multi-threaded message interaction management method according to claim 1, characterized in that, After sending a message to the corresponding delayed queue through the channel adaptation proxy, the method further includes: Set the delay time for messages in each delay queue using the ReSet mechanism; When the waiting time of a message in any delay queue is equal to the corresponding delay time, the message in the corresponding delay queue is sent to the corresponding TopicB queue and waits to be retrieved again in chronological order.
4. The multi-threaded message interaction management method according to claim 3, characterized in that, The method further includes: Monitor the number of message sending failures in each of the aforementioned delay queues; The delay time of each delay queue is dynamically adjusted based on the number of message sending failures in each delay queue to obtain the current delay time of each delay queue.
5. The multi-threaded message interaction management method according to claim 4, characterized in that, When the waiting time of a message in any delay queue is equal to the corresponding delay time, the message in the corresponding delay queue is sent to the corresponding TopicB queue, and waits to be retrieved again in chronological order, including: When the waiting time of a message in any delay queue is equal to the current delay time, the message in the corresponding delay queue is sent to the corresponding TopicB queue and waits to be retrieved again in chronological order.
6. The multi-threaded message interaction management method according to claim 1, characterized in that, The message middleware can be any one of RocketMQ, RabbitMQ, or Kafka.
7. A multi-threaded message interaction management device, characterized in that, The multi-threaded message interaction management device includes: The receiving and splitting module is used to receive messages to be processed in various business scenarios through middleware, and split the messages to be processed according to business type and send them to different queues of TopicA. The extraction and splitting module is used to extract the first message from different queues of TopicA, split the first message according to the third-party channel type corresponding to different business messages, and send the split messages to different queues of TopicB. The extraction and sending module is used to extract the second message from different queues of the TopicB in a multi-threaded parallel manner, and send the second message to the corresponding channel adaptation proxy; the channel adaptation proxy corresponds one-to-one with the third-party channel type; The first sending module is used to send messages to the corresponding third-party channel through the channel adapter proxy; The traffic monitoring module is used to monitor the message traffic sent by the channel adaptation agent within a set time window, and to determine whether the message traffic sent by each of the channel adaptation agents within the set time window triggers rate limiting. The second sending module is used to send a message to the corresponding delay queue through the channel adapter if rate limiting is triggered. The third sending module is used to continue sending messages to the corresponding third-party channel through the channel adapter proxy if rate limiting is not triggered.
8. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the steps of the multi-threaded message interaction management method according to any one of claims 1-6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the multi-threaded message interaction management method as described in any one of claims 1-6.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the multi-threaded message interaction management method as described in any one of claims 1-6.