Create Queue

Last updated: 2025-08-11 10:37:21

Create Queue

Last updated: 2025-08-11 10:37:21

A Queue is used to store messages. Each message will be put into one or more queues. Producers generate messages and deliver them to queues. Consumers can pull messages from queues to consume.
Multiple consumers can subscribe to the same Queue. At this point, messages in the Queue will be evenly distributed to multiple consumers for processing, rather than each Consumer receiving all messages and handling them.
Restrictions and Limitations
Limit Type
Open-Source Managed
Serverless Edition
Quantity
A Vhost supports creating a maximum of 1000 Queues.
A Vhost supports creating a maximum of 100 Queues.
Default Queue
After creation, a Vhost creates a default Queue named tdmq_event_handle for event query functionality. It cannot be edited or deleted, and adding binding relationships is not supported. By default, it is bound to the default Exchange named amq.rabbitmq.event.
No default Queue.
Console-supported queue types
Support creating regular queues or Quorum Queues.
Only supports creating regular queues.
Prerequisites
The corresponding Vhost has been created. For the directions, see Create a Vhost.
Operation Steps
Open-Source Managed
Serverless Edition
1. Log in to the TDMQ for RabbitMQ console.
2. Select Cluster Management > Queue in the left sidebar, select a Vhost, then click Create to enter the create queue page.
3. Fill in the Queue basic information, click Submit to complete the Queue creation.
Note:
Support creating regular queues or Quorum Queues. Click the following tabs to view ways to create different types of queues.
Ordinary Queue (Classic Queue): Uses lightweight index and shared storage architecture to balance standalone performance and storage efficiency, suitable for high-throughput scenarios with poor data consistency.
Quorum Queue: Based on the Raft protocol, implements multiple replicas with strong consistency to ensure critical business operations and data integrity, suitable for key business such as financial transactions and order management.
Ordinary Queue
Quorum Queue
Category
Parameter
Required or Not
Description
Basic Information
Current Vhost
Yes
Indicates which Vhost the Queue is being created for.
﻿
Queue Name
Yes
Fill in the Queue Name, comply with the naming rule: 1-64 characters, only letters, numbers, "-", and "_" are allowed.
Queue name cannot be modified after successful creation.
﻿
Type
Yes
Select Ordinary Queue.
﻿
Durable
No
Set whether to persist the Queue, enabled by default.
If set to true, the Queue still exists after service restart.
If set to false, the Queue will be deleted after service restart and needs to be rebuilt.
﻿
Node
Yes
In the dropdown list, select the node of the Queue cluster.
﻿
AutoDelete
No
Whether to enable auto-delete for the Queue, off by default.
If set to true, the Queue will be automatically deleted when the last consumer subscribing to Queue messages unsubscribes.
If set to false, the Queue will not be deleted when the last consumer subscribing to Queue messages unsubscribes.
﻿
Queue Description
No
Fill in the Queue description, up to 128 characters.
Common Parameters
Message TTL
No
The time to live of messages in the Queue, in milliseconds. If the TTL is exceeded and the message hasn't been successfully consumed, then:
If a dead letter Exchange is specified, the message will be sent to the dead letter Exchange.
If a dead letter Exchange is not specified, the message will be discarded.
﻿
Auto Expire
No
The idle survival time of a Queue. If the Queue has no consumer connection, no message consumed or published within a specified time, it will be automatically deleted.
﻿
Max Length
No
The Queue can hold messages up to the capacity limit. Exceeding the set value will trigger the Overflow policy.
﻿
Max Length Bytes
No
The Queue's storage capacity limit triggers the Overflow policy when exceeding the set value.
﻿
Overflow Behaviour
No
When the Queue capacity reaches the upper limit, the message processing policy:
drop-head: drop the message at the head of the queue when the capacity limit is reached.
reject-publish: deny new message release and mark the release operation as fail when the queue reaches capacity limit.
reject-publish-dlx: When the queue reaches its capacity limit, reject new message publishing and send messages to the Dead Letter Exchange (dlx). If no Dead Letter Exchange is configured, automatically designate the default Exchange named AMQP default Exchange.
﻿
dead letter Exchange
Yes
The message size exceeds the TTL time and is not successfully consumed, it will be sent to the dead letter Exchange, designated by default as the AMQP default Exchange.
Other advanced options
Single Active Consumer
No
Whether single active consumer is enabled, off by default.
If set to true, the Queue only allows one consumer to consume messages at the same time. Other consumers remain on standby. When the active consumer disconnects, the next consumer is automatically selected. Suitable for sequential-sensitive tasks such as order status change.
﻿
Maximum Priority
No
Configure the maximum priority of messages in the queue. Optional range: [0, 255]. A higher value results in larger sorting overhead.
After configuring this parameter, the priority feature is enabled. When the producer sends messages, it specifies the priority (between 0 and Maximum Priority) through the priority attribute. High-priority messages are consumed first. Messages without a priority set default to 0. Applicable to scenarios such as VIP customer order priority handling and emergency task preemption.
﻿
Lazy Mode
No
Whether lazy mode is enabled, off by default.
If set to true, the queue will prioritize saving pushed messages on disk to reduce memory usage, loading them to memory only when consuming. Suitable for queues with severe message backlog, such as dead letter queue.
If set to false, messages are stored in memory by default.
﻿
Master Locator
No
When a mirrored queue is configured, the allocation method of the master node location.
min-masters (default): When a mirrored queue is configured, select the node with the least number of managed queue masters as the location of the current queue master. It is recommended to keep the default min-masters in a production environment to achieve load balancing.
client-local: When a mirrored queue is configured, select the node that the client declaring the queue connects to as the location of the current queue master.
random: When a mirrored queue is configured, select a random node as the location of the current queue master.
Category
Parameter
Required or Not
Description
Basic Information
Current Vhost
Yes
Indicates which Vhost the Queue is being created for.
﻿
Queue Name
Yes
Fill in the Queue Name, comply with the naming rule: 1-64 characters, only letters, numbers, "-", and "_" are allowed.
Queue name cannot be modified after successful creation.
﻿
Type
Yes
Select Quorum Queue.
﻿
Node
Yes
In the dropdown list, select the node of the Queue cluster.
﻿
Queue Description
No
Fill in the Queue description, up to 128 characters.
Common Parameters
Auto Expire
No
The idle survival time of a Queue. If the Queue has no consumer connection, no message consumed or published within a specified time, it will be automatically deleted.
﻿
Max Length
No
The Queue can hold messages up to the capacity limit. Exceeding the set value will trigger the Overflow policy.
﻿
Max Length Bytes
No
The Queue's storage capacity limit triggers the Overflow policy when exceeding the set value.
﻿
Delivery Limit
No
If message delivery fails in the queue, the allowed retry count. When the delivery count reaches the set value, the message will be automatically delivered to the dead-letter queue (if a dead letter Exchange is configured), otherwise it will be discarded.
﻿
Overflow Behaviour
No
When the Queue capacity reaches the upper limit, the message processing policy:
drop-head: drop the message at the head of the queue when the capacity limit is reached.
reject-publish: deny new message release and mark the release operation as fail when the queue reaches capacity limit.
﻿
Dead Letter Policy
Yes
Policy for delivering messages unable to be consumed to the dead-letter queue.
at-most-once: deliver up to once, messages may be lost but not duplicated, suitable for non-critical business with message loss allowed.
at-least-once: deliver at least once, messages will not be lost but may duplicate, applicable to key business operations where message loss is not allowed. Only when overflow behaviour is set to reject-publish can you choose at-least-once for dead letter policy.
﻿
dead letter Exchange
Yes
The message failed to deliver after reaching maximum retry limit and will be sent to the dead letter Exchange, designated by default as the AMQP default Exchange.
Other advanced options
Single Active Consumer
No
Whether single active consumer is enabled, off by default.
If set to true, the Queue only allows one consumer to consume messages at the same time. Other consumers remain on standby. When the active consumer disconnects, the next consumer is automatically selected. Suitable for sequential-sensitive tasks such as order status change.
﻿
Max In Memory Length
No
The maximum number of messages cached in memory for a Quorum Queue will be written to disk if exceeded.
﻿
Max In Memory Bytes
No
The total size (bytes) of messages cached in memory for a Quorum Queue will be written to disk if exceeded.
﻿
Initial cluster size
No
Define the initial node count in the cluster participating in Raft consensus for a Quorum Queue.
﻿
Leader locator
Yes
Specify the Leader node selection policy for a Quorum Queue.
client-local: Select the node with client connection as the current queue Leader to reduce network delay.
balanced: evenly distribute Leader to avoid node load is too high
1. Log in to the TDMQ for RabbitMQ console.
2. Select Cluster Management > Queue in the left sidebar, select a Vhost, then click Create to enter the create queue page.
3. Fill in the Queue basic information, click Submit to complete the Queue creation.
Parameter
Required or Not
Description
Current Vhost
Yes
Indicates which Vhost the Queue is being created for.
Queue Name
Yes
Fill in the Queue Name, comply with the naming rule: 1-64 characters, only letters, numbers, "-", and "_" are allowed.
Queue name cannot be modified after successful creation.
Type
Yes
Only supports Ordinary Queue.
Message TTL
No
The time to live of messages in the Queue, in milliseconds. If the TTL is exceeded and the message hasn't been successfully consumed, then:
If a dead letter Exchange is specified, the message will be sent to the dead letter Exchange.
If a dead letter Exchange is not specified, the message will be discarded.
dead letter Exchange
No
The message size exceeds the TTL time and is not successfully consumed, it will be sent to the dead letter Exchange.
Queue Description
No
Fill in the Queue description, up to 128 characters.
﻿
﻿

Was this page helpful?

You can also Contact Sales or Submit a Ticket for help.

Yes

Feedback

Limit Type	Open-Source Managed	Serverless Edition
Quantity	A Vhost supports creating a maximum of 1000 Queues.	A Vhost supports creating a maximum of 100 Queues.
Default Queue	After creation, a Vhost creates a default Queue named tdmq_event_handle for event query functionality. It cannot be edited or deleted, and adding binding relationships is not supported. By default, it is bound to the default Exchange named amq.rabbitmq.event.	No default Queue.
Console-supported queue types	Support creating regular queues or Quorum Queues.	Only supports creating regular queues.

Category	Parameter	Required or Not	Description
Basic Information	Current Vhost	Yes	Indicates which Vhost the Queue is being created for.
		Queue Name	Yes	Fill in the Queue Name, comply with the naming rule: 1-64 characters, only letters, numbers, "-", and "_" are allowed. Queue name cannot be modified after successful creation.
		Type	Yes	Select Ordinary Queue.
		Durable	No	Set whether to persist the Queue, enabled by default. If set to true, the Queue still exists after service restart. If set to false, the Queue will be deleted after service restart and needs to be rebuilt.
		Node	Yes	In the dropdown list, select the node of the Queue cluster.
		AutoDelete	No	Whether to enable auto-delete for the Queue, off by default. If set to true, the Queue will be automatically deleted when the last consumer subscribing to Queue messages unsubscribes. If set to false, the Queue will not be deleted when the last consumer subscribing to Queue messages unsubscribes.
		Queue Description	No	Fill in the Queue description, up to 128 characters.
Common Parameters	Message TTL	No	The time to live of messages in the Queue, in milliseconds. If the TTL is exceeded and the message hasn't been successfully consumed, then: If a dead letter Exchange is specified, the message will be sent to the dead letter Exchange. If a dead letter Exchange is not specified, the message will be discarded.
		Auto Expire	No	The idle survival time of a Queue. If the Queue has no consumer connection, no message consumed or published within a specified time, it will be automatically deleted.
		Max Length	No	The Queue can hold messages up to the capacity limit. Exceeding the set value will trigger the Overflow policy.
		Max Length Bytes	No	The Queue's storage capacity limit triggers the Overflow policy when exceeding the set value.
		Overflow Behaviour	No	When the Queue capacity reaches the upper limit, the message processing policy: drop-head: drop the message at the head of the queue when the capacity limit is reached. reject-publish: deny new message release and mark the release operation as fail when the queue reaches capacity limit. reject-publish-dlx: When the queue reaches its capacity limit, reject new message publishing and send messages to the Dead Letter Exchange (dlx). If no Dead Letter Exchange is configured, automatically designate the default Exchange named AMQP default Exchange.
		dead letter Exchange	Yes	The message size exceeds the TTL time and is not successfully consumed, it will be sent to the dead letter Exchange, designated by default as the AMQP default Exchange.
Other advanced options	Single Active Consumer	No	Whether single active consumer is enabled, off by default. If set to true, the Queue only allows one consumer to consume messages at the same time. Other consumers remain on standby. When the active consumer disconnects, the next consumer is automatically selected. Suitable for sequential-sensitive tasks such as order status change.
		Maximum Priority	No	Configure the maximum priority of messages in the queue. Optional range: [0, 255]. A higher value results in larger sorting overhead. After configuring this parameter, the priority feature is enabled. When the producer sends messages, it specifies the priority (between 0 and Maximum Priority) through the priority attribute. High-priority messages are consumed first. Messages without a priority set default to 0. Applicable to scenarios such as VIP customer order priority handling and emergency task preemption.
		Lazy Mode	No	Whether lazy mode is enabled, off by default. If set to true, the queue will prioritize saving pushed messages on disk to reduce memory usage, loading them to memory only when consuming. Suitable for queues with severe message backlog, such as dead letter queue. If set to false, messages are stored in memory by default.
		Master Locator	No	When a mirrored queue is configured, the allocation method of the master node location. min-masters (default): When a mirrored queue is configured, select the node with the least number of managed queue masters as the location of the current queue master. It is recommended to keep the default min-masters in a production environment to achieve load balancing. client-local: When a mirrored queue is configured, select the node that the client declaring the queue connects to as the location of the current queue master. random: When a mirrored queue is configured, select a random node as the location of the current queue master.

tencent cloud

Restrictions and Limitations

Prerequisites

Operation Steps