rabbitmq 多个消费者消费一个队列_RabbitMQ手动确认+重试+死信队列保证消费可靠性...

引言

RabbitMQ 消息的消费有两种确认模式： 自动确认和手动确认

自动确认：Broker(RabbitMQ 服务器)在将消息发送给消费者后即将消息从队列中删除，无论消费者是否消费成功。如果消费者消费时业务代码出现异常或者还未消费完毕时系统宕机，就会导致消息丢失。

手动确认：消费者消费完毕后手动地向 Broker 发送确认通知，Broker 收到确认通知后再从队列中删除对应的消息。

由于自动确认方式存在的缺陷，对于一些重要的消息，实际中一般采用手动确认的方式来保证消息业务的可靠性。

那么在手动确认方式下，消费者业务中具体如何保证消息的可靠性呢？ 下面我们介绍一种方式，即采用 重试 + 手动确认 + 死信队列 的方式来保证消费信息不丢失。

死信队列

死信(Dead Letter)，指无法被消费者正确地进行业务处理的消息，消费者消费时业务程序抛出了异常，其主要原因有两个。一、消息本身是有问题的(主要原因)，如付款消息中传递的银行卡号不存在。二、由于网络波动等原因，消费者依赖的第三方服务调用异常，如调用第三方接口失败，数据库由于无法获取连接访问失败等情况。对于这类消息，一般将其放入 RabbitMQ 的死信队列中，使用专门的消费者对死信进行处理，或者进行人工补偿。

死信队列的消息来源

1、消息被否定确认使用 channel.basicNack 或 channel.basicReject ，并且此时requeue 属性被设置为false。

2、消息在队列中的时间超过了设置的TTL(time to live)时间。

3、消息数量超过了队列的容量限制。

当一个队列中的消息满足上述三种情况任一个时，该消息就会从原队列移至死信队列，若该队列没有绑定死信队列则消息被丢弃。

Tips：死信队列和普通的业务队列完全一样，只不过是业务上创建用来存储处理失败的消息的队列。所以其工作方式也和业务队列相同，死信仍然需要交换机的转发到达死信队列。

死信队列的配置

1、为业务队