RabbitMQ消息积压比较厉害，然后突然丢弃
RabbitMQ中的消息积压陡降通常表明某些突发事件或操作已经显著减少了队列中的消息数量。这种现象可能由多种原因引起，以下是一些可能的原因及其解释：
- 消费者处理速度突然增加
原因: 你的消费者（消费者应用或服务）可能在某个时间点突然加快了消息处理速度。这可能是由于增加了消费者实例，提升了消费者处理能力，或者优化了消费者代码。
解决方案: 检查最近是否有任何与消费者相关的更改或调整，例如部署了新的消费者实例或修改了代码。
- 消费者重新启动或恢复
原因: 如果消费者之前处于停滞或休眠状态，当它们重新启动或恢复正常运行时，会迅速处理积压的消息。
解决方案: 检查消费者的运行状态日志，看看是否有任何重新启动或恢复的记录。
- 队列中的消息被清空或删除
原因: 有人可能手动清空或删除了队列，导致消息积压陡降。
解决方案: 检查RabbitMQ管理控制台或相关日志，看看是否有任何清空或删除队列的操作记录。
- 消息过期或被丢弃
原因: 如果你的消息有TTL（Time-To-Live）设置，超过存活时间的消息会被自动丢弃，从而导致积压陡降。
解决方案: 检查队列的TTL设置以及是否有消息过期的情况。
- 消息被重新路由到死信队列
原因: 消息可能由于无法被正常处理而被重新路由到死信队列（Dead Letter Queue）。
解决方案: 检查是否有配置死信队列，并查看死信队列的状态和日志。
- 突发的消息消费需求
原因: 某个消费者可能突然需要大量处理消息，从而导致消息积压陡降。
解决方案: 检查系统或应用日志，看看是否有任何突发的消息处理需求。
排查步骤
检查消费者状态: 查看所有消费者的运行状态和日志，确认是否有消费者重新启动、恢复或优化。
查看RabbitMQ管理控制台: 检查是否有手动操作清空或删除队列，或者是否有过期消息被丢弃。
检查队列配置: 确认队列是否有TTL设置，以及是否有死信队列配置。
监控和日志: 查看相关的监控系统和日志，寻找异常事件或操作的痕迹。
- 消息 ready 总数
在 RabbitMQ 中，“消息 ready 总数” 指的是当前队列中已经准备好等待消费的消息数量。这些消息已经被生产者发布到队列中，并且满足了可以被消费者处理的条件，例如没有被其他消费者锁定并且满足了消费者的订阅条件（例如路由规则）。
具体来说，消息 ready 总数表示了当前处于队列中、等待消费者获取并处理的消息的数量。这个指标通常在监控和管理 RabbitMQ 队列时使用，帮助管理员和开发者了解当前队列的负载情况、消息处理速度以及潜在的性能问题。
如果消息 ready 总数较高，可能意味着消费者处理速度不足以跟上生产者发布消息的速度，或者消费者的某些操作（例如网络延迟、处理时间过长等）导致了消息积压。这时候可能需要考虑调整消费者的数量、增加消费者的处理能力，或者优化消费者的处理逻辑，以确保队列中的消息能够及时被处理。
总结来说，RabbitMQ 中的消息 ready 总数是一个重要的监控指标，用来衡量队列中处于可消费状态的消息数量，从而帮助管理者和开发者优化系统的性能和稳定性。
- 最终原因
定时任务批量生产消息，用于数据同步，部分数据处理发生异常，导致当批次消息消费失败，消息阻塞。
后续消息还在生产，导致消息积压。
积压之后么，客户端一直报错，MQ客户端最后和服务器连接失败——MQ client 挂了。
因为客户端不消费消息了，消息从 unAck 状态变为为 ready 状态，消息并未消失。
从新启动客户端之后，消息会从 ready 变为 unAck ,从新被客户端消费。
- 最终原因
