- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Best Practices
- Message Queue Model
- Message Topic Model
- Migration Description
- Solutions and Cases
- API Documentation
- SDK
- Service Level Agreement
- Glossary
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Best Practices
- Message Queue Model
- Message Topic Model
- Migration Description
- Solutions and Cases
- API Documentation
- SDK
- Service Level Agreement
- Glossary
Tencent Cloud Message Queue (CMQ) is a distributed message queue service that provides a reliable message-based async communication mechanism among different applications deployed in a distributed manner (or different components of the same application). Messages are stored in highly reliable and available CMQ queues, and multiple processes can be read/written at the same time without affecting one another.
CMQ provides four SDKs. This document uses the SDK for Python as an example.
SDK for Python Overview
To facilitate your use, CMQ operations for objects such as users, queues, and topics are divided into the following classes:
- Account: encapsulates account
SecretIdandSecretKeyso that you can create, delete, and view queues, topics, and subscriptions. - queue: receives/sends messages and views/sets queue attributes.
- topic: publishes messages, views and sets topic attributes, and views subscribers.
- cmq_client: sets the attributes of the connection between client and server, such as setting whether log write is enabled, connection timeout period, and whether persistent connection is enabled
All classes are not thread-safe. If you need to use them in multiple threads, it is recommended that each thread instantiate its own objects.
Queue Model
A queue in CMQ is different from that defined in a data structure. Queues in data structures are manipulated in strict compliance with the FIFO method, while CMQ distributed queues do not strictly follow FIFO (a dedicated FIFO product will be released in the future). A CMQ queue is considered as a container featuring high performance, capacity, and reliability, to which produced messages can be delivered, and from which messages can be fetched out for consumption. It has its own attribute settings during initialization as detailed below:
| Attribute | Description |
|---|---|
| maxMsgHeapNum | Maximum number of retained messages, i.e., number of messages that can be stored in a queue. It represents the queue storage and retention capacity. |
| pollingWaitSeconds | Long-polling waiting time for message receipt, which ranges from 0 to 30 seconds. It indicates the default time it takes to receive a message during message consumption. For example, when this attribute is set to 10, if there are no messages during message consumption, the result will be returned after 10 seconds of waiting by default; otherwise, the result will be immediately returned. You can customize the waiting time when receiving messages, which will take precedence over this attribute. |
| visibilityTimeout | Message visibility timeout period. After a message is obtained by a consumer, there will be an invisibility period, during which other consumers cannot get this message. This value ranges from 1 to 43,200 seconds (12 hours), and the default value is 30. |
| maxMsgSize | Maximum message size, which ranges from 1,024 to 1,048,576 bytes (i.e., 1–1,024 KB). The default value is 65,536. |
| msgRetentionSeconds | Message lifecycle, i.e., message retention time period in queue, which ranges from 60 to 1,296,000 seconds (1 minute to 15 days). The default value is 345,600 (4 days). |
| createTime | Queue creation time. A Unix timestamp accurate down to the second will be returned. |
| lastModifyTime | Time when the queue attribute is last modified. A Unix timestamp accurate down to the second will be returned. |
| activeMsgNum | Total number of messages in Active state (not being consumed) in queue, which is an approximate value. |
| inactiveMsgNum | Total number of messages in Inactive state (being consumed) in queue, which is an approximate value. |
| rewindSeconds | Maximum time range during which a message can be rewound in the queue, which ranges from 0 to 43,200 seconds. 0 indicates that message rewind is disabled. |
| rewindmsgNum | Number of retained messages which have been deleted by the DelMsg API but are still within their rewind time range. |
| minMsgTime | Minimum unconsumed time of message in seconds. |
| delayMsgNum | Number of delayed messages. |
Getting Started with Queue Model >>
Topic Model
The topic model is similar to the publish/subscribe design pattern. A topic is the unit for sending messages, and subscribers under a topic are equivalent to observers. A topic will actively push published messages to subscribers.
| Attribute | Description |
|---|---|
| msgCount | Number of messages currently retained in topic (number of retained messages) |
| maxMsgSize | Maximum message size, which ranges from 1,024 to 1,048,576 bytes (i.e., 1–1,024 KB). The default value is 65,536. |
| msgRetentionSeconds | Maximum lifecycle of message in topic. After the period specified by this parameter has elapsed since a message is sent to the topic, the message will be deleted no matter whether it has been successfully pushed to the user. This parameter is measured in seconds and defaulted to one day (86,400 seconds), which cannot be modified. |
| createTime | Topic creation time. A Unix timestamp accurate down to the second will be returned. |
| lastModifyTime | Time when the topic attribute is last modified. A Unix timestamp accurate down to the second will be returned. |
| filterType | Filtering policy selected when a subscription is created: If filterType is 1, filterTag will be used for filtering.If filterType is 2, bindingKey will be used for filtering. |
Yes
No
Was this page helpful?