tencent cloud

Feedback

Note

Last updated: 2020-06-08 16:02:37

    Note:

    This is a legacy API which has been hidden and will no longer be updated. We recommend using the new CMQ API 3.0 which is standardized and faster.

    Welcome to Tencent Cloud message queue CMQ (Cloud Message Queue).

    Tencent Cloud message queuing (Cloud Message Queue, (hereinafter referred to as CMQ) is a distributed message queuing service that stores messages transmitted between processes and provides reliable message-based asynchronous communication services between different distributed applications or between different components of an application. Messages are stored in highly reliable and highly available message queues, and multiple processes can read and write at the same time without interfering with each other. With Tencent Cloud CMQ, users can pass information between distributed components executing different job's applications without losing messages or requiring that each component is always available.

    The queue acts as a buffer between the data sender and the data receiver. Queues can solve the problems when the working speed of the data sender is faster than that of the data receiver, or when the data sender or data receiver is only intermittently connected to the network.

    In the traditional process communication mode, the client requests the service of the server and waits for the response of the server. However, this model has many disadvantages: for example, when the network condition is bad, the client's request may be lost; when the server-side processing time is too long, it may cause the client to wait for a long time and the request timed out and failed.

    To this end, Tencent Cloud introduced message queuing service for message distribution and management. With Tencent Cloud CMQ, you can separate the components of an application so that they can run independently, while simplifying message management between components. Any component of a distributed application can store messages in queues, and Tencent Cloud CMQ ensures that each message is delivered at least once and supports multiple reads and writes. A single queue can be used by multiple distributed application components at the same time without the need for collaboration between these components. All components can use CMQ API to retrieve and manipulate messages programmatically.

    For all supported operations, see API Overview Page .

    Please make sure that you have a good understanding of these interfaces before using them. CMQ product description .

    The helper account cannot be used for CMQ operations at this time.

    Queue model

    Glossary of terms

    Below is the list of common terms used in this document:

    Terminology Full name English Description
    CMQ Cloud Message Queue Cloud message queue Tencent Cloud's message service includes queue model, topic model, high-performance message service and so on.
    Queue Queue Queue Queue is a first-in-first-out data model. Producers can add data to the end of the queue by Concurrence, and consumers can pull (pull) data from the head of the queue by Concurrence.
    Active Active Can be consumed (visible) state When the message is in Active state, it can be consumed by all consumers, but only one consumer can successfully consume it. At this time, the message becomes Inactive and is not visible to other consumers.
    Inactive Inactive Non-consumable (invisible) state When a message is in the Inactive state, it indicates that the message is being consumed by a consumer, and other consumers cannot consume the message.
    (Batch) ReceiveMessage (Batch) Receive Message Consumption message The ReceiveMessage operation simply sets the message from the Active state to the Inactive state so that the message cannot be consumed by other consumers. However, after consumption, Explicit has to call the (Batch) DeleteMessage operation to delete the message from the queue, otherwise, after the time specified by visibilityTimeout, the message becomes Active again and can be consumed by other consumers, resulting in unexpected duplicate messages.
    MaxMsgHeapNum Maximum Message Heap Number Maximum number of Message Retention In order to prevent the message from being lost because the message is not consumed in time, the message service has the function of heap message. Heap has an upper limit on the number of messages. Producers can no longer add messages to the queue after the limit is exceeded. After the message is consumed and deleted, the producer can add the message to the queue.
    PollingWaitSeconds Polling Wait Seconds Long-polling Waiting Time for Message Receipt When consumers want to pull messages from the queue for consumption, the queue may have no data for the time being. Consumers may not want to return immediately (similar to non-blocking mode) and want to wait for a period of time to see if a message will come. (similar to blocking mode), pollingWaitSeconds is similar to the timeout in blocking mode. After this time, it will return regardless of whether there is a message or not. If you want to consume messages nonblocking, set the value to 0.
    MsgRetentionSeconds Message Retention Seconds Message Lifecycle Heap's message in the queue has a retention time, after which it has not been consumed by consumers, it will be deleted by the queue, and consumers can no longer consume it.
    ReceiptHandle Receipt Handle Message receipt handle This handle is returned when the message is consumed, and only the handle that is currently consuming the message can delete the message. If the consumption time is too long and exceeds the visibilityTimeout, the message will be consumed by other consumers, and the previous consumer's handle to get the message will become invalid and cannot be used to delete the message.
    Qps throttling QPS Throttling QPS restriction The term originally means a limit on the number of requests per second, but it is actually a limit on the number of messages per second. The number of requests per second for a single interface (SendMessage, ReceiveMessage, DeleteMessage),). But for batch interfaces (BatchSendMessage, BatchReceiveMessage, BatchDeleteMessage),), it is the sum of all batch values within 1 second. The purpose of this restriction is to provide users with a more stable and fair product. If you need a larger message limit, you can Submit a ticket Apply to us.

    Definition of input parameters and return parameters

    • Limit and offset
      Limit and offset are parameters used to control paging. When the corresponding result is in the form of a list, if the number exceeds the value limited by limit, only limit values are returned. Users can control paging through two parameters: limit and offset: limit is the maximum number of entries returned at a time, and offset is the offset.
      For example, the parameter offset=0&limit=20 returns items 0 to 20, offset=20&limit=20 returns items 20 to 40, offset=40&limit=20 returns items 40 to 60, and so on.

    • Id.n
      Id.n is a format in which multiple parameters are entered at the same time. When a format like this is encountered, multiple input parameters can be passed at the same time.
      For example, id.0= "10.12.243.21" & id.1= "10.12.243.21" & id.2= "10.12.243.21" & id.3= "10.12.243.21". And so on (starting with 0 below).

    API Getting Started

    Users can use the CMQ SDK (it is recommended that multiple language versions are available), or call Cloud API directly (it is more troublesome, it is recommended for users other than SDK language) to use CMQ services:

    1. Select region and private and public network. Unlike other Tencent Cloud services, the request domain name of message queuing API varies with different regions. You need to select the domain name corresponding to the region. The composition rules of the request domain name are as follows cmq-queue-region.api.qcloud.com/v2/index.php The region field needs to replace: gz (Guangzhou), sh (Shanghai) and bj (Beijing) with a specific region. If the machine used by the user is a Tencent Cloud server, the private network domain name should be preferred, otherwise the public network domain name should be selected.
    2. Create a queue . SDK (or cloud API) calls the CreateQueue API.
    3. Message sending . SDK (or cloud API) calls the SendMessage (or BatchSendMessage) API.
    4. Consumption message . SDK (or cloud API) calls the ReceiveMessage (or BatchReceiveMessage) API.
    5. Delete message . SDK (or cloud API) calls DeleteMessage (or BatchDeleteMessage).
    6. Delete queue . SDK (or cloud API) calls the DeleteQueue API.

    Topic model

    Glossary of terms

    Below is the list of common terms used in this document:

    Terminology English Description
    Subscriber Subscriber Refers to the subscriber of the service in CMQ-Topic mode.
    Production Produce Refers to the operation of the producer to write a message to the Topic.
    Shipping Subscription Refers to the process of Topic's message to subscriber shipping.
    Message receiving mode (PUSH) Message-receiving model (PUSH) The Topic model of CMQ, which already supports the PUSH mode of active push.
    Retry policy NotifyStrategy The NotifyStrategy property of the subscription, which is the retry policy when an error occurs in pushing the message to the receiver. This policy is enabled by default. There are two options, one of which must be checked.
    a. Backoff retry: retry 3 times with a random value between 10 and 20 seconds. After more than 3 times, the message is discarded for the subscriber and will not be retried.
    b. Recession index retry (default check): retry 176 times, the total retry time is 1 day, the interval is: 2 ^0,2^ 1,. , 512, 512,. , 512 seconds.
    Message Lifecycle MsgRetentionSeconds The longest survival time of a message in TOPIC. After the time specified by this parameter from sending to the queue, the message will be deleted regardless of whether the message has been fetched or not. The default value is 86400s (1 day), and modification is not allowed.
    Max Message Length MaxMsgSize Limits the maximum length of the message body allowed to be sent to the queue; in units, byte, valid values range from 1024 to 65536byte, that is, 1K to 64K.
    Message Retention MessageRetentionPeriod On by default. There is a message from the producer, which has not yet triggered shipping to the subscriber, or the subscriber failed to receive the message. For the time being, heap went to the Topic and tried again. The project cannot be configured. The maximum heap time is 1 day.
    Retry verification Status code After Topic shipping arrives at the subscriber, if the HTTPS return code is 200, it will be considered successful.
    Add subscriber tags FilterTag When you add a subscriber, you can add FilterTag,. After adding FilterTag, the subscriber can only receive messages with that FilterTag. A single Tag is a string of no more than 16 characters, and a single subscriber can add up to 5 Tag. As long as one of the Tag, matches the filter tag of Topic, you can receive the message from Topic shipping. If the message does not have any tags, the subscriber cannot receive this type of message.
    Add message filter tags Messagetag That is, message label and message type, which are used to distinguish the message classification under the Topic of a certain CMQ. MQ allows consumers to filter messages by Tag, ensuring that consumers end up consuming only the types of messages they care about. This feature is not enabled by default. When it is not enabled, all messages are sent to all subscribers. When the subscriber sets Tag, the subscriber cannot receive the message because of a mismatch. The message filtering tag describes the label of message filtering in the subscription (only messages with consistent labels are pushed). A string with no more than 16 characters in a single Tag, and a single Message can add up to 5 Tag.
    Open log track LoggingEnabled Whether to enable the log management feature. True: enable, False: disable. When enabled, the original Log of CMQ is written to Cloud Object Storage COS. And users can do Log aggregation query through the CMQ console to avoid the tedious need to build their own analysis system.

    Definition of input parameters and return parameters

    • Limit and offset
      Parameters used by limit and offset to control paging. When the corresponding result is in the form of a list, if the number exceeds the value limited by limit, only limit values are returned. Users can control paging through two parameters: limit and offset: limit is the maximum number of entries returned at a time, and offset is the offset.
      For example, the parameter offset=0&limit=20 returns items 0 to 20, offset=20&limit=20 returns items 20 to 40, offset=40&limit=20 returns items 40 to 60, and so on.

    • Id.n
      Id.n is a format in which multiple parameters are entered at the same time. When a format like this is encountered, multiple input parameters can be passed at the same time.
      For example, id.0= "10.12.243.21" & id.1= "10.12.243.21" & id.2= "10.12.243.21" & id.3= "10.12.243.21". And so on (starting with 0 below).

    API Getting Started

    Users can use the CMQ SDK (it is recommended that multiple language versions are available), or call Cloud API directly (it is more troublesome, it is recommended for users other than SDK language) to use CMQ services:

    1. Select region and private and public network. Unlike other Tencent Cloud services, the request domain name of message queuing API varies with different regions. You need to select the domain name corresponding to the region. The composition rules of the request domain name are as follows cmq-topic-region.api.qcloud.com/v2/index.php The region field needs to replace: gz (Guangzhou), sh (Shanghai) and bj (Beijing) with a specific region. If the machine used by the user is a Tencent Cloud server, the private network domain name should be preferred, otherwise the public network domain name should be selected.
    2. Create topic . SDK (or cloud API) calls the CreateTopic API.
    3. Modify Topic Attributes . SDK (or cloud API) calls the SetTopicAttributes API.
    4. Get topic list . SDK (or cloud API) calls the ListTopic API.
    5. Get topic attribute . SDK (or cloud API) calls the GetTopicAttributes API.
    6. Delete topic . SDK (or cloud API) calls the DeleteTopic API.
    7. Publish news . SDK (or cloud API) calls the PublishMessage API.
    8. Batch publish messages . SDK (or cloud API) calls the BatchPublishMessage API.
    9. Shipping news .
    10. Create a subscription . SDK (or cloud API) calls the Subscribe API.
    11. Get subscription list . SDK (or cloud API) calls the ListSubscriptionByTopic API.
    12. Modify subscription properties . SDK (or cloud API) calls the SetSubscriptionAttributes API
    13. Get subscription properties . SDK (or cloud API) calls the GetSubscriptionAttributes API.
    14. Delete Subscription . SDK (or cloud API) calls the Unsubscribe API.