A reliable message encapsulation method, device and medium based on RabbitMQ

Abstract

The application discloses a reliable message packaging method and device based on RabbitMQ and a medium, and comprises the following steps: persisting a message object into a message record in a delivery state and delivering to a message middleware; detecting routing failure of the message from an exchange to a queue through a routing failure callback, writing an unroutable mark in a shared mark container according to a message identifier in response to detecting the routing failure, and not updating the state of the message record; receiving an acknowledgement result returned by the message middleware through a producer acknowledgement callback, reading the unroutable mark from the shared mark container, updating the message record to a delivery success only when the acknowledgement is successful and the unroutable mark does not exist, otherwise, keeping the delivery in progress and determining a failure reason type; periodically scanning the message record in the delivery, determining a corresponding retry strategy according to the failure reason type and executing a compensation retry, which can avoid message state misupdate caused by semantic mixing of the routing failure callback and the acknowledgement callback, and realize differentiated compensation based on the failure reason.

Description

Technical Field

[0001] This invention relates to the field of distributed system communication technology, and specifically to a reliable message encapsulation method, device and medium based on RabbitMQ. Background Technology

[0002] With the development of microservice architecture and distributed systems, message middleware is widely used for asynchronous decoupling, event notification, peak shaving and valley filling, and distributed task processing. During message delivery, producers need to be aware of whether the message has successfully arrived at the message middleware and whether it has been successfully routed to the target queue in order to achieve accurate tracking of message status and anomaly compensation.

[0003] In existing technologies, message middleware typically provides two asynchronous callback mechanisms: a producer acknowledgment callback to indicate whether a message has reached the exchange, and a routing failure callback to indicate whether a message cannot be routed to the queue after reaching the exchange. However, the triggering timing and semantics of the two callbacks differ, and if not clearly distinguished, it can easily lead to erroneous updates to the message status. For example, if a message successfully reaches the exchange but cannot be routed to the queue, the producer acknowledgment callback returns a successful acknowledgment. If the message status is updated only based on the acknowledgment result, the message that actually failed to be delivered will be mistakenly marked as successfully delivered, causing the business system to believe that the message has been reliably delivered and stop compensation. In reality, the consumer will never be able to consume the message.

[0004] Furthermore, existing message compensation schemes typically employ fixed retry intervals and uniform retry strategies, without distinguishing between failure causes. In real-world scenarios, different types of failures, such as switch unreachability, routing misconfiguration, and acknowledgment timeout, exhibit different recovery characteristics: high-frequency retries when a switch is unreachable can exacerbate system load; retries cannot resolve routing misconfiguration issues and require maintenance intervention; and acknowledgment timeouts necessitate waiting for network recovery. Adopting a uniform fixed retry interval is not only inefficient but may also exacerbate system load due to high-frequency retries when a switch is unreachable.

[0005] Furthermore, existing compensation schemes typically scan messages according to their arrival order or identifier order, without distinguishing between messages based on their business importance. In scenarios with high message backlog, important business messages may not receive compensation for an extended period because they are ranked after lower-priority messages, impacting business continuity.

[0006] In addition, existing consumption failure handling typically involves either direct acknowledgment and discarding or re-enqueuing. Direct discarding prevents failed messages from self-healing, while re-enqueuing can cause failed messages to repeatedly return to the front of the queue, resulting in queue congestion. Summary of the Invention

[0007] This invention proposes a reliable message encapsulation method, device, and medium based on RabbitMQ to solve the problems mentioned in the background.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: A reliable message encapsulation method based on RabbitMQ according to the present invention includes the following steps: S1: Construct a message object and persist the message object as a message record with a status of delivery. The message object includes a message identifier, an exchange, a routing key, and a message type. S2: Deliver the message object to the message middleware, and generate confirmation association data containing the message identifier and the message type during delivery; S3: Detect the routing failure of the message object from the exchange to the queue through the routing failure callback. In response to the detection of routing failure, write an unroutable flag in the shared flag container according to the message identifier, and do not update the status of the message record. S4: Receive the confirmation result returned by the message middleware through the producer confirmation callback, and determine the failure reason type based on the confirmation result and the detection result of the unroutable flag; S5: Periodically scan message records that are in delivery and have reached the retry time, determine the corresponding retry strategy according to the failure reason type, and perform compensated resubmission according to the retry strategy.

[0009] Preferably, S4 includes: The producer confirms the callback to receive the confirmation result returned by the message middleware, reads the unroutable tag corresponding to the message identifier from the shared tag container, and updates the message record to delivery success only if the confirmation result is successful and the unroutable tag does not exist; if the confirmation result is unsuccessful or the unroutable tag exists, the message record is kept as being delivered, and the failure reason type is determined according to the confirmation result and the detection result of the unroutable tag.

[0010] Preferably, the shared tag container is a concurrent-safe key-value pair container; the routing failure callback writes the unroutable tag with the message identifier as the key, and the producer confirmation callback reads and removes the unroutable tag with the message identifier as the key; the execution timing of the routing failure callback precedes the execution timing of the producer confirmation callback.

[0011] Preferably, the failure reason types include switch confirmation failure type, unroutable type, and confirmation timeout type; wherein, the switch confirmation failure type corresponds to the confirmation result being confirmation failure, the unroutable type corresponds to the existence of the unroutable flag, and the confirmation timeout type corresponds to the confirmation result not being received from the producer confirmation callback within a preset confirmation timeout period; The step of determining the corresponding retry strategy based on the failure reason type includes: For the failure type of the switch confirmation, an exponential backoff strategy is used to determine the next retry time. The next retry time is calculated based on the current time, the base interval and the number of retries, wherein the next retry interval increases exponentially with the number of retries. For the unroutable type, a fixed interval strategy is used to determine the next retry time and trigger a routing configuration alarm. For the confirmation timeout type, a linear backoff strategy is used to determine the next retry time. The next retry time is calculated based on the current time, the base interval, and the number of retries, wherein the next retry interval increases linearly with the number of retries.

[0012] Preferably, the confirmation association data further includes a company code and a tracing identifier; after the producer confirmation callback parses the confirmation association data, it performs dynamic data source routing based on the company code and sets the tracing identifier to the log context.

[0013] Preferably, the message object further includes a priority field; the message records that are periodically scanned and whose delivery status has reached the retry time include: sorting the message records according to the priority field, prioritizing the scanning of high-priority message records and performing compensation redelivery.

[0014] Preferably, the method further includes: When message consumption fails, the failed message is delivered to a dead-letter queue with a timeout. Messages in the dead-letter queue are routed to the delayed retransmission queue via the dead-letter switch after their lifespan expires. When the number of compensation retry attempts reaches the preset maximum number of retries, the message record will be updated to "delivery failed" and transferred to the manual diagnosis queue.

[0015] Preferably, the method further includes: After successful consumption, if the consumer is the producer that sent the message, the message record will be updated to indicate successful consumption. Otherwise, a feedback message is constructed and sent to the feedback queue, and the feedback consumer updates the original message record to "consumption successful" based on the feedback message.

[0016] In another aspect, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0017] In another aspect, the present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.

[0018] As can be seen from the above technical solution, the present invention provides a reliable message encapsulation method based on RabbitMQ. Compared with the prior art, the present invention has the following advantages: 1. This invention, through a joint determination mechanism of routing failure callbacks and producer confirmation callbacks, avoids the problem of erroneously updating message status based solely on a single callback result. The routing failure callback only writes an unroutable flag without directly updating the message status, while the producer confirmation callback combines the confirmation result and the unroutable flag for unified determination, ensuring that a message is only marked as successfully delivered when it has both arrived at the exchange and been successfully routed to the queue. Furthermore, by determining the failure reason type during the callback process and adopting differentiated retry strategies based on the failure reason type, compensation efficiency can be improved and system load aggravation caused by a uniform retry interval can be avoided.

[0019] 2. This invention implements the writing and reading of unroutable markers through a concurrent and safe key-value pair container, and removes the markers after reading to avoid residual markers affecting subsequent delivery judgments; the timing guarantee that the routing failure callback is executed before the producer confirmation callback ensures that the producer confirmation callback can accurately detect routing failure events.

[0020] 3. This invention drives the sorting of compensation scans through a priority field, so that high-priority business messages are compensated first in backlog scenarios, avoiding important business messages from being delayed for a long time because they are ranked after low-priority messages.

[0021] 4. This invention employs differentiated backoff strategies for different failure causes: exponential backoff is used when the switch is unreachable to quickly reduce the retry frequency and avoid exacerbating system load; fixed intervals are used and alarms are triggered when routing is misconfigured to prompt maintenance intervention; linear backoff is used when a timeout is confirmed to appropriately increase the waiting time; compared with a uniform fixed interval compensation scheme, this differentiated strategy can improve compensation efficiency and reduce the waste of system resources caused by invalid retries.

[0022] 5. This invention achieves delayed retransmission of failed messages by limiting the lifespan of the dead-letter queue, avoiding immediate re-enqueuing of failed messages and causing queue blockage; after exceeding the maximum number of retries, messages are transferred to the manual diagnosis queue instead of being directly marked as failed, enabling maintenance personnel to perform root cause analysis on continuously failing messages before deciding whether to retransmit or archive them. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating a reliable message encapsulation method based on RabbitMQ according to the present invention.

[0024] Figure 2 This is a flowchart of the failure cause classification and adaptive compensation process in this invention.

[0025] Figure 3 This is a flowchart of the priority compensation scanning process in this invention.

[0026] Figure 4 This is a flowchart of the multi-level isolation process for dead-letter queues in this invention.

[0027] Figure 5 This is a flowchart of the successful consumption feedback process in this invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.

[0029] like Figure 1 As shown in this embodiment, a reliable message encapsulation method based on RabbitMQ includes the following steps: S1: Construct a message object and persist the message object as a message record with a status of delivery. The message object includes a message identifier, an exchange, a routing key, and a message type. S2: Deliver the message object to the message middleware, and generate confirmation association data containing the message identifier and the message type during delivery; S3: Detect the routing failure of the message object from the exchange to the queue through the routing failure callback. In response to the detection of routing failure, write an unroutable flag in the shared flag container according to the message identifier, and do not update the status of the message record. S4: Receive the confirmation result returned by the message middleware through the producer confirmation callback, and determine the failure reason type based on the confirmation result and the detection result of the unroutable flag; S5: Periodically scan message records that are in delivery and have reached the retry time, determine the corresponding retry strategy according to the failure reason type, and perform compensated resubmission according to the retry strategy.

[0030] In this embodiment, the unified message object includes the following attributes: messageId, a globally unique identifier used for associating persistent records, confirming associated data, and determining callbacks; exchange, the name of the message target exchange; routingKey, the message routing key; message body, the business data payload; version number, used for optimistic locking to control concurrent updates; message type, including ordinary acknowledgment messages (CONFIRM) and reliable messages (RELIANT); priority, the message priority used to compensate for scan sorting; companyCode, the tenant identifier in multi-tenant scenarios; traceId, used for end-to-end trace tracing; userId, the business user identifier that triggered the message; and connectionKey, the connection identifier in multi-message middleware connection scenarios.

[0031] The message builder executes the following logic when constructing a message: It throws an exception if no exchange is provided, ensuring the message has a clearly defined target exchange; if no message identifier is provided, it generates a unique identifier using a global identifier generator; if no version number is provided, it is set to 1; if no priority is provided, it is set to the default priority; if no company code and user identifier are provided, they are inferred from the current request context. This message model allows sending, callback determination, and compensation retransmission to all be performed based on the same message identifier.

[0032] Message types include ordinary acknowledgment messages (CONFIRM) and reliable messages (RELIANT). For ordinary acknowledgment messages, the system only performs delivery and producer acknowledgment, and does not establish persistent records for status tracking and automatic compensation. For reliable messages, the system saves the message as a persistent record with a status of "DELIVERING" before the first delivery, and enables joint determination by dual callbacks, failure reason classification, adaptive compensation, and consumption success feedback.

[0033] Specifically, the joint determination process of dual callbacks may include the following steps: First, after a reliable message is stored in the database, the message object is delivered to the message middleware through the unified producer interface. During delivery, acknowledgment data is constructed, with the following format: message identifier#message type#connection identifier#switch#routing key#version number#user identifier#company code#traceability identifier. This acknowledgment data is encoded as a string in the acknowledgment data object, enabling the producer's acknowledgment callback to restore all the context required for message state updates in an asynchronous thread.

[0034] Then, when a message cannot be routed from the exchange to the queue, the message middleware triggers a routing failure callback. The routing failure callback performs the following operations: records the exchange name, routing key, reply code, and reply text; deserializes the returned message to obtain the message identifier; and writes an unroutable tag into the shared tag container using the message identifier as the key.

[0035] It is important to emphasize that the routing failure callback does not directly update the state of the message persistence record; the message record remains in the process of being delivered (DELIVERING). If the routing failure callback directly updates the message state to failure, the message state will have already been overwritten with failure by the time the producer confirmation callback returns a success confirmation, making a unified judgment impossible. Conversely, if the producer confirmation callback executes before the routing failure callback, it may be mistakenly judged as successful delivery because the routing failure was not detected. By only writing a flag without updating the state, the final judgment is uniformly delegated to the producer confirmation callback.

[0036] Then, the message middleware triggers a producer acknowledgment callback after the message arrives or fails to arrive at the exchange. The producer acknowledgment callback performs the following operations: parses the acknowledgment associated data, restores the context such as message identifier, message type, company code, and tracing identifier; and reads and removes unroutable tags from the shared tag container using the message identifier as the key.

[0037] The producer confirms the callback for joint judgment; only when the confirmation result is successful (ack=true) and there is no unroutable flag, is the delivery considered successful and the message record is updated to successful delivery (DELIVER_SUCCESS); when the confirmation result is unsuccessful (ack=false), it is determined to be a failure type of the switch confirmation, the reason for failure is recorded, and the message record is kept in delivery; when there is an unroutable flag, it is determined to be an unroutable type, the reason for failure is recorded, and the message record is kept in delivery.

[0038] After the above determination is completed, the tag corresponding to the message identifier is removed from the shared tag container to avoid residual tags affecting subsequent delivery determination.

[0039] It should be noted that the triggering order of the routing failure callback and the producer acknowledgment callback is deterministic: the routing failure callback is triggered only when a message arrives at the exchange but cannot be routed to the queue, and its triggering time must precede or be equal to the corresponding producer acknowledgment callback. Therefore, when the producer acknowledgment callback is executed, if a routing failure has occurred, the corresponding unroutable flag must already exist in the shared flag container; this timing guarantee is the basis for the correctness of the joint determination mechanism.

[0040] In addition, for confirmation timeout scenarios, where no confirmation result is received from the producer's confirmation callback within the preset confirmation timeout period, the message record is still being delivered; this scenario is captured by periodic compensation scanning, and the failure reason is determined to be the confirmation timeout type during scanning.

[0041] This invention employs a timing coordination mechanism that pre-writes an unroutable flag in the routing failure callback and makes a unified judgment after the producer confirms the flag. This ensures that a message is marked as successfully delivered only when it both arrives at the exchange and is successfully routed to the queue.

[0042] like Figure 2 As shown, this embodiment further classifies and differentiates the reasons for failure based on the joint determination of dual callbacks.

[0043] The reasons for failure fall into three categories: The acknowledgment failure type (BROKER_UNREACHABLE) corresponds to an acknowledgment failure (ack=false), indicating that the message did not reach the switch. This is usually caused by the message middleware being unreachable or the switch not existing.

[0044] Unroutable type: This corresponds to the presence of an unroutable flag, indicating that the message arrives at the exchange but cannot be routed to any queue. This is usually caused by incorrect routing key configuration or missing queue binding.

[0045] Confirmation timeout type (CONFIRM_TIMEOUT): This corresponds to the failure to receive a confirmation callback from the producer within the preset confirmation timeout period, which is usually caused by network partitioning or excessive load on the message middleware.

[0046] Differentiated retry strategies are adopted for the three types of failure reasons: For switch confirmation failure types, an exponential backoff strategy is used to determine the next retry time.

[0047] Specifically, the next retry interval = base interval × 2^(number of retries - 1), and the next retry time = current time + next retry interval; for example, when the base interval is 1 minute, the first retry interval is 1 minute, the second is 2 minutes, the third is 4 minutes, and the fourth is 8 minutes; this strategy can quickly reduce the retry frequency and avoid increasing the system load due to high-frequency retries when the message middleware is unreachable.

[0048] For unroutable types, a fixed interval strategy is used to determine the next retry time and trigger a routing configuration alarm. Since routing configuration errors usually require maintenance intervention to fix, a fixed interval, such as 5 minutes, is used to retry, and maintenance personnel are notified to check the routing configuration through an alarm channel. The alarm channel includes, but is not limited to, SMS, email and instant messaging tools.

[0049] For confirmation timeout types, a linear backoff strategy is used to determine the next retry time.

[0050] Specifically, the next retry interval = base interval × number of retries, and the next retry time = current time + next retry interval; for example, when the base interval is 2 minutes, the first retry interval is 2 minutes, the second is 4 minutes, and the third is 6 minutes; this strategy appropriately increases the waiting time to adapt to the uncertainty of network partition recovery.

[0051] During compensation resubmission, the corresponding retry strategy parameters are queried based on the failure reason type field stored in the message record, the next retry time is calculated, and the retry count, next retry time, and version number of the message record are updated. Compensation resubmission is executed by reconstructing the message object and calling the unified producer interface, and the version number of the resubmitted message is set to the original version number plus 1.

[0052] It is understood that the differentiated backoff strategy of this invention draws on the exponential backoff concept in TCP congestion control and the half-open probe mode in microservice circuit breakers; for switch unreachable failures, exponential backoff is similar to window reduction in the TCP congestion avoidance phase; for routing configuration error failures, triggering alarms and reducing the retry frequency is similar to the open state of a circuit breaker; for acknowledgment timeout failures, linear backoff provides a recovery strategy between exponential backoff and fixed intervals.

[0053] like Figure 3 As shown, this embodiment introduces a priority sorting mechanism in the compensation scan.

[0054] The periodic compensation scan task is triggered every 30 seconds by default. During the scan, message records with a status of DELIVERING and a next retry time less than or equal to the current time are queried. The scan query is sorted in descending order by the priority field so that high-priority message records are ranked at the top of the query results and are given priority for compensation re-delivery.

[0055] In one possible implementation, the priority field includes three levels: HIGH, NORMAL, and LOW. High-priority messages correspond to core business scenarios, such as order creation and payment notifications; medium-priority messages correspond to general business scenarios, such as status synchronization and log recording; and low-priority messages correspond to non-critical scenarios, such as statistical reporting and cache refresh. In scenarios with high message backlog, the compensation delay for high-priority messages is significantly lower than that for low-priority messages, ensuring the timely processing of core business messages.

[0056] In addition, in multi-instance deployment scenarios, the compensation scan avoids repeated execution through a distributed lock; after acquiring the distributed lock, when a dynamic data source router exists, it traverses multiple company codes and performs a compensation scan database by database, and the scans within each database are also sorted by the priority field.

[0057] like Figure 4 As shown, this embodiment provides a multi-level isolation mechanism for consumption failure messages, including: S501: When message consumption fails, instead of directly returning an acknowledgment response to the message middleware to re-enqueue the message, the failed message is delivered to a dead-letter queue with a time-to-live (TTL). The TTL of the dead-letter queue is dynamically set according to the message priority and the type of failure reason: high-priority messages have shorter TTLs, such as 30 seconds, while low-priority messages have longer TTLs, such as 5 minutes.

[0058] In S502, messages in the dead-letter queue are automatically routed to the delayed redelivery queue via the dead-letter switch after their TTL expires. Consumers in the delayed redelivery queue process the message according to the normal consumption process.

[0059] S503: When the number of compensation retry attempts reaches the preset maximum number of retries, the message record is not directly marked as a delivery failure. Instead, the message is transferred to the manual diagnosis queue. The messages in the manual diagnosis queue wait for maintenance personnel to perform root cause analysis through the management interface and decide whether to retry or archive them based on the analysis results.

[0060] This multi-level isolation mechanism isolates failed messages from the normal consumption queue to the dead-letter queue, preventing repeated re-enqueueing of failed messages and causing queue blockage; through manual queue diagnosis, it enables root cause analysis of continuously failing messages rather than simply discarding them.

[0061] like Figure 5 As shown, this embodiment implements end-to-end consumption status tracking, including: After successful consumption, two paths are selected based on whether the consumer is the producer who sent the message: If the consumer is the producer itself, meaning the same service both sends and consumes messages, then the message persistence record is directly updated to "consumption successful" (CONSUMED_SUCCESS).

[0062] If the consumer is for another service, a feedback message is constructed. This message carries the original message identifier, the original request context, and the original connection identifier. The switch and routing keys are appended with the ".feedback" suffix before being sent to the feedback queue. The feedback consumer consumes the message from the feedback queue and updates the message record to "consumption successful" (CONSUMED_SUCCESS) according to the original message identifier.

[0063] This mechanism advances the message status from "sent to message middleware" (DELIVER_SUCCESS) to "consumed by business" (CONSUMED_SUCCESS), forming an end-to-end observable state. This invention enables producers to perceive the message consumption completion status through a feedback queue mechanism.

[0064] In multi-tenant or sharded database scenarios, message confirmation callbacks are typically executed in an asynchronous thread, isolated from the context of the message sending thread. If the tenant context cannot be restored in the callback, it may lead to data source routing errors.

[0065] In this embodiment, the associated data is confirmed to be encoded as a company code (companyCode) and a trace identifier (traceId) in string form. After the producer confirms the associated data through callback parsing, it constructs a request context based on the company code and sets it to the context holder of the current thread. The trace identifier is set to the log context so that the logs during the callback process can be associated with the logs during the message sending phase through the same trace identifier, forming a complete trace. If a dynamic data source router exists, the data source routing is performed based on the company code, and the corresponding database is switched to perform the message status update operation.

[0066] After acquiring the distributed lock, if a dynamic data source router exists, the compensation scan iterates through all company code lists, switches data sources one by one, and performs a compensation scan to ensure that all messages awaiting compensation in each database are scanned.

[0067] The main states of a message log include: "Delivering" means "delivering". A status value of 0 indicates that the reliable message has been stored in the database and is in the state of pending delivery, delivery in progress, or waiting for confirmation.

[0068] Successful delivery is indicated by DELIVER_SUCCESS, with a status value of 1: the producer confirmation callback returns a successful confirmation and there is no unroutable flag.

[0069] Delivery failure is DELIVER_FAIL, status value 2: If the delivery still fails after the maximum number of retries has been reached, it will be transferred to the manual diagnosis queue.

[0070] Consumption success is indicated by CONSUMED_SUCCESS, with a status value of 3: the transaction was successfully completed, or the consumer was notified that the transaction was successful.

[0071] Consumption failure is indicated by CONSUME_FAILED, status value 4: business consumption failed and was recorded.

[0072] The state transition paths are as follows: from delivery in progress to delivery success and then to consumption success (normal path); from delivery in progress to delivery in progress (compensation re-delivery); from delivery in progress to delivery failure (exceeding the maximum number of retries); from delivery success to consumption success (consumption success feedback); and from delivery success to consumption failure (consumption failure).

[0073] In another aspect, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0074] In another aspect, the present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.

[0075] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk).

[0076] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0077] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0078] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A reliable message encapsulation method based on RabbitMQ, characterized in that, Includes the following steps: S1: Construct a message object and persist the message object as a message record with a status of delivery. The message object includes a message identifier, an exchange, a routing key, and a message type. S2: Deliver the message object to the message middleware, and generate confirmation association data containing the message identifier and the message type during delivery; S3: Detect the routing failure of the message object from the exchange to the queue through the routing failure callback. In response to the detection of routing failure, write an unroutable flag in the shared flag container according to the message identifier, and do not update the status of the message record. S4: Receive the confirmation result returned by the message middleware through the producer confirmation callback, and determine the failure reason type based on the confirmation result and the detection result of the unroutable flag; S5: Periodically scan message records that are in delivery and have reached the retry time, determine the corresponding retry strategy according to the failure reason type, and perform compensated resubmission according to the retry strategy.

2. The reliable message encapsulation method based on RabbitMQ according to claim 1, characterized in that: S4 includes: The producer confirms the callback to receive the confirmation result returned by the message middleware, reads the unroutable tag corresponding to the message identifier from the shared tag container, and updates the message record to delivery success only if the confirmation result is successful and the unroutable tag does not exist; if the confirmation result is unsuccessful or the unroutable tag exists, the message record is kept as being delivered, and the failure reason type is determined according to the confirmation result and the detection result of the unroutable tag.

3. The reliable message encapsulation method based on RabbitMQ according to claim 1, characterized in that: The shared tag container is a concurrent-safe key-value pair container; the routing failure callback writes the unroutable tag with the message identifier as the key, and the producer confirmation callback reads and removes the unroutable tag with the message identifier as the key; The execution timing of the routing failure callback precedes the execution timing of the producer confirmation callback.

4. The reliable message encapsulation method based on RabbitMQ according to claim 1, characterized in that: The failure reason types include switch confirmation failure type, unroutable type, and confirmation timeout type; wherein, the switch confirmation failure type corresponds to the confirmation result being confirmation failure, the unroutable type corresponds to the existence of the unroutable flag, and the confirmation timeout type corresponds to the confirmation result not being received from the producer confirmation callback within a preset confirmation timeout period; The step of determining the corresponding retry strategy based on the failure reason type includes: For the failure type of the switch confirmation, an exponential backoff strategy is used to determine the next retry time. The next retry time is calculated based on the current time, the base interval and the number of retries, wherein the next retry interval increases exponentially with the number of retries. For the unroutable type, a fixed interval strategy is used to determine the next retry time and trigger a routing configuration alarm. For the confirmation timeout type, a linear backoff strategy is used to determine the next retry time. The next retry time is calculated based on the current time, the base interval, and the number of retries, wherein the next retry interval increases linearly with the number of retries.

5. A reliable message encapsulation method based on RabbitMQ according to claim 1, characterized in that: The confirmation association data also includes a company code and a tracing identifier; after the producer confirmation callback parses the confirmation association data, it performs dynamic data source routing based on the company code and sets the tracing identifier to the log context.

6. The reliable message encapsulation method based on RabbitMQ according to claim 1, characterized in that: The message object also includes a priority field; the message records that are periodically scanned and whose delivery status has reached the retry time include: sorting the message records according to the priority field, scanning the message records with higher priority first and performing compensation redelivery.

7. A reliable message encapsulation method based on RabbitMQ according to claim 1, characterized in that: The method further includes: When message consumption fails, the failed message is delivered to a dead-letter queue with a timeout. Messages in the dead-letter queue are routed to the delayed retransmission queue via the dead-letter switch after their lifespan expires. When the number of compensation retry attempts reaches the preset maximum number of retries, the message record will be updated to "delivery failed" and transferred to the manual diagnosis queue.

8. A reliable message encapsulation method based on RabbitMQ according to claim 1, characterized in that: The method further includes: After successful consumption, if the consumer is the producer that sent the message, the message record will be updated to indicate successful consumption. Otherwise, a feedback message is constructed and sent to the feedback queue, and the feedback consumer updates the original message record to "consumption successful" based on the feedback message.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of the method as described in any one of claims 1 to 8.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the computer program is executed by the processor, it causes the processor to perform the steps of the method as described in any one of claims 1 to 8.

Images