RabbitMQ消息可靠性问题

可靠性问题的几种解决方案

可靠性的几种方案

• 事务(性能较差，不推荐)
• 开启confirm(推荐)
• 开启持久化(交换机，队列，消息)
• 使用手动ack机制(默认是自动的)

保证消息的不重复消费(幂等)的几种方案

• 顺序消费
• 消息重试机制
• 延时和死信队列
• 分布式事务

RabbitMQ的消息可靠性，一般是业务系统接入消息中间件时首要考虑的问题，一般通过三个方面保障
发送可靠性： 确保消息成功发送到Broker
存储可靠性： Broker对消息持久化，确保消息不会丢失
消费可靠性： 确保消息成功被消费

消息发送可靠性

一般消息发送可靠性分为三个层级

• At most once：最多一次，消息可能会丢失，但绝不会重复传输
• At least once：最少一次，消息绝不会丢失，但可能会重复传输
• Exactly once：恰好一次，每条消息肯定会被传输一次且仅传输一次

RabbitMQ支持其中的“最多一次”和“最少一次”

其中“最少一次”投递实现需要考虑以下这几个方面的内容：

• 消息生产者需要开启事务机制或者publisher confirm机制，以确保消息可以可靠地传输到RabbitMQ中。
• 消息生产者需要配合使用mandatory参数或者备份交换器来确保消息能够从交换器路由到队列中，进而能够保存下来而不会被丢弃。

“最多一次”的方式就无需考虑以上那些方面，生产者随意发送，不过这样很难确保消息会成功发送。

消息积压的解决

当消费者产生意外情况，导致部分机器不可用，很容易造成消费能力不足，导致消息积压，因此一般配套监控和告警功能来进行通知，从而解决消息积压的问题。
但是当异常情况出现时，此时触发保护机制，会拒绝接收生产端的消息，此时可以先调整阈值，将默认的保护阈值从0.4调高，让mq先活过来，再通过增加消费者来处理消息积压问题。

订单超时的处理

当一个消息一直不被消费，可以将消息移到死信队列中，死信队列可以接受正常队列的数据，可以将订单放进正常队列中，同时设置一个超时时间，当超时以后将消息放进死信队列，进行处理，比如修改订单状态为已超时等。