一、如何保证生产者生产消息100%的投递成功

1. 保障消息的成功发出
2. 保障MQ节点的成功接收
3. 发送端收到MQ节点（Broker）确认应答
4. 完善的消息进行补偿机制

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分钟到了后，关闭订单。

延迟消息、可靠性消息 都在下面代码中。

代码地址