Alibaba Cloud MNS is a distributed messaging service that provides scalability, high efficiency, reliability, security, and availability. MNS allows developers to transfer data and notifications between the distributed components of an application and build a loosely coupled system. MNS provides a queue-based messaging model and a topic-based messaging model.
Access methods
MNS supports access from the Internet and Virtual Private Cloud (VPC). If you select VPC as the network type, you can configure the CIDR block, route table, and gateway of your VPC. In your VPC, you can use Alibaba Cloud resources, such as Elastic Compute Service (ECS), ApsaraDB RDS, and Server Load Balancer (SLB) instances.
Queue-based messaging model
A queue-based messaging model provides highly reliable and concurrent message consumption services. Each message in a queue can be consumed by only one client.
An MNS queue can be compared to a conveyor belt sushi restaurant. Chefs (producers) produce sushi dishes (messages) and put them on the conveyor belt. Each sushi dish is unique. Customers (consumers) can take (consume) their favorite sushi dishes from the conveyor belt.
Queue-based message flow
The below figure 'Queue-based message flow' illustrates the process of queue-based messaging. In this flow, Application A (producer) sends messages to a queue, while Application B (consumer) retrieves the messages from the queue.
Figure 1. Queue-based message flow
Features of the queue-based messaging model
Multiple queue types
Standard queues and delayed queues are supported. You can customize the parameters of a queue to meet various business needs.
Concurrent access requests
MNS queues can process a large number of concurrent requests from multiple producers and consumers. Once a message is pulled from a queue, it cannot be retrieved again within a specified period.
Guaranteed message delivery
MNS ensures that a message in a queue can be consumed at least once during the validity period of the message. MNS is integrated into the Alibaba Cloud account system in which resources are isolated between users. This ensures that only authorized entities can retrieve your messages in MNS queues.
Distributed transactional messages
MNS queues provide an efficient solution to process distributed transactional messages.
Log management
You can view the log of each message. The log includes all records that are generated when you send, receive, and delete the message during its lifecycle. Log management allows you to troubleshoot issues with ease. For more information, see Log management.
CloudMonitor
You can view queue information in the CloudMonitor console and customize alert rules. Then, CloudMonitor sends notifications to you if an unexpected issue occurs. For more information, visit the product page of CloudMonitor.
Topic-based messaging model
A topic-based messaging model is used to send messages from one publisher client to multiple subscriber clients. MNS topics can be pushed as messages by using multiple methods.
A topic can be compared to a newspaper to which multiple customers subscribe. When a new issue of the newspaper is released, customers (including the partners of the post office) can select one of the following methods to receive the newspaper:
Ask a mail courier to deliver the newspaper to a specific address, such as your house.
Go to the nearest newsstand to which a mail courier delivers the newspaper.
Topic-based message flow
The figure Topic-based message flow shows the 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 endpoints that are specified in subscriptions.
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 same tag can be pushed to the specified queue.
Figure 2. Topic-based message flow
Features of the topic-based messaging model
Notification messages
MNS 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 excessive code introduction. For more information, see the following topics:
If you do not want to provide callback URLs, you can push messages to MNS queues and retrieve messages from the queues. You can use queues to consume messages from topics. For more information, see the following topics:
Broadcast messages
A message that is published to a topic can be pushed to multiple subscriber clients based on specified methods and endpoints. MNS 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
MNS 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 same tag from the topic. If you specify a tag for a subscription, you can specify a tag for a message when you call the PublishMessage operation. Then, MNS pushes the message to the endpoint that is specified only when the tags are the same. For more information, see Topic-related APIs.
Message delivery
MNS supports pushing messages to queues.
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. Retry policies include:
BACKOFF_RETRY
Retries three times.
The interval between two consecutive retries is a random value between 10 and 20 seconds.
EXPONENTIAL_DECAY_RETRY
Retries 176 times.
All these retries are completed within one day.
The interval between two consecutive retries exponentially increases to a maximum of 512 seconds. For example, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 512... 512 (The number 512 is used for 167 retries).
Message content formats include:
XML: The request body contains the message content and the message parameters.
JSON: The request body contains the message content and the message parameters.
SIMPLIFIED: The request body contains only the message content in the text format. For more information, see the following topics:
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.
CloudMonitor
You can monitor the message pushing in the Cloud Monitor console. If a large number of messages fail to be pushed, you can customize alert rules to send notifications to specified recipients. For more information, visit the product page of CloudMonitor.