tencent cloud

Feedback

Other Notes

Last updated: 2024-09-10 14:38:52

    Delayed Messages Implemented with rabbitmq_delayed_message_exchange Plugin

    1. The current design of the plugin is not suitable for scenarios involving a large number of delayed messages (hundreds of thousands or millions of unscheduled messages). Carefully assess the message throughput in the production environment to avoid unexpected long delays, message loss, and other issues.
    2. The delayed messages have only one persistent replica on each node. If a node fails to operate normally (for example, the message heap causes continuous OOM errors, leading to restarts and recovery failure), the delayed messages on that node cannot be consumed by the consumer side.
    3. The delay exchange does not support the mandatory option, so producers cannot be notified through the basic.return event about messages that could not be routed. Therefore, ensure the corresponding exchange, queue, and routing relationship exist before sending delayed messages.
    In summary, we strongly recommend against using this plugin and suggest using dead-letter queues to indirectly implement Delayed Message instead. If you still choose to use this plugin despite understanding its various drawbacks, it is strongly recommended to keep the number of delayed messages as low as possible to avoid triggering high memory load issues.

    Network Partition

    1. Network partition is an inevitable issue when using RabbitMQ. The network partition can lead to inconsistencies in the cluster status, and even after the network is recovered, RabbitMQ still requires a Broker restart to resynchronize the status. TDMQ for RabbitMQ currently uses the autoheal mode, which will automatically select a winning partition and then restart the Broker in the untrusted partition.
    2. Clients are recommended to take the following measures to minimize the negative impact of network partition:
    Message senders need to consider using the mandatory mechanism when sending messages and having the ability to process basic.return to promptly address message routing failures that may occur during processing networks partitions.
    Message consumers need to implement idempotency at the consumer end since there may be duplicate messages during partitioning networks and processing network partitions.

    Alarm Configuration

    Tencent Cloud provides monitoring metrics for various dimensions such as clusters and nodes. For details, see Monitoring and Alarms. It is strongly recommended to focus on key metrics such as CPU, memory, disk utilization, and message heap on each node, and to configure alarms to avoid continuous high server load that can affect the cluster stability.

    Message Track Usage Limit

    An overview of the implementation principle of message query: After the Trace plugin for a VHost is enabled in the Tencent Cloud console, the server-side components will consume the track messages of the corresponding RabbitMQ cluster. After a series of processes, the message track query feature can be enabled in the console. Based on the principle described above, the message track relies on the service components to consume track messages. Since the service components are underlying public services, they cannot ensure timely consumption of track messages for high-traffic RabbitMQ clusters. If track messages heap occurs, it may cause high memory load within the cluster, affecting the stability of the RabbitMQ cluster. Therefore, it is not recommended to enable the Trace plugin in the production environment, especially in scenarios where the overall cluster (including all VHosts) sending TPS exceeds 1,000. The Trace plugin is recommended to be used in low-traffic verification or troubleshooting scenarios instead of production environments.
    Contact Us

    Contact our sales team or business advisors to help your business.

    Technical Support

    Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

    7x24 Phone Support