Alibaba Cloud Simple Message Queue (SMQ, formerly MNS) is a distributed messaging service designed for scalability, high efficiency, reliability, security, and availability. SMQ enables developers to transfer data and notifications between distributed components within an application, helping to build loosely coupled systems. It supports both queue-based and topic-based messaging models.
Access methods
SMQ supports both Internet and Virtual Private Cloud (VPC) access. When using a VPC, you can configure the CIDR block, route table, and gateway, and access Alibaba Cloud resources such as Elastic Compute Service (ECS), ApsaraDB RDS, and Server Load Balancer (SLB) within your VPC.
Queue-based messaging model
A queue-based messaging model provides highly reliable and concurrent message consumption. In this model, each message in a queue can be consumed by only one client.
An SMQ queue can be compared to a conveyor belt sushi restaurant: chefs (producers) prepare sushi dishes (messages) and place them on the conveyor belt. Each dish (message) is unique, and customers (consumers) select and consume their preferred sushi dishes from the belt.
Queue-based message flow
The following figure, Queue-based message flow, illustrates the queue-based messaging process. In this flow, producers send messages to a queue, and consumers retrieve messages from the queue.
Figure 1. Queue-based message flow
Features of the queue-based messaging model
Multiple queue modes
Both standard queues and delayed queues are supported. Customize queue parameters to meet different business requirements.
Concurrent access requests
SMQ queues efficiently handle numerous concurrent requests from multiple producers and consumers. Once a message is pulled from a queue, it cannot be retrieved again within a specified period. You have the flexibility to adjust concurrency settings based on your workload.
Guaranteed message delivery
SMQ ensures that each message in a queue can be consumed at least once during its validity period. SMQ integrates with the Alibaba Cloud account system to isolate resources between users, ensuring that only authorized entities can access messages in SMQ queues.
Log management
You can view detailed logs for each message, including all records generated when a message is sent, received, or deleted throughout its lifecycle. For more information, see Log management.
Cloud Monitor
View queue information and customize alert rules in the Cloud Monitor console. Cloud Monitor will notify you of any unexpected issues. For more information, see Cloud Monitor.
Topic-based messaging model
A topic-based messaging model supports one-to-many publish-subscribe messaging. With SMQ topics, a single publisher can send messages to multiple subscribers, and messages can be delivered using multiple methods.
A topic can be likened to a newspaper to which multiple customers subscribe. When a new issue is released, subscribers (including the post office's partners) can choose how to receive it, for example:
Have a mail courier deliver the newspaper directly to a specific address, such as their home.
Pick up the newspaper themselves at a nearby newsstand, where the courier first delivers newspapers in bulk.
Topic-based message flow
As shown in a topic-based message flow:
A topic has multiple subscriptions that are specified with different queues.
After a message is published to the topic, the message is pushed to the queue endpoints that are specified in subscriptions.
Subscriptions support message filtering. You can specify a tag for a subscription to filter messages.
If you do not specify a tag for a subscription, messages are pushed to the specified queue no matter whether you specify message tags.
If you specify a tag for a subscription, only the messages that have the tag can be pushed to the specified queue.
Figure 2. Topic-based message flow
Features of the topic-based messaging model
Notification messages
The SMQ server pushes messages to specified queues. This eliminates unnecessary request polling and resource consumption of clients. You can maximize the resource usage to meet your business needs. You do not need to depend on other message service clients. This prevents system instability that is caused by excess code introduction. For more information, see Sign a request that is sent to an endpoint and Manage topics.
If a callback URL is not available due to network or other reasons, you can push messages to SMQ queues and retrieve messages from the queues. You can use queues to consume messages from topics. For more information, see Queue and Send messages from one producer client to multiple consumer clients.
One-to-many
A message that is published to a topic can be pushed to multiple subscriber clients.SMQ pushes messages to queues that are specified in subscriptions. After a message is published, the message is pushed to multiple endpoints. This ensures the atomicity of message publishing.
Tag-based message filtering
SMQ allows you to use tags to filter messages. You can specify a tag for a subscription and then receive only the messages that have the tag from the topic. SMQ pushes the message to the endpoint that is specified only when the tags are the same. For more information, see RESTful API operations about topics.
Message delivery
SMQ sends messages to queues. For more information, see Queue and Send messages from one producer client to multiple consumer clients.
Guaranteed message delivery: The messages that are published to a topic are automatically pushed to subscriber clients during the validity period based on specified retry policies and content formats. For more information, see NotifyStrategy.
Message formats
XML: The message is in XML format and contains the message body and message attributes.
JSON: The message is in JSON format and contains the message body and message attributes.
SIMPLIFIED: The message body is a message that is published by a user. It does not contain attribute information (this a simplified format, namely, text format). For more information, see:
Log management
Logs are generated when a message is published to a topic and then pushed to endpoints. The information about push retries and results are recorded in logs. You can use logs to view the lifecycle of the message. Log management allows you to troubleshoot issues with ease. For more information, see Log management.
Cloud Monitor
Cloud Monitor records messages that are pushed. If one or more messages fail to be pushed, Cloud Monitor allows you trace exceptions by creating alert rules. For more information, see Cloud Monitor.