当前插件的设计不适用于大量延迟消息（未调度的消息达数十万甚至数百万条）的场景，生产环境请谨慎评估消息量级，避免非预期的长时间延迟、消息丢失等问题。
延时消息在每个节点上只有一个持久化副本，如果节点无法正常运行（例如由于消息堆积导致持续 OOM 后重启且无法恢复），则该节点上的延时消息无法被消费端消费。
延时交换机不支持设置 mandatory ，生产者无法通过 basic.return 事件感知到无法路由的消息，因此发送延时消息前请务必保证对应的交换机、队列、路由关系存在。
综上所述，我们强烈建议您不要使用这一插件，转而使用死信队列来间接实现延时消息。如果您在了解了这个插件的若干缺陷后仍然要使用，那我们强烈推荐您将延迟消息数量保持在一个尽可能低的水平，避免触发内存负载高的问题。

网络分区

网络分区是在使用 RabbitMQ 时不得不面对的一个问题。网络分区会带来集群状态的不一致，即使是网络恢复后，RabbitMQ 仍需通过重启 Broker 的方式来重新同步状态。RabbitMQ 目前使用的 autoheal 模式，它会自动决出一个获胜的分区，然后重启非信任分区内的 Broker。
建议客户端做好以下措施，尽可能减小网络分区带来的负面影响：
- 消息发送方，考虑发送消息时配合使用 mandatory 机制并有处理 basic.return 的能力，以便及时处理网络分区时可能出现的消息路由失败。
- 消息消费方，网络分区出现/处理过程中，可能会伴有消息重复，消费端需要做好幂等处理。

告警配置

云平台提供了集群/节点等多维度的监控指标，详情请见监控告警。
强烈建议重点关注节点 CPU、内存、磁盘利用率、堆积消息数量等几个指标并配置告警，避免服务端持续负载过高影响集群稳定性。