1, the concept of queue persistence
The queue declaration is stored in memory by default. If rabbitmq is restarted, it will be lost. If you want to persist after restarting, you must make the queue persistent and save it in the Mnesia database that comes with Erlang. When rabbitmq is restarted, it will be read.
Simple Application Server
USD1.00 New User Coupon
* Only 3,000 coupons available.
* Each new user can only get one coupon(except users from distributors).
* The coupon is valid for 30 days from the date of receipt.
2. Exclusive
The simple understanding is whether the queue will be deleted when the connection is closed (regardless of whether there are messages in the queue)
3, automatic deletion
When there are messages in the queue, no matter whether it is exclusive or not, closing the connection will not delete the queue. At this time, when the consumer finishes consuming the message and then disconnects the consumer, the queue will be automatically deleted. (If there are multiple consumers consuming the same queue here, all consumers need to be disconnected before they can be deleted automatically)
4, the message confirmation mechanism Message acknowledgment
In actual applications, it may happen that the consumer receives the message in the Queue, but fails (or other accidents) before the processing is completed. In this case, the message may be lost. In order to avoid this situation, we can require consumers to send a receipt to RabbitMQ after consuming the message. RabbitMQ will only remove the message from the Queue after receiving the message acknowledgment; if RabbitMQ does not receive the receipt and Detecting that the consumer's RabbitMQ connection is disconnected, RabbitMQ will send the message to other consumers (if there are multiple consumers) for processing. There is no concept of timeout here. No matter how long a consumer processes a message, it will not cause the message to be sent to other consumers unless its RabbitMQ connection is disconnected. There will be another problem here. If our developers forget to send the receipt to RabbitMQ after processing the business logic, this will lead to serious bugs-more and more messages will accumulate in the Queue; after the consumer restarts Consume these messages repeatedly and execute business logic repeatedly... There is no ack for pub messages.
Once the message is received by the consumer, the message in the queue will be deleted. How does RabbitMQ know that the message has been received?
What if the consumer hangs up without performing any operation after receiving the message? Or an exception was thrown? Message consumption failed, but RabbitMQ has no way of knowing, so the message is lost!
Therefore, RabbitMQ has an ACK mechanism. When the consumer gets the message, it will send a receipt ACK to RabbitMQ to inform that the message has been received.
5, two situations of message ACK
Automatic ACK
Once the message is received, the consumer automatically sends an ACK. If the message is not important and loss has no effect, then automatic ACK will be more convenient
Manual ACK
After the message is received, no ACK will be sent, and it needs to be called manually. If the message is very important, it cannot be lost. Then it is best to manually ACK after the consumption is completed, otherwise it will automatically ACK after receiving the message, and RabbitMQ will delete the message from the queue. If the consumer is down at this time, then the message is lost.
Six, Rabbitmq consumption news mode
Rabbitmq's consumption mode is divided into two types: Push mode and Pull mode. Push mode uses Basic.Consume for consumption, and pull mode calls Basic.Get mode.
Push mode
mq actively pushes the message to the consumer (the consumer needs to provide a consumer interface)
The mq belongs to the active party, and the consumer belongs to a passive consumption. Once a message arrives at the mq, the mq push mechanism will be triggered to push the message to the consumer, regardless of the state of the consumer.
advantage:
Less consumer code: For consumers, they only need to provide a consumer interface to mq; mq will immediately push the received message to the designated consumer interface
The real-time message is relatively high: for consumers, once the message arrives at mq, mq will immediately push it to the consumer
Disadvantages:
Consumers are passive, and when the volume of messages is relatively large, they have higher performance requirements for consumers; if the consumer's machine resources are limited, it may cause stress overload and cause downtime.
The requirements for consumer availability are relatively high: when consumers are unavailable, it will cause very push failures, and the mq side needs to consider pushing successfully at least once.
Pull mode
The process of message consumption:
The consumer uses polling to pull messages from the mq service for consumption
Consumption complete notification mq deletes the message of successful consumption
Continue to pull news consumption
For consumers, it is the active party, which can use the thread pool method to increase or reduce the size of the thread pool according to the performance of the machine, control the speed of pulling messages, and control their own pressure well.
advantage:
Consumers can actively control the speed at which messages are pulled based on their own performance, control their pressure, and prevent themselves from overwhelming
Real-time performance is lower than that of push
Consumers are the active party and have greater control
Disadvantages:
Consumers need to implement the code to pull messages
When the consumption speed is slow, it may cause a backlog of messages in mq and delays in message consumption.
Seven, the best practice of consumption model
Consumers with better performance and high real-time requirements can use push
Consumer performance is limited, it is recommended to use the pull method
On the whole, it mainly depends on the performance of consumers. If there is no problem with the performance of the machine, both push and pull are possible.
