Exploration on the Implementation Principle of RocketMQ Delayed Messages
Exploration on the Implementation Principle of RocketMQ Delayed Messages
class=”markdown_views prism-atom-one-dark”> Since there are several scenarios of using delayed messages in daily development, and the message middleware used in business currently includes rabbitmq and kafka, the support for delayed messages is not ideal. where The rabbitmq delay message is realized by setting the queue ttl+dead letter exchange Disadvantages: You have to set up two queues every time, one is used to implement the delay, and after the expiration, it will be transferred to the corresponding business queue for consumption through the dead letter exchange. Another: rabbitmq provides a delay plugin, but there are many disadvantages, such as: 1. The startup plugin must either be restarted or introduce a new cluster; 2. It does not support high availability, and the delayed message is only stored in the current broker before sending In the internal database Mnesia of the node, it will not be mirrored and copied; 3. The delay is unreliable, there are a large number of messages or the delay is inaccurate after a long time of use; 4: Large-scale messages are not supported, same as 3; 5: Only ram nodes are supported (Mnesia database exists on disk) The kafka delayed message is implemented by judging whether the message…