Simple Message Queue (SMQ, formerly MNS) allows you to configure the delay period for a message or messages from a queue to be consumed. This topic describes common scenarios, effective rules, and methods of the delay features.
Scenarios
Scenario 1: Distributed timed scheduling
A distributed timed scheduling scenario involves tasks that require various time granularity levels. For example, a task to execute file cleanup at 5 o'clock every day and a task to trigger message push every 2 minutes. Traditional dataset-based timed scheduling solutions are complex and inefficient in distributed scenarios. In comparison, the delayed messages in SMQ allow you to encapsulate multiple types of time triggers.
Scenario 2: Task timeout processing
A typical scenario that involves task timeout processing is e-commerce payment, where an unpaid order is canceled after it remains unpaid for a specific time period instead of being canceled immediately. In this case, you can use delayed messages in SMQ to check and trigger timeout tasks.
Task timeout processing based on delayed messages provides the following benefits:
Various time granularity levels and simplified development: Delayed messages in SMQ do not have the limit of fixed time increments. You can trigger tasks at any time granularity level and without business deduplication.
High performance and scalability: Delayed messages in SMQ offer high concurrency and scalability. This outperforms traditional database scanning methods, which are complex to implement and can cause performance bottlenecks due to frequent API calls for scanning.
Description
SMQ provides queue-level and message-level delay features.
Queue-level delayed messages
When you create a queue, you can specify the DelaySeconds parameter. By default, all messages sent to the queue are consumed after the period that is specified by this parameter.
Unit: seconds.
Valid values: 0 to 604,800 seconds (0 second to 7 days).
Message-level delayed messages
When you create a message, you can specify the DelaySeconds parameter. The message is consumed after the period that is specified by this parameter.
Unit: seconds.
Valid values: 0 to 604,800 seconds (0 second to 7 days).
Effective rules
If the DelaySeconds parameter of a message is greater than 0, the message-level delay setting takes effect prior to the queue-level delay setting. In this case, if you configure the DelaySeconds parameter for a message, the configuration overwrites the queue-level delay setting.
The following table describes the effective rules:
Scenario | Message-level DelaySeconds parameter | Queue-level DelaySeconds parameter | Effective rules |
Scenario 1 | Greater than 0 | Greater than or equal to 0 | The message-level delay setting takes effect prior to the queue-level delay setting. For example, set the
|
Scenario 2 | Equal to 0 or empty | Greater than 0 | Messages are delivered based on the |
Lifecycle
Compared with normal messages, delayed messages contain a state of being scheduled:
Being scheduled: A message is sent to the broker but has not yet reached the end of its delay time. During this period, the message is in the scheduled state and is invisible to consumers.
Message visible: After the delay period ends, the message is visible and available to the consumers.
Message invisible: After a consumer receives a message, the message is in an invisible state. In this case, the message cannot be retrieved by other consumers.
Message deleted: After a consumer successfully consumes a message, the message can be deleted by calling deletion operation.
Metrics
You can configure metrics for the NumberOfMessagesDelayed parameter of the messages that are being scheduled in SMQ. For more information, see the Metrics section in the topic of Cloud Monitor.