一、如何保证生产者生产消息100%的投递成功
- 保障消息的成功发出
- 保障MQ节点的成功接收
- 发送端收到MQ节点（Broker）确认应答
- 完善的消息进行补偿机制
1. 理解Confirm确认消息机制
- 消息的确认，是指生产者投递消息后，如果Broker收到消息，则会给我们生产者一个应答。
- 生产者进行接收应答，用来确定这条消息是否正常的发送到了Broker,这种方式也是消息可靠性投递的核心保障！
1.1 Confirm确认消息流程解析
2. 理解Return消息机制
Return Listener 用于处理一些不可路由的消息！
我们的消息生产者，通过指定一个Exchange和RoutingKey把消息送达到某一个队列中去，然后我们的消费者监听队列，进行消费处理操作。
但是在某些情况下，如果我们在发送消息的时候，当前的exchange不存在或者指定的路由key路由不到，这个时候如果我们需要监听这种不可达的消息，就需要使用 Return Listener。
二、如何保证消费者消费消息成功
1.消费端的手工ACK和NACK
- 消费端进行消费的时候，如果由于业务异常我们可以进行日志的记录，然后进行补偿！
- 如果由于服务器宕机等严重问题，那我们就需要手工进行ACK，保障消费端消费成功
2.消费端的重回队列
- 消费端重回队列是为了针对没有成功处理掉消息，把消息重新投递给Broker
- 一般实际应用中，都会关闭重回队列，也就是设置为false。
三、如何保证MQ挂掉消息还在？
可以设置交换机、队列、消息的持久化。
四、消息的限流
1.什么事消费端限流
假设一个场景，我们的RabbitMQ服务器上有上万条未处理的消息，我们随便打开一个消费者客户端。会出现下面情况：
- 巨量的消息瞬间全部推送过来，但是我们单个客户端无法同时处理这么多数据！导致服务死掉。
RabbitMQ提供了一种qos（服务质量保证）功能，既在非自动确认消息的前提下，如果一定数目的消息（通过基于consume或者channel设置的Qos的值）未被确认前，不进行消费新的消息。
void basicQos(int prefetchSize, int prefetchCount, boolean global) throws IOException：- prefetchSize：0
- prefetchCount：告诉RabbitMQ不要同时给一个消费者推送多少条消息，既一旦有N个小希还没有ack，则该消费者将block掉，直到有消息ack
- global：true / false 是否将上面设置应用于 channel ，简单点来说，就是上面限制是 channel级别的，还是consumer(消费者)级别的。
五、延迟消息 延迟交换机（也就是说的定时消息）
常见的应用场景，比如商城下单，每个订单有个30分钟倒计时，30分钟到了后，关闭订单。
延迟消息、可靠性消息 都在下面代码中。