Alibaba Cloud Message Service (MNS) is an efficient, reliable, secure, convenient, and scalable distributed messaging service. MNS allows developers to transfer data and notifications between the distributed components of an application and build a loosely coupled system. MNS provides queue-based MNS services and topic-based MNS services.

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 also use Alibaba Cloud resources, such as Elastic Compute Service (ECS), ApsaraDB for RDS (RDS), and Server Load Balancer (SLB) instances.

Queue-based MNS services

MNS queues provide one-to-one message consumption services. These services are highly reliable and concurrent. 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 figure Figure 1 shows the queue-based message flow. Application A (producer) delivers messages to a queue. Application B (consumer) pulls the messages from the queue.

Figure 1. Queue-based message flow
queuemodel

Benefits of queue-based MNS services

  • Multiple queue types

    Standard queues, delayed queues, and priority queues are supported. You can customize the parameters of a queue to meet various business needs.

  • A large number of concurrent access requests

    MNS queues support concurrent access requests from multiple producers and consumers. After a message is pulled from a queue, the message cannot be pulled again within a specified period of time. You can customize the limit of concurrent access requests based on business needs.

  • 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 transactions

    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.

  • Cloud Monitor

    You can view queue information in the Cloud Monitor console and customize alert rules. Then, Cloud Monitor sends notifications to you when an unexpected business issue occurs. For more information, see Cloud Monitor.

Topic-based MNS services

MNS topics are used to send messages from one publisher client to multiple subscriber clients. MNS topics support multiple message pushing methods.

A topic can be compared to a newspaper subscription service. When a new issue of the newspaper is released, customers (including the partners of the post office) can use 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.
  • Ask the post office to send the electronic version of the newspaper to a specified email address.
  • Ask the post office to send messages that include the newspaper content to your mobile phone.
  • Ask the post office to use the WebSocket API to push the electronic version of the newspaper to multiple clients.
  • Ask the news agency to use Alibaba Cloud Mobile Push to publish the electronic version of the newspaper on a mobile app.

Topic-based message flow

  • A topic has multiple subscriptions that are specified with different endpoints. These endpoints include HTTP servers, queues, and email addresses.
  • After a message is published to the topic, the message is pushed to the endpoints that are specified in subscriptions.
  • You can specify a filter tag for a subscription to filter messages.
    • If you do not specify a filter tag for a subscription, messages are pushed to the specified endpoint no matter whether you specify message tags.
    • If you specify a filter tag for a subscription, messages can be pushed to the specified endpoint only when you specify message tags.
Figure 2. Topic-based message flow
topicmodel

Benefits of topic-based MNS services

  • Notification messages
  • Broadcast messages
    • A message that is published to a topic can be pushed to multiple subscriber clients based on specified message pushing methods and endpoints. You can use multiple channels to receive the message.
    • 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. By specifying a tag for a subscription, you only receive messages with 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 specified endpoint that is specified only when the tags are the same. For more information, see Manage topics.

  • Multiple delivery methods

    MNS supports the following message delivery methods:

  • Guaranteed message delivery

    During the validity period of the message, the messages that are published to a topic are automatically pushed to subscriber clients based on specified retry policies and content formats. Retry policies include:

    • BACKOFF_RETRY
      • Specifies three retries.
      • The interval between two consecutive retries is a random value between 10 and 20 seconds.
    • EXPONENTIAL_DECAY_RETRY
      • Specifies 176 retries.
      • 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 at 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 text format. For more information, see the following topics:
  • Log management

    Log entries are generated when a message is published to a topic and pushed to endpoints. The information about pushing retries and results are recorded in log entries. You can use log entries to view the lifecycle of the message. Log management allows you to troubleshoot issues with ease. For more information, see Log management.

  • Cloud Monitor

    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, see Cloud Monitor.