消息积压处理
我们现有的业务就面临此问题，消息生产太快，消费不过来，导致队列堆积很长，把服务器内存耗尽，这时RabbitMQ的处理能力很低下。
总结起来解决方案大体包括：
- 增加消费者的处理能力，或减少发布频率，增加消费端实例。说白了就是增加机器。
- 如果申请机器行不通，毕竟公司的机器是有限的，此时可以增加消费端的消费能力。在MQ的配置中配置"最大消费者数量"与"每次从队列中获取的消息数量"
- 考虑使用队列最大长度限制，RabbitMQ 3.1支持
- 给消息设置年龄，超时就丢弃
- 发送者发送流量太大上线更多的消费者，紧急上线专门用于记录消息的队列，将消息先批量取出来，记录数据库，离线慢慢处理
这也是实现了柔性事务-可靠消息+最终一致性解决方案
做好消息确认机制（生产者、消费者）+手动确认机制
消息丢失处理
RabbitMQ的事务:事务可以保证消息100%传递，可以通过事务的回滚去记录日志，后面定时再次发送当前消息。事务的操作，效率太低，加了事务操作后，比平时的操作效率的至少要慢250倍。 RabbitMQ除了事务，还提供了Confirm的确认机制，这个效率比事务高很多。
- 普通Confirm方式。
- 批量Confirm:
3.异步Confirm:
Return机制：
Confirm只能保证消息到达exchange，无法保证消息可以被exchange分发到指定queue。而且exchange是不能持久化消息的，queue是可以持久化消息。 采用Return机制来监听消息是否从exchange送到了指定的queue中。
在业务环境下也有可能又这几种情况：
1、只要订单完成我们就会发送一条消息给MQ，这个途中突然MQ服务器网络中断，导致消息无法抵达
做好容错方法需要在消息发送前加上异常处理；
还可以将消息存入数据库，把失败的消息定期重新再发一遍
2、当消息发送给MQ，通过Brock通过交换机抵达队列，MQ关机了，只有抵达队列才能实现消息持久化
这时候需要使用生产者的确认机制（Confirm,Return）
3、自动ACK的状态下。消费者收到消息，但没来得及消息然后宕机
一定开启手动ACK，消费成功才移除，失败或者没来得及处理就NoAck并重新入队
本网站是一个以CSS、JavaScript、Vue、HTML为核心的前端开发技术网站。我们致力于为广大前端开发者提供专业、全面、实用的前端开发知识和技术支持。 在本网站中，您可以学习到最新的前端开发技术，了解前端开发的最新趋势和最佳实践。我们提供丰富的教程和案例，让您可以快速掌握前端开发的核心技术和流程。 本网站还提供一系列实用的工具和插件，帮助您更加高效地进行前端开发工作。我们提供的工具和插件都经过精心设计和优化，可以帮助您节省时间和精力，提升开发效率。 除此之外，本网站还拥有一个活跃的社区，您可以在社区中与其他前端开发者交流技术、分享经验、解决问题。我们相信，社区的力量可以帮助您更好地成长和进步。 在本网站中，您可以找到您需要的一切前端开发资源，让您成为一名更加优秀的前端开发者。欢迎您加入我们的大家庭，一起探索前端开发的无限可能!