消息队列-Rabbitmq

Rabbitmq 服务流程

• 由图，Producer端可以注册ConfirmListener和ReturnListener 分别对发出去的消息的反馈做相对应的处理。这种机制可以完成很多的功能。例如限流等等。

如何保障消息的可靠性投递

什么是生产端的可靠性投递

• 保障消息成功发送出去
• 保障mq节点成功接收消息
• 消息发送端需要收到mq服务的确认应答
• 完善的消息补偿机制（百分百成功成功 需要该步骤）

方案一：消息落库

1. 我们会先将业务数据和发送的消息体入库，这里要使用分布式事务。
2. 发送消息，如果通过confirm机制知道已经被签收，我们修稿信息状态，未被签收，就重新发送。
3. 我们有一个定时器，会一段时间去查看数据状态，如果还是未被签收，那么就会重发。

方案二：延时投递

• 通过延时的检查，来判断是否被签收。

幂等性以及消息的幂等性

• 接口的幂等性
  简而言之，就是对接口发起的一次调用和多次调用，生产的结果都是 一致的。

• 保障幂等性重要性
  案例一:比如订单提交的过程中，用户点了一次提交，但是由于网络等原因，导致后端处理延时，客户就连 续点击了多次，在没有幂等性的条件下，那么就会造成订单的重复提交。

• 方案：
  在保存订单的时候，根据生成的系统全局唯一ID(这里订单号+业务类型),并且把该唯一ID 调用 redis 的setnx命令保存起来，在第一次保存的时候，由于redis中没有该key,那么就会 把全局唯一ID 进行设置上，此时订单就会保存成功，。这个时候若出现前端重复点击按钮, 由于第一步已经 setnx上了 就会阻止后面的保存。

消息的确认Confirm

1. 消息的确认是指，生产端投递消息后，若mq-server接受到消息，就会给生产者一个应答
2. 生产端根据mq broker返回应答来确认该条消息是否正常发送到了broker,这种方式是消息可靠性投递的核心保障

如何来做消息的confirm

• 第一步:在channel上开启确认模式 channel.confirmSelect();
• 第二步;在channel上增加confirm监听，来监听成功和异常的confirm结果

return listener 消息处理机制

• 我们的消息生产者，通过把消息投递到exchange上，然后通过routingkey 把消息路由到某一个队列上，然后我们 消费者通过队列消息侦听，然后进行消息消费处理.
  以上会出现下面的情况

1. broker中根本没有对应的exchange交换机来接受该消息
2. 消息能够投递到broker的交换机上，但是交换机根据routingKey 路由不到某一个队列上.

针对上述二种情况 我们就需要return listener来处理这种不可达的消息.

• 处理一；若在消息生产端 的mandatory设置为true 那么就会调用生产端ReturnListener 来处理。
• 处理二；若消息生产端的mandatory设置为false(默认值也是false) 那么mq-broker就会自动删除消息。

消费端限流量

• 什么是消费端的限流
  场景:首先，我们迎来了订单的高峰期，在mq的broker上堆积了成千上万条消息没有处理，这个时候，我们随便打开了 消费者，就会出现下面请 如此多的消息瞬间推送给消费者，我们的消费者不能处理这么多消息 就会导致消费者出现巨大压力，甚至服务器崩溃

• 解决方案
  rabbitmq 提供一个钟qos（服务质量保证）,也就是在关闭了消费端的自动ack的前提 下，我们可以设置阈值（出队）的消息数没有被确认（手动确认），那么就不会推送 消息过来.

死信队列

• 什么是死信?

  就是在队列中的消息如果没有消费者消费，那么该消息就成为一个死信，那这个 消息被重新发送到另外一个exchange上的话，那么后面这个exhcange就是死信队列。

• 消息变成死信的几种情况

  • 消息被拒
  • 消息TTL过期

• 死信队列也是一个正常的exchange,也会通过routingkey 绑定到具体的队列上。