When using middleware for message delivery in the system, the most troublesome problem is that the message is lost. Although we know that middleware generally provides a mechanism for message persistence and message confirmation retry, but if it is to be combined with business functions , These are often not enough. Next, I will share with you how to ensure the reliability of messages in the systems I have contacted :
Architecture diagram to ensure message reliability
Train of thought
Combined with the above figure, let's understand the detailed processing flow
Introduction of involved components:
- Q1: Business message queue, monitored by business consumers
- Q2: After receiving the message, the consumer will send a confirmation message to this queue, which is monitored by the callback inspection service
- Q3: The queue that receives delayed messages is monitored by the callback inspection service to implement a timeout retry mechanism
- Producter: The producer of the message, which is our application
- DB: Including business database, producer message database, consumer message database
- Callback check service: confirm whether the message is consumed over time, if it times out, the producer will be notified to resend the message, otherwise the message will be written to the consumption message database
- Regular check service: By comparing the producer message database with the consumer database, compare those messages that have been sent but have not yet arrived in our consumer message database. If they exist, notify the producer to resend the message
Process explanation
-
Before our app, the producer of the message, sends a message, first save a copy of the message in the message database;
-
After storing the message in the database, the producer will send the message to two message queues respectively. The first is to immediately send the message to our business queue Q1, which will be monitored by business consumers, and the second is Send a delayed message to the Q3 queue and be monitored by the callback inspection service;
-
The business consumer listens to the message sent by the producer, and if the processing is successful, it sends a confirmation message to the Q2 queue, which is also monitored by the callback inspection service;
-
The processing process of the callback check service is like this:
- If a message from the Q2 queue is received, the message is directly saved to the consumer message database
- If a message from the Q3 delay queue is received, it will check whether there is a record of successful confirmation of the message consumption in the consumption message database. If there is, no processing will be done; if there is no record, it means that the message has not been recorded within the specified time. When the business consumer consumes, it will be treated as a message consumption timeout. At this time, the producer will be notified to resend the message to the queue;
-
The regular check service processing process is like this:
- By comparing the producer message database with the consumer message database, and then extract the data that does not exist in the consumer message database for further processing;
- Determine whether the interval between the message sending time and the current time is greater than our predetermined timeout limit, and then notify the producer of the timeout message to resend it to the queue for processing;
A search on WeChat [Le Zai talks] Follow the handsome me and reply [Receive dry goods], there will be a lot of interview materials and architect must-read books waiting for you to choose, including java basics, java concurrency, microservices, middleware, distribution More information on styles, concurrent programming, etc. is waiting for you.