- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Development Guide
- Practical Tutorial
- API Documentation
- SDK Documentation
- FAQs
- General References
- Service Level Agreement
- Contact Us
- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Development Guide
- Practical Tutorial
- API Documentation
- SDK Documentation
- FAQs
- General References
- Service Level Agreement
- Contact Us
Avoid Creating a Connection/Channel for Every Message Sent
Creating a connection in RabbitMQ is a time and resource-intensive operation, with each connection consuming at least 100 KB of memory. Too many connections can put significant memory pressure on the Broker. It is recommended to create a connection when the program starts and reuse this persistent connection for each message sent, improving sending performance and reducing memory usage on the server side.
Channels are a more lightweight communication method. It is recommended to maximize the use of channels to reuse connections. However, using the same channel concurrently across threads is not recommended, as many RabbitMQ clients do not implement thread-safe channels.
Setting a Reasonable Send Timeout Period for the Producer
Different RabbitMQ clients across various languages and versions have different default send timeout settings, with some clients having excessively long default timeout periods, such as 580 seconds or 900 seconds. During network exceptions, excessively long send timeout periods can block the sender thread and even cause an avalanche effect. It is recommended to set a reasonable timeout period according to the business scenario, with 3 seconds being a recommended value.
Using Separate Connections for Producers and Consumers
Due to RabbitMQ's unique flow control mechanism, if the producer and consumer reuse the same physical connection and the consumption traffic is high enough to trigger flow control, the producer may be throttled, causing slow sending or timeout. Therefore, it is recommended that producers and consumers use separate physical connections during initialization to avoid mutual interference.
Avoiding Automatic Message Acknowledgment for Consumers
The RabbitMQ server provides semantics delivered at least once to ensure that messages are correctly delivered to the downstream business system. Once the consumer enables automatic acknowledgment, the server will automatically confirm and delete the message after it is pushed to the consumer. This occurs even when the consumer encounters an exception during processing, which prevents retries and may lead to message loss in the business logic.
Implementing Idempotent Processing of Messages for Consumers
The RabbitMQ server provides semantics delivered at least once, which may result in duplicate message delivery in extreme scenarios. Therefore, it is recommended to implement idempotent processing for critical business messages to avoid negative business impacts from duplicated messages.
The business idempotent processing can be implemented by including a unique business identifier in the message, with the consumer checking this identifier and the message status during consumption. This ensures that duplicate messages do not negatively affect the business.
Limiting the Queue Length to Avoid Message Backlog
Excessively long queues (with a large number of message heap) consume a significant amount of memory and system resources. This not only extends the time required for status synchronization during runtime but also greatly increases the Broker's startup recovery time.
Shorter queues provide faster processing speed and better system performance.
Therefore, clients need to maximize consumption ability and improve queue dimension limits, such as setting the
max-length, to keep queues as short as possible.Using Consume or Get for Message Consumption
Get is a polling-based pull mode consumption method. Each time a message is consumed, a request is sent to the Broker. If there are no messages in the queue, it may lead to many unnecessary empty pulls, causing resource occupancy. In contrast, Consume allows receiving a batch of messages at once, with the server pushing messages based on current conditions. In most cases, Consume should be used instead of Get to consume messages.
If your business logic requires to use Get to consume messages, pay attention to the business-level Get mechanism to avoid continuous Get Empty (where the queue is empty but the consumer keeps making Get requests), which can lead to abnormally high CPU load on the server.
Setting a Reasonable Prefetch Count for Consumers
Prefetch settings allow the consumer to preemptively fetch messages into the consumer cache to improve consumption throughput, reducing wait time and delay. However, if the Prefetch Count is too large or unlimited, it can lead to a large number of messages being cached in the consumer, and the server Broker also has to maintain the status of unacknowledged messages in memory, consuming substantial resources. If messages remain in the unacknowledged status for too long, they cannot be consumed by other idle consumers, increasing consumption delay or causing a load imbalance.
It is recommended to set the Prefetch Count within a reasonable range based on the business consumption rate.
Setting a Reasonable Exception Processing Policy for Consumers
When consumers encounter exceptions while consuming messages that they cannot process, and automatic acknowledgment is not enabled, message retries will be triggered. If the exceptions cannot be processed properly, it will result in infinite message retries, causing high load on the Broker and preventing subsequent messages from being consumed appropriately.
Client Reconnection Mechanism Confirmation
In extreme scenarios such as OOM or container host failures, the server Broker will heal itself and restart. Routine business operations, such as cluster configuration upgrades, can also trigger Broker restarts. To avoid continuous connection exceptions during Broker restarts, ensure that the client implements an automatic reconnection mechanism.
Avoiding Disabling Heartbeat Settings for Client SDKs
The heartbeat have a configuration value on both the server side and client side (with the server set to 60 seconds). The effective heartbeat is negotiated between the server and client, and the negotiation mechanism varies by client language/version. Setting the client heartbeat to 0 disables heartbeat detection, causing the server to be unable to automatically remove long-term inactive connections. This can lead to unexpected connection leaks.
Yes
No
Was this page helpful?