rabbitmq_delayed_message_exchange 插件实现的延迟消息
1. 当前插件的设计不适用于大量延迟消息（未调度的消息达数十万甚至数百万条）的场景，生产环境请谨慎评估消息量级，避免非预期的长时间延迟、消息丢失等问题。
2. 延时消息在每个节点上只有一个持久化副本，如果节点无法正常运行（例如由于消息堆积导致持续 OOM 后重启且无法恢复），则该节点上的延时消息无法被消费端消费。
3. 延时交换机不支持设置 mandatory ，生产者无法通过 basic.return 事件感知到无法路由的消息，因此发送延时消息前请务必保证对应的交换机、队列、路由关系存在。
综上所述，我们强烈建议您不要使用这一插件，转而使用死信队列来间接实现延时消息。如果您在了解了这个插件的若干缺陷后仍然要使用，那我们强烈推荐您将延迟消息数量保持在一个尽可能低的水平，避免触发内存负载高的问题。
网络分区
1. 网络分区是在使用 RabbitMQ 时不得不面对的一个问题。网络分区会带来集群状态的不一致，即使是网络恢复后，RabbitMQ 仍需通过重启 Broker 的方式来重新同步状态。腾讯云 RabbitMQ 目前使用的 autoheal 模式，它会自动决出一个获胜的分区，然后重启非信任分区内的 Broker。
2. 建议客户端做好以下措施，尽可能减小网络分区带来的负面影响：
消息发送方，考虑发送消息时配合使用 mandatory 机制并有处理 basic.return 的能力，以便及时处理网络分区时可能出现的消息路由失败。
消息消费方，网络分区出现/处理过程中，可能会伴有消息重复，消费端需要做好幂等处理。
告警配置
消息轨迹使用限制
消息查询的实现原理概述：腾讯云控制台打开 VHost 的 Trace 插件后，服务端组件会消费对应 RabbitMQ 集群的轨迹消息，通过一系列处理后可实现控制台查询消息轨迹的功能。
由上述原理，消息轨迹依赖于服务组件消费轨迹消息，由于服务组件为底层公共服务，无法保证大流量的 RabbitMQ 集群的轨迹消息可以被及时消费；如轨迹消息堆积，会造成集群内存负载高等问题，影响 RabbitMQ 集群稳定性。
因此，不建议在生产环境尤其整体集群（包括所有 VHost）发送 TPS 超过 1000 的场景下开启 Trace 插件，Trace 插件建议使用在小流量验证/排查问题场景，不建议在生产环境使用。
