消息持久化
为了确保队列元数据和队列中的消息在 Broker 重启后不丢失，建议将队列设置为 durable、消息设置为 persistent，这样队列在接收到消息后会立即将其持久化到磁盘上。
非持久化的消息也会占用更多的服务端内存资源，极端情况下引起服务端内存负载过高。
发送端 Confirm
Confirm 机制可以确保消息被成功地发送到 Broker。但如果发送消息时不设置 mandatory，无论消息是否成功路由到目标队列，Broker 都会回应 confirm 给发送端。如果设置了 mandatory（延迟交换机不支持设置 mandatory），消息无法路由时 Broker 会将消息原路返回客户端，客户端可以通过实现 basic.return 的处理来感知这些无法路由的消息；消息可以成功路由到目标队列时，Broker 才会回应 confirm 给发送端。
消费端 Acknowledgement
消费端 ACK 机制可以确保客户端收到消息，提供了 at least once 级别的消费语义保证，确保消息被正确处理后才能被删除。但这也需要客户端做好幂等，避免重复消费消息引发错误，而且未被 ACK 的消息会堆积在内存中导致客户端和服务端内存占用增加。
开启镜像队列
镜像队列通过将队列数据复制到集群内其他 Broker 上来保证队列的高可用。配置镜像队列策略可能会增加 Broker 的启动时长和资源占用，但可以确保队列在单个 Broker 故障时仍处于可用状态，尽量确保不丢失消息。
配置镜像队列策略时，应避免设置 ha-sync-mode=automatic，该配置会引起服务端 Broker 重启后自动全量同步队列数据（无论队列数据是否被同步过）。如果同步的队列堆积数据过多，最终会导致 Broker 同步数据时间过长、持续占用内存资源等问题，且队列同步完成前队列处于不可用状态，对业务可用性、服务端稳定性都有严重影响。
