一、消息可靠投递

生产端的

在使用 RabbitMQ的时候，作为消息发送方希望杜绝任何消息丢失或者投递失败场景。

RabbitMQ 为我们提供了两种方式用来控制消息的投递可靠性模式。

• confirm 确认模式
• return 退回模式

rabbitmq整个消息投递的路径为:

producer--->rabbitmq broker--->exchange--->queue--->consumer

• 消从 producer到exchange 则会返回一个confirmCallback
• 消息从 exchange-->queue 投递失败则会返回一个returnCallback

我们将利用这两个callback 控制消息的可靠性投递

confirmCallback 

returnCallback 

二、Consumer Ack

消费端的

ack指acknowledge，确认。表示消费者接收到消息后的确认方式

三种：

• 自动确认: acknowledge="none
• 手动确认:acknowledge="manual
• 根据异常情况确认:acknowledge="auto"(这种方式使用麻烦，不作讲解)

自动确认是指，当消息一旦被Consumer接收到，则自动确认收到，并将相应 mesage 从 RabbitMQ的消息缓存中移除。但是在实际业务处理中，很可能消息接收到，业务处理出现异常，那么该消息就会丢失。

如果设置了手动确认方式，则需要在业务处理成功后，调用channel.basicAck0，手动签收，如果出现异常，则调用channel.basicNack0方法，让其自动重新发送消息。

1、自动确认

什么都不配置默认就是自动确认

2、手动确认

实现的不是messagelistener而是他的子接口，然后开启手动确认

3、小结

三、限流 

这样配置的话就是代表用了手动接收，然后每次只接收一条消息，手动确认之后才有下一条，如果去掉prefetch=“1”，那么一次就会把消息全部拉过来

在<rabbit:listener-container>中配置 prefetch属性设置消费端一次拉去多少消息
消费端的确认模式一定为手动确认，acknowledge="manual"

四、TTL

Time to Live（存活时间/过期时间）

当消息到达存活时间后，还没有被消费，会被自动清除

RabbitMQ可以对消息设置过期时间，也可以对整个队列设置过期时间

1、队列统一过期

配置好队列和交换机，设置好队列的过期时间 10秒

队列过期后，会统一的把全部消息都删除掉

消息过期后，只有消息在队列顶端，才会判断其是否过期然后马上删除，如果不是队列顶端的，只有消息被用到前才会判断是否过期，跟redis的惰性删除很像

2、消息单独过期

写完然后把这个匿名内部类当参数传入covertandsend里面： 

如果设置了消息的过期时间，也设置了队列的消息时间，以时间短的为主 

3、小结

• 设置队列过期时间使用参数: -message-ttl，单位: ms(毫秒)，会对整个队列消息统一过期
• 设置消息过期时间使用参数:expiration。单位:ms(毫秒)，当该消息在队列头部时 (消费时)，会单独判断这一消息是否过期。
• 如果两者都进行了设置，以时间短的为准

五、死信队列

别的mq没有exchange所有叫死信队列，但rabbitMQ有exchange所以也叫死信交换机

死信队列，DLX。Dead letter Exchange（死信交换机），当消息成为Dead message后，可以被重新发送到另一个交换机，这个交换机交DLX

如果一个消息过期了，没有被正常消费，如果绑定了死信队列，不会被丢弃而是发到死信交换机上重新发送给另一个队列，也可以绑定消费者。

什么消息会变死信（重点）

• 队列消息长度达到限制
• 消费者拒接消费消息，basicNack/basicReject，并且不把消息重新放入原目标队列，requeue=false
• 原队列存在消息过期设置，消息到达超时时间未被消费

队列绑定死信交换机：

给队列设置参数：x-dead-letter-exchange和x-dead-letter-routing-key

第一个参数就是设置死信交换机的名称，第二个参数就是死信队列绑定的routingkey

六、延迟队列

场景：现在要求用户下单之后，如果30分钟未支付，取消订单，回滚库存，支付了就不操作

实现方式：定时任务（不够优雅），延迟队列

RabbitMQ中未提供延迟队列的功能

但是，我们可以通过 TTL+DLX（死信队列）的方式来实现延迟队列的效果

我们可以定义一个队列过期时间为30分钟，绑定个死信交换机，然后没有消费者监听死信队列，不监听正常队列，就等他过期，过期了就会发送到私信交换机，死信交换机再发送给消费者。

七、优先级队列

优先级队列是按照优先级来优先执行，而不是按先进先出的顺序

 

八、惰性队列

惰性队列：消息保存在磁盘中，正常的队列是把消息存放在内存中

场景：当消费者宕机或者处于维护状态，导致长时间内不能消费而造成堆积的时候，惰性队列就很有必要了。

惰性队列的性能会比较低，占用内存很小。

九、应用问题

1、消息补偿机制

需求：要100%保证消息发送成功

首先生产者先把数据入库然后发送消息到队列1，如果消费者成功接收也入库，消费者接收到还要发送确认消息到队列2。生产者还会延迟发送消息给队列3，队列3和队列2的消息都会被监听到回调检查服务，如果他们的消息是不同的，队列3消息监听到发现2不在里面说明没有发成功，调用producer重新发送。如果发送消息和延迟发送都失败怎么办？还有个定时任务去定时检查回调数据库，看是否有数据没用就调用hseng

2、幂等性的保障

幂等性指的是一次或多次请求某一个资源，对于一个资源本身一个有相同的结果。

既任意多次执行对资源本身所产生的的影响均与一次的影响相同

MQ中：消费多条相同的消息，得到与消费改消息一次相同的结果

比如说我买东西画了500块，但是因为某些原因mq发了两条消息，要保证账户只扣500元

我们发消息的时候版本是1，重复发消息还是会是1多次发送还是1，但是我们只要有一个成功了，我们数据库的版本就会变成2，这样就算第二次1版本过来也和更新完的版本2不一样了失败。保证了幂等性。