RabbitMQ 可靠性、重复消费，java底层原理

public class RabbitMQConfig {

@Autowired

private RabbitTemplate rabbitTemplate;

@PostConstruct

public void enableConfirmCallback() {

//confirm 监听，当消息成功发到交换机 ack = true，没有发送到交换机 ack = false

//correlationData 可在发送时指定消息唯一 id

rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> {

if(!ack){

//记录日志、发送邮件通知、落库定时任务扫描重发

}

});

//当消息成功发送到交换机没有路由到队列触发此监听

rabbitTemplate.setReturnsCallback(returned -> {

//记录日志、发送邮件通知、落库定时任务扫描重发

});

}

}

测试的时候可以在发送消息时故意写错交换机、路由键的名称，然后就会回调到我们刚刚写的监听方法， cause 会给我们展示具体没有发到交换机的原因；returned 对象中包含了消息相关信息。

实际上据我了解一些企业并不会在这两个监听里面去做重发，为什么呢？成本太高了…首先 RabbitMQ 本身丢失的可能性就非常低，其次如果这里需要落库再用定时任务扫描重发还要开发一堆代码，分布式定时任务…再其次定时任务扫描肯定会增加消息延迟，不是很有必要。真实业务场景是记录一下日志就行了，方便问题回溯，顺便发个邮件给相关人员，如果真的极其罕见的是生产者弄丢消息，那么开发往数据库补数据就行了。

RabbitMQ 弄丢消息

========================================================================

不开启持久化的情况下 RabbitMQ 重启之后所有队列和消息都会消失，所以我们创建队列时设置持久化，发送消息时再设置消息的持久化即可（设置 deliveryMode 为 2 就行了）。一般来说在实际业务中持久化是必须开的。

消费者弄丢消息

==================================================================

所谓消费端弄丢消息就是消费端执行业务代码报错了，那么该做