1. Message model
peer to peer
After a message producer sends a message to the message queue, it can only be consumed by one consumer once.
Publish/subscribe
After the message producer sends a message to the channel, multiple consumers can subscribe to the message from the channel and consume it.
The publish and subscribe model and the observer model have the following differences:
- In the observer mode, both the observer and the subject know the existence of each other; in the publish and subscribe mode, the producer and the consumer do not know the existence of each other, and they communicate through channels.
- The observer mode is synchronous. When the event is triggered, the topic will call the observer's method and then wait for the method to return; while the publish and subscribe mode is asynchronous. After the producer sends a message to the channel, it does not need to care about the consumer. When you go to subscribe to this news, you can return immediately.
Two, usage scenarios
Asynchronous processing
After the sender sends the message to the message queue, it does not need to wait for the message receiver to complete the processing, but immediately returns to perform other operations. The message receiver processes asynchronously after subscribing to the message from the message queue.
For example, in the registration process, it is usually necessary to send a verification email to ensure the legitimacy of the registered user's identity. You can use the message queue to make the operation of sending the verification email asynchronously processed. A message is sent to the message queue.
This can only be done when the business process allows asynchronous processing. For example, in the above registration process, if the user is required to click on the verification email to complete the registration, the message queue can no longer be used.
Traffic cut
In high concurrency scenarios, if a large number of requests arrive in a short time, the server will be overwhelmed.
The request can be sent to the message queue, and the server subscribes to the message from the message queue for processing according to its processing capacity.
Application decoupling
If the modules are not directly called, the coupling between the modules will be very low, so modifying a module or adding a new module will have little impact on other modules, thereby achieving scalability.
By using the message queue, one module only needs to send messages to the message queue, and other modules can selectively subscribe to messages from the message queue to complete the call.
Three, reliability
Reliability of the sender
After the sender completes the operation, the message must be successfully sent to the message queue.
Implementation method: Build a message table in the local database and store the message data and business data in the same database instance, so that the transaction mechanism of the local database can be used. After the transaction is submitted successfully, the message in the message table is transferred to the message queue. If the message is transferred successfully, the data in the message table is deleted, otherwise the retransmission is continued.
Reliability of the receiving end
The receiving end can successfully consume a message from the message queue.
Two implementation methods:
- Ensure that the business logic of the receiving end to process messages is idempotent: as long as it is idempotent, how many times the message is consumed, the final processing result is the same.
- Ensure that messages have a unique number, and use a log table to record the number of messages that have been consumed.