- Alibaba Cloud Message Service (Message Service) is an auto scalable and distributed message service featuring efficiency, reliability, security, and convenience.
- Message Service helps application developers transfer data freely on distributed components of their applications to build a loosely coupled system.
Typical application scenarios:
- Integrate Message Service with other Alibaba Cloud products, making applications more reliable and flexible.
- Use Message Service as a working queue. Each message in the queue represents one task and must be completed in one process. One or multiple ECSs can read and execute tasks from the queue.
- Store notifications of major events in service processes. Each event has one corresponding message in the queue. The application that needs to acquire the event can read and process the corresponding message.
As Alibaba Cloud services develop, products are launched in more regions. To regulate naming and adapt for international development, regions for Alibaba Cloud products were renamed on March 29, 2016. The following table lists the old and new region names.
|Old name||New name||English name|
|Qingdao||China North 1||North China 1|
|Beijing||China North 2||North China 2|
|Hangzhou||China East 1||East China 1|
|Shanghai||China East 2||East China 2|
|Shenzhen||China South 1||South China 1|
To help protect your data security, Message Service provides HTTPS interfaces on the public network. You only need to change
http:// of the public access address to
The account ID is provided when a user registers at Alibaba Cloud, which can be viewed at Alibaba Cloud’s website.
The following table lists operation commands supported by the Message Service queue model.
|CreateQueue||Creates a new message queue.|
|SetQueueAttributes||Modifies the attributes of a queue.|
|GetQueueAttributes||Obtains the attributes of a queue.|
|DeleteQueue||Deletes a queue.|
|ListQueue||Lists the queue lists under a user name.|
|SendMessage||The producer sends messages to a specified queue.|
|BatchSendMessage||The producer sends messages in batch to a specified queue.|
|ReceiveMessage||The consumer consumes messages in a queue.|
|BatchReceiveMessage||The consumer consumes messages in batch in a queue.|
|DeleteMessage||Deletes a message that has been consumed.|
|BatchDeleteMessage||Deletes messages that have been consumed in batch.|
|PeekMessage||The consumer views a message in a queue.|
|BatchPeekMessage||The consumer views messages in a queue in batch.|
|ChangeMessageVisibility||Modifies the next consumable time of a message that has been consumed and is now inactive.|
The following table lists operation commands supported by the Message Service topic model.
|CreateTopic||Creates a new topic.|
|SetTopicAttributes||Modifies the attributes of a topic.|
|GetTopicAttributes||Obtains the attributes of a topic.|
|DeleteTopic||Deletes a topic.|
|ListTopic||Lists the topic lists under a user name.|
|Subscribe||Subscribes to a topic.|
|SetSubscriptionAttributes||Modifies the attributes of a subscription.|
|GetSubscriptionAttributes||Obtains the attributes of a subscription.|
|Unsubscribe||Cancels a subscribed topic.|
|ListSubscriptionByTopic||Lists the subscription lists of a topic.|
|PublishMessage||Publishes a message to a topic.|
What are the advantages of Message Service over self-developed, commercial, or open source message queue systems?
Compared with systems built to manage message queues or using a commercial or open source message and notification service, Message Service has the following advantages:
- There is no need of large investments in development and configuration at the early stage.
- There is no need to consecutively engage hardware and management resources with the increase of your service volume.
- Redundant message storage is implemented by default, ensuring that messages are not lost as a result of hardware failure, and making system investment, development, configuration, and deployment easier.
- There is no need to input deployment and maintenance resources for the message service at the later stage. Message Service can be applied to production environments after simple configuration.
- Create an Alibaba Cloud account and subscribe to Message Service online.
- Choose Console-Account Management to obtain the account ID, and click AccessKeys to obtain the AccessKeyID.
- Perform basic operations visually at Message Service console, such as creating and deleting queues, and receiving and sending messages.
- Call APIs (SDKs) in the applications to execute all Message Service operations.
- MessageID is used to identify a message in a message queue/topic. In one message queue/topic, each message has a unique MessageID, but MessageIDs in different message queues/topics may be the same.
- When a message is sent to a Message Service queue/topic, Message Service generates a MessageID which will not change.
- When a message in queue mode is removed, Message Service returns the message body, MessageID, and temporary ReceiptHandle of this request to the user. ReceiptHandle is used to delete the message after the message consumption is complete within the validity period.
Yes. Compared with traditional ShortPolling, in LongPolling, a response is returned only when a message enters the queue or LongPolling times out. Once the message is available, LongPolling can immediately retrieve the message in the Message Service queue in a simple and economical manner.
For details about LongPolling settings, refer to related description on the PollingWaitSeconds attribute in Message Service API documentation.
Message Service tries its best to ensure that messages are consumed in an FIFO manner. However, due to some features of distributed message queues, it cannot be ensured that you can consume messages in the order they are sent. If your service requires FIFO, you are advised to add sequence numbers to messages so that messages are resorted after consumption.
Message Service can work with other Alibaba Cloud services, such as ECS, OSS, and Table Store, making applications more flexible and scalable.Common uses include: Create multiple components or modules that have mutual communication demands but cannot process the same workload at the same time. In this scenario, the Message Service queue can carry messages so that applications running on the ECS instance can process the messages in sequence. The ECS instance can read the queue, process tasks, and then publish the result to another Message Service queue as a message (which may be further processed by other applications). Because ECS allows dynamic scalability of applications, application developers can easily change the number of computing instances based on the number of messages (service volume) in the Message Service queue, ensuring timely processing of the tasks.
Message Service stores all queues and messages on a network formed by highly reliable and highly available data centers of Alibaba Cloud. All messages are stored on multiple servers in redundancy mode. When one server fails, redundant data will be automatically copied to other servers. This means that the security of messages in the Message Service queue is not affected in the case of a single server fault or network failure.
How does Message Service ensure that no messages are lost or repeatedly consumed when multiple consumers access the same message queue?
Each Message Service queue has the configurable invisibility period attribute (that is, the hidden period of a message taken out from the queue). When one message is taken out from the queue, other consumers cannot obtain this message during its invisibility period. If the user completes the consumption within the invisibility period, the temporary handle (ReceiptHandle) is used to delete the message. If the user does not complete the consumption within the invisibility period, a request for extending the invisibility period (ChangeVisibilityTimeout) must be sent; otherwise, the message will be obtained by other consumers after the invisibility period expires.
The system is designed to ensure that all messages in a queue will be consumed at least once. You are advised to improve fault tolerance of application services, preventing faults or inconsistency when a message is processed for multiple times.
Alibaba Cloud offers secure and reliable identity verification mechanism to protect your Message Service queues from unauthorized access. Only Alibaba Cloud account owners can access the queues created by themselves.
To configure the message retention period, use SetQueueAttributes to set the MessageRetentionPeriod attribute. This attribute specifies the retention seconds of a message in the Message Service queue. At present, the message retention period is four days by default. You can set MessageRetentionPeriod to a value between 60 seconds (one minute) and 1,296,000 seconds (15 days).
The message retention period is configurable in Message Service. You can set it to any value between one minute and 15 days. The default value is four days. Once the message retention period expires, your message will be deleted automatically. A longer message retention period offers higher flexibility, allowing a longer interval between the generation and consumption of messages.
To configure the maximum message size, use SetQueueAttributes to set the MaximumMessageSize attribute. This attribute specifies the number of bytes of a message in the Message Service queue. It can be set to any value between 1,024 bytes (1 KB) and 65,536 bytes (64 KB). If the message length exceeds 64 KB, you are advised to store the data in OSS, and store only the access address of the data in Message Service.
When you use Message Service normally, Alibaba Cloud does not delete inactive queues or topics. However, if your Message Service is suspended due to overdue charge or other reasons, all your queues and topics will be deleted.
For signature computation principles and precautions, refer to the Message Service API reference manual. The following is an example of signature methods:The HTTP header of the request is:
GET /MyQueue HTTP/1.1
Date: Thu, 09 Jul 2015 03:01:34 GMT
The source string of the signature to be encrypted is:
Thu, 09 Jul 2015 03:01:34 GMT
Assume that the accessID is TestAccessID, and accesskey is TestAccessSecret.The signature value obtained by the encryption algorithm is uwx3yeWoILzgmvesW0BQSgfM7b8=.
No. Queues with the same name in different regions are independent from each other.
If you no longer need a queue, you need to stop all API requests for the queue after deleting the queue instance. Otherwise, Message Service continues billing according to the number of API requests.
If you no longer need a topic, the instance occupation fee will not be charged the next day after the topic instance is deleted. You need to stop all API requests fro the topic. Otherwise, Message Service continues billing according to the number of API requests.