This topic introduces the concepts, scenarios, and usage precautions of RocketMQ scheduled messages and delayed messages.
- Scheduled message: A producer sends a message to the RocketMQ broker, but intends the message to be postponed to reach the consumer at a certain time. The message is a scheduled message.
- Delayed message: A producer sends a message to the RocketMQ broker, but intends the message to be delayed in order to reach the consumer after a certain period of time. The message is a delayed message.
There are some coding differences between scheduled messages and delayed messages, but they have the same effect. Such messages will not be delivered immediately after they are sent to the RocketMQ broker, but will be delivered to the consumer after being delayed for a specific period of time, which is specified in the attributes of the message.
Scheduled messages and delayed messages apply to the following scenarios:
- When a time window is required for message production and consumption. For example, in e-commerce transactions, an order is closed after a payment timer times out. A delayed message is sent upon the creation of such an order. This message will be delivered to the corresponding consumer after 30 minutes. After receiving this message, the consumer needs to determine whether payment has been made. If the payment is not complete, the order is then closed. Otherwise, the consumer ignores the message.
- To trigger scheduled tasks with messages. For example, sending a notification message to a user at a specified time.
Scheduled messages and delayed messages have the following differences in terms of codes:
- For scheduled messages, a time point after the message sending time should be specified as the message delivery time.
- For delayed messages, a delay duration needs to be specified and the message will be sent after the duration elapses.
- For scheduled messages or delayed messages, the msg.setStartDeliverTime parameter needs to be set to a time point (unit: milliseconds) after the current timestamp. If the scheduled time is earlier than the current timestamp, the message is immediately delivered to the consumer.
- The msg.setStartDeliverTime parameter can be set to any time (unit: milliseconds) within 40 days. If it is set to a time point beyond 40 days, the message delivery will fail.
- The StartDeliverTime parameters specifies the time for the broker to start delivering the message to the consumer. If messages have been accumulated for the consumer, the scheduled message or delayed message will be queued after the accumulated messages, and will not be delivered according to the specified time exactly.
- Due to the potential time difference between the client and the broker, time differences might also occur between the actual delivery time and the delivery time set by the client.
- The 3-day message storage limit still applies for scheduled messages and delayed messages.For example, a message is scheduled to be consumed in 5 days. If it is not consumed after 5 days, the message will be deleted on the 8th day.
- Delayed messages are only supported for Java.
The sample code for sending scheduled messages and delayed messages can be found in the following documentation: