Scheduled messages and delayed messages - Message Queue for Apache RocketMQ

Concepts

Scheduled message: A producer sends a message to the Message Queue for Apache RocketMQ broker, expecting the message to be delivered to a consumer at a specified time in the future. The message is a scheduled message.
Delayed message: A producer sends a message to the Message Queue for Apache RocketMQ broker, expecting the message to be delivered to a consumer after a specified 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 Message Queue for Apache 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.

Scenarios

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 the payment has been made. If the payment is not complete, the order is then closed. Otherwise, the consumer ignores the message.
Scheduled messages are sent to trigger scheduled tasks with messages. For example, a notification message is sent to a user at a specified time.

Usage

Scheduled messages and delayed messages have the following differences in terms of code:

For scheduled messages, a time point after the message sending time must be specified as the message delivery time.
For delayed messages, a delay duration must be specified and the message will be sent after the duration elapses.

Precautions

Scheduled messages have 1s to 2s latency.
For scheduled messages or delayed messages, the msg.setStartDeliverTime parameter must be set to a time point in 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 in milliseconds within 40 days. If it is set to a time point beyond 40 days, the message delivery will fail.
StartDeliverTime 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.

TCP sample code

The sample code for sending scheduled messages and delayed messages can be found in the following documentation:

HTTP sample code

The sample code for sending scheduled messages and delayed messages can be found in the following documentation: