Release Notes and Announcements

Release Notes

Announcements

Product Introduction

Introduction and Selection of the TDMQ Product Series

What Is TDMQ for RabbitMQ

Strengths

Use Cases

Description of Differences Between Managed Edition and Serverless Edition

Open-Source Version Support Description

Comparison with Open-Source RabbitMQ

High Availability

Use Limits

TDMQ for RabbitMQ-Related Concepts

Regions

Related Cloud Services

Billing

Billing Overview

Pricing

Billing Example

Convert to Monthly Subscription from Hourly Postpaid

Renewal

Viewing Consumption Details

Overdue Payments

Refund

Getting Started

Getting Started Guide

Step 1: Preparations

Step 2: Creating a RabbitMQ Cluster

Step 3: Configuring a Vhost

Step 4: Using the SDK to Send and Receive Messages

Step 5: Querying a Message

Step 6: Deleting Resources

User Guide

Usage Process Guide

Configuring the Account Permission

Creating a Cluster

Configuring a Vhost

Connecting to the Cluster

Managing Messages

Configure Advanced Feature

Managing the Cluster

Viewing Monitoring Data and Configuring Alarm Policy

Use Cases

Use Instructions of Use Cases

RabbitMQ Client Use Cases

RabbitMQ Message Reliability Use Cases

Usage Instructions for MQTT Protocol Supported by RabbitMQ

Migrate Cluster

Migrating RabbitMQ to Cloud

Step 1. Purchasing a TDMQ Instance

Step 2: Migrating Metadata to the Cloud

Step 3: Enabling Dual Read-Write

API Reference (Managed Edition)

API Overview

API Reference (Serverless Edition)

History

Introduction

API Category

Making API Requests

Relevant APIs for RabbitMQ Serverless PAAS Capacity

RabbitMQ Serverless Instance Management APIs

Data Types

Error Codes

SDK Documentation

SDK Overview

Spring Boot Starter Integration

Spring Cloud Stream Integration

Java SDK

Go SDK

Python SDK

PHP SDK

Security and Compliance

Permission Management

Network Security

Deletion Protection

Change Records

CloudAudit

FAQs

Service Level Agreement

Creating a Queue

PDF

Mode fokus

Ukuran font

Terakhir diperbarui: 2026-01-05 10:11:17

A queue is used to store messages. Each message will be put into one or more queues. Producers produce messages and deliver them to queues, while consumers pull messages from queues for consumption.
Multiple consumers can subscribe to the same queue. In this case, messages in the queue will be evenly distributed to the consumers for processing, rather than making each consumer receive and process all the messages.
TDMQ for RabbitMQ supports creating classic queues or quorum queues in the console. This document introduces how to create classic queues. For how to create quorum queues, see Configuring a Quorum Queue.
Classic queue: employs a lightweight indexing and shared storage architecture, striking a balance between single-node performance and storage efficiency. It is suitable for high-throughput scenarios that do not require strong consistency.
Quorum queue: implements strong consistency through multiple replicas based on the Raft protocol, ensuring no loss of critical business data. It is suitable for key business scenarios such as financial transactions and order management.
Constraints and Limitations
Limitation Type
Managed Edition
Serverless Edition
Quantity
A single vhost supports the creation of up to 1000 queues.
A single vhost supports the creation of up to 100 queues.
Default queue
After a vhost is created, a default queue named tdmq_event_handle is created for the event query feature. It cannot be edited or deleted, nor can it have new binding relationships. Instead, it is bound by default to the default exchange named amq.rabbitmq.event.
No default queue.
Queue types supported for creation in the console
Supports creating classic queues or quorum queues.
Only supports creating classic queues.
Prerequisites
You have created a corresponding vhost. For specific steps, see Creating a Vhost.
Operation Steps
Managed Edition
Serverless Edition
1. Log in to the TDMQ for RabbitMQ console.
2. In the left sidebar, choose Cluster > Queue, select a vhost, and then click Create to go to the Create Queue page.
3. After configuring the queue information as prompted on the page, click Submit to complete the queue creation.
Category
Parameter
Required
Description
Basic info
Current Vhost
Yes
Indicates which vhost the queue is being created for.
﻿
Queue Name
Yes
Enter a queue name. It must be 1 to 64 characters in length and can only contain letters, digits, hyphens (-), and underscores (_).
After a queue is successfully created, the name cannot be modified.
﻿
Type
Yes
Select Classic Queue.
﻿
Durable
No
Set whether to enable persistence for the queue. It is enabled by default.
If it is set to true, the queue persists after a service restart.
If it is set to false, the queue will be deleted after a service restart and needs to be recreated.
﻿
Node
Yes
Select the cluster node where the queue is located from the drop-down list.
﻿
AutoDelete
No
Whether to enable automatic deletion of the queue. It is disabled by default.
If it is set to true, the queue will be automatically deleted when the last consumer unsubscribes from its messages.
If it is set to false, the queue will not be deleted when the last consumer unsubscribes from its messages.
﻿
Queue Description
No
Enter the queue description information, with a maximum of 128 characters.
Common Parameters
Message TTL
No
TTL of messages in the queue, in milliseconds (ms). If a message is not successfully consumed after the TTL expires, then:
If a dead letter exchange is specified, the message will be sent to the dead letter exchange.
If no dead letter exchange is specified, the message will be discarded.
﻿
Auto Expire
No
Idle time-to-live for a queue. When no consumer connections exist, and no messages are consumed or published within the specified time period, the queue will be automatically deleted.
﻿
Max Length
No
Maximum number of messages a queue can hold. Exceeding this set value will trigger the overflow behaviour policy.
﻿
Max Length Bytes
No
Maximum storage capacity for a queue. Exceeding this set value will trigger the overflow behaviour policy.
﻿
Overflow Behaviour
No
Message processing policy of the queue when the queue capacity reaches the upper limit:
drop-head: When the queue capacity reaches the upper limit, discard messages at the head of the queue.
reject-publish: When the queue capacity reaches the upper limit, reject the publishing of new messages and mark the publish operation as failed.
reject-publish-dlx: When the queue reaches its capacity limit, reject the publishing of new messages and route them to the dead letter exchange (DLX). If no dead letter exchange is configured, the system will automatically specify the default exchange named AMQP default exchange.
﻿
Dead Letter Exchange
Yes
Messages that are not successfully consumed beyond the TTL will be delivered to the dead letter exchange. By default, the system specifies the default exchange named AMQP default exchange.
Other Advanced Options
Single Active Consumer
No
Whether to enable the single active consumer, which is disabled by default.
If it is set to true, the queue allows only one consumer to process messages at a time. Other consumers remain in the standby status. When the active consumer disconnects, the system automatically selects the next consumer. This configuration is suitable for sequence-sensitive tasks, such as order status changes.
﻿
Maximum Priority
No
Set the maximum priority for messages in this queue, with an optional range of [0, 255]. Higher values incur greater sorting overheads.
After this parameter is configured, the priority feature is enabled. When sending messages, producers specify the priority level (between 0 and Maximum Priority) via the priority property. High-priority messages are consumed before lower-priority ones. The priority level of messages without a priority setting defaults to 0. This feature is suitable for scenarios such as prioritizing VIP customer orders or allowing urgent tasks to jump the queue.
﻿
Lazy Mode
No
Whether to enable lazy mode. It is disabled by default.
If it is set to true, the queue will save the incoming messages first on the disk to reduce memory usage and load them into memory only when they are consumed. This feature is suitable for queues with severe message backlogs, such as dead letter queues.
If it is set to false, messages are stored in memory by default.
﻿
Master Locator
No
Allocation method for the master node when mirrored queues are configured.
min-masters (default): When mirrored queues are configured, the node that manages the fewest queue masters is selected as the location for the master of the current queue. It is recommended to retain the default min-masters setting in production environments to achieve load balancing.
client-local: When mirrored queues are configured, the node to which the client declaring the queue is connected is selected as the location for the master of the current queue.
random: When mirrored queues are configured, a random node is selected as the location for the master of the current queue.
﻿
1. Log in to the TDMQ for RabbitMQ console.
2. In the left sidebar, choose Cluster > Queue, select a vhost, and then click Create to go to the Create Queue page.
3. After entering the basic information of the queue, click Submit to complete the creation of the queue.
Parameter
Required
Description
Current Vhost
Yes
Indicates which vhost the queue is being created for.
Queue Name
Yes
Enter a queue name. It must be 1 to 64 characters in length and can only contain letters, digits, hyphens (-), and underscores (_).
After a queue is successfully created, the name cannot be modified.
Type
Yes
Only supports Classic Queue.
Message TTL
No
TTL of messages in the queue, in milliseconds (ms). If a message is not successfully consumed after the TTL expires, then:
If a dead letter exchange is specified, the message will be sent to the dead letter exchange.
If no dead letter exchange is specified, the message will be discarded.
Dead Letter Exchange
No
Messages that are not successfully consumed beyond the TTL will be delivered to the dead letter exchange.
Queue Description
No
Enter a queue description, with a maximum of 128 characters.
﻿

Bantuan dan Dukungan

Apakah halaman ini membantu?

Anda juga dapat Menghubungi Penjualan atau Mengirimkan Tiket untuk meminta bantuan.

masukan

Limitation Type	Managed Edition	Serverless Edition
Quantity	A single vhost supports the creation of up to 1000 queues.	A single vhost supports the creation of up to 100 queues.
Default queue	After a vhost is created, a default queue named tdmq_event_handle is created for the event query feature. It cannot be edited or deleted, nor can it have new binding relationships. Instead, it is bound by default to the default exchange named amq.rabbitmq.event.	No default queue.
Queue types supported for creation in the console	Supports creating classic queues or quorum queues.	Only supports creating classic queues.

Category	Parameter	Required	Description
Basic info	Current Vhost	Yes	Indicates which vhost the queue is being created for.
		Queue Name	Yes	Enter a queue name. It must be 1 to 64 characters in length and can only contain letters, digits, hyphens (-), and underscores (_). After a queue is successfully created, the name cannot be modified.
		Type	Yes	Select Classic Queue.
		Durable	No	Set whether to enable persistence for the queue. It is enabled by default. If it is set to true, the queue persists after a service restart. If it is set to false, the queue will be deleted after a service restart and needs to be recreated.
		Node	Yes	Select the cluster node where the queue is located from the drop-down list.
		AutoDelete	No	Whether to enable automatic deletion of the queue. It is disabled by default. If it is set to true, the queue will be automatically deleted when the last consumer unsubscribes from its messages. If it is set to false, the queue will not be deleted when the last consumer unsubscribes from its messages.
		Queue Description	No	Enter the queue description information, with a maximum of 128 characters.
Common Parameters	Message TTL	No	TTL of messages in the queue, in milliseconds (ms). If a message is not successfully consumed after the TTL expires, then: If a dead letter exchange is specified, the message will be sent to the dead letter exchange. If no dead letter exchange is specified, the message will be discarded.
		Auto Expire	No	Idle time-to-live for a queue. When no consumer connections exist, and no messages are consumed or published within the specified time period, the queue will be automatically deleted.
		Max Length	No	Maximum number of messages a queue can hold. Exceeding this set value will trigger the overflow behaviour policy.
		Max Length Bytes	No	Maximum storage capacity for a queue. Exceeding this set value will trigger the overflow behaviour policy.
		Overflow Behaviour	No	Message processing policy of the queue when the queue capacity reaches the upper limit: drop-head: When the queue capacity reaches the upper limit, discard messages at the head of the queue. reject-publish: When the queue capacity reaches the upper limit, reject the publishing of new messages and mark the publish operation as failed. reject-publish-dlx: When the queue reaches its capacity limit, reject the publishing of new messages and route them to the dead letter exchange (DLX). If no dead letter exchange is configured, the system will automatically specify the default exchange named AMQP default exchange.
		Dead Letter Exchange	Yes	Messages that are not successfully consumed beyond the TTL will be delivered to the dead letter exchange. By default, the system specifies the default exchange named AMQP default exchange.
Other Advanced Options	Single Active Consumer	No	Whether to enable the single active consumer, which is disabled by default. If it is set to true, the queue allows only one consumer to process messages at a time. Other consumers remain in the standby status. When the active consumer disconnects, the system automatically selects the next consumer. This configuration is suitable for sequence-sensitive tasks, such as order status changes.
		Maximum Priority	No	Set the maximum priority for messages in this queue, with an optional range of [0, 255]. Higher values incur greater sorting overheads. After this parameter is configured, the priority feature is enabled. When sending messages, producers specify the priority level (between 0 and Maximum Priority) via the priority property. High-priority messages are consumed before lower-priority ones. The priority level of messages without a priority setting defaults to 0. This feature is suitable for scenarios such as prioritizing VIP customer orders or allowing urgent tasks to jump the queue.
		Lazy Mode	No	Whether to enable lazy mode. It is disabled by default. If it is set to true, the queue will save the incoming messages first on the disk to reduce memory usage and load them into memory only when they are consumed. This feature is suitable for queues with severe message backlogs, such as dead letter queues. If it is set to false, messages are stored in memory by default.
		Master Locator	No	Allocation method for the master node when mirrored queues are configured. min-masters (default): When mirrored queues are configured, the node that manages the fewest queue masters is selected as the location for the master of the current queue. It is recommended to retain the default min-masters setting in production environments to achieve load balancing. client-local: When mirrored queues are configured, the node to which the client declaring the queue is connected is selected as the location for the master of the current queue. random: When mirrored queues are configured, a random node is selected as the location for the master of the current queue.

tencent cloud

TDMQ for RabbitMQ

Creating a Queue

Constraints and Limitations

Prerequisites

Operation Steps

Bantuan dan Dukungan