RabbitMQ如何确保消息发送和消息接收

核心概念
在mq领域中，producer（消息生产者）将msg发送到queue（消息的载体），然后consumer（消息消费者）通过消费queue（消息的载体）完成PC解耦
rabbitmq是由Exchange（消息交换机）决定msg应该怎么样发送到目标queue（消息的载体），这就是binding（绑定）及对应的策略
消息发送确认
1ConfirmCallback方法
ConfirmCallback是一个回调接口，消息发送到Broker后触发回调，确认消息是否到达Broker服务器，也就是只确认是否正确到达Exchange中。

2 ReturnCallback方法
通过实现ReturnCallback接口，启动消息失败返回，此接口是在交换器路由不到队列时触发回调，该方法可以不使用，因为交换器和队列是在代码里绑定的，如果消息成功投递到Broker后几乎不存在绑定队列失败，除非你代码写错了。

消息接收确认

RabbitMQ消息确认机制(ACK)默认是自动确认的，自动确认会在消息发送给消费者后立即确认，但存在丢失消息的可能，如果消费端消费逻辑抛出异常，假如你用回了也只是保证了数据的一致性，但是消息还是丢了，也就是消费端没有处理成功这条消息，那么就相当于丢失了消息。

防止丢失消息，自己加表记录状态用cron去跑，如果没有成功，重发消息

堆积场景
1.消息拒绝，重新入队->死信队列/日志
2.消费慢->优化程序/集群消费
3.队列容量不够->扩容

先说为什么会重复消费:正常情况下，消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除;但是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将消息分发给其他的消费者。

针对以上问题，一个解决思路是:保证消息的唯一性，就算是多次传输，不要让消息的多次消费带来影啊保证消息等幂性:
比如:在写入消息队列的数据做唯一标示，消费消息时，根据唯一标识判断是否消费过;
假设你有个系统，消费一条消息就往数据库里插入一条数据，要是你一个消息重复两次，你不就插入了两条，这数据不就错了?但是你要是消费到第二次的时候，自己判断一下是否已经消费过了，若是就直接扔了，这样不就保留了一条数据，从而保证了数据的正确性。