RabbitMQ小结

MQ的作用

异步处理 - 相比于传统的串行、并行方式，提高了系统吞吐量。

应用解耦 - 系统间通过消息通信，不用关心其他系统的处理。

流量削锋 - 可以通过消息队列长度控制请求量；可以缓解短时间内的高并发请求。

日志处理 - 解决大量日志传输。

消息通讯 - 消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实 现点对点消息队列，或者聊天室等。

 

MQ的缺点

1. 系统可用性降低 本来系统运行好好的，现在你非要加入个消息队列进去，那消息队列挂了，你的系统不是呵 呵了。因此，系统可用性会降低；

2. 系统复杂度提高 加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消 费、如何保证消息可靠性传输等。因此，需要考虑的东西更多，复杂性增大。

3. 一致性问题 A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三 个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致 了。

MQ两大问题之一消息顺序

　　解决：保证生产者 - MQServer - 消费者是一对一对一的关系。

　　缺陷：并行度就会成为消息系统的瓶颈；更多的异常处理，比如：只要消费端出现问题，就会导致整个处理流程阻塞；

　　不关注乱序的应用实际大量存在 队列无序并不意味着消息无序 所以从业务层面来保证消息的顺序而不仅仅是依赖于消息系 统，是一种更合理的方式。

MQ两大问题之一消息重复

　　消费端处理消息的业务逻辑保持幂等性。只要保持幂等性，不管来多少条重复消息，最后处理的结 果都一样。

RabbitMQ基本组成

　　Broker： 简单来说就是消息队列服务器实体 Exchange：

　　消息交换机，它指定消息按什么规则，路由到哪个队列 

　　Queue： 消息队列载体，每个消息都会被投入到一个或多个队列

　　Binding： 绑定，它的作用就是把exchange和queue按照路由规则绑定起来

　　Routing Key： 路由关键字，exchange根据这个关键字进行消息投递

　　VHost：vhost 可以理解为虚拟 broker ，即 mini-RabbitMQ server。其内部均含有独立的 queue、exchange 和 binding 等，但最最重要的是，其拥有独立的权限系统，可以做到 vhost 范围的用户控制。当然，从 RabbitMQ 的全局角度，vhost 可以作为不同权限隔离的手段（一个典 型的例子就是不同的应用可以跑在不同的 vhost 中）。 Producer： 消息生产者，就是投递消息的程序 Consumer： 消息消费者，就是接受消息的程序 Channel： 消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话 任务 由Exchange、Queue、RoutingKey三个才能决定一个从Exchange到Queue的唯一的线路。

RabbitMQ的工作模式

　　1、simple模式（即最简单的收发模式）

　　　　

　　　　消息产生消息，将消息放入队列，消息的消费者(consumer) 监听 消息队列,如果队列中有消息,就消费掉,消息被拿走后,自动从队列中 删除(隐患 消息可能没有被消费者正确处理,已经从队列中消失了,造成消息的丢失，这里可以设置 成手动的ack,但如果设置成手动ack，处理完后要及时发送ack消息给队列，否则会造成内存溢 出)。

　　2、work工作模式(资源的竞争)

　　　　

　　　　消息产生者将消息放入队列消费者可以有多个,消费者1,消费者2同时监听同一个队列,消息被消费。C1 C2共同争抢当前的消息队列内容,谁先拿到谁负责消费消息(隐患：高并发情况下,默认会产生某一个消息被多个消费者共同使用,可以设置一个开关(syncronize) 保证一条消息只能被一个消费者使用)。

　　3、publish/subscribe发布订阅(共享资源)

　　

　　　　每个消费者监听自己的队列；生产者将消息发给broker，由交换机将消息转发到绑定此交换机的每个队列，每个绑定交换机的 队列都将接收到消息。

　　4、routing路由模式

　　　　

　　　　消息生产者将消息发送给交换机按照路由判断,路由是字符串(info) 当前产生的消息携带路由字符 (对象的方法),交换机根据路由的key,只能匹配上路由key对应的消息队列,对应的消费者才能消费消 息;

　　　　根据业务功能定义路由字符串

　　　　从系统的代码逻辑中获取对应的功能字符串,将消息任务扔到对应的队列中。

　　　　业务场景:error 通知;EXCEPTION;错误通知的功能;传统意义的错误通知;客户通知;利用key路由,可 以将程序中的错误封装成消息传入到消息队列中,开发者可以自定义消费者,实时接收错误;

　　5、topic 主题模式(路由模式的一种)

　　　　

　　　　星号井号代表通配符

　　　　星号代表多个单词,井号代表一个单词

　　　　路由功能添加模糊匹配

　　　　消息产生者产生消息,把消息交给交换机

　　　　交换机根据key的规则模糊匹配到对应的队列,由队列的监听消费者接收消息消费 （在我的理解看来就是routing查询的一种模糊匹配，就类似sql的模糊查询方式）

消息如何路由

　　消息提供方->路由->一至多个队列消息发布到交换器时，消息将拥有一个路由键（routing key）， 在消息创建时设定。通过队列路由键，可以把队列绑定到交换器上。消息到达交换器后， RabbitMQ 会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）； 常用的交换器主要分为一下三种：

1. fanout：如果交换器收到消息，将会广播到所有绑定的队列上

2. direct：如果路由键完全匹配，消息就被投递到相应的队列

3. topic：可以使来自不同源头的消息能够到达同一个队列。 使用 topic 交换器时，可以使用通配符

消息基于什么传输

　　由于 TCP 连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ 使用信道的方式来传输数据。信道是建立在真实的 TCP 连接内的虚拟连接，且每条 TCP 连接上的 信道数量没有限制。

保证RabbitMQ消息的可靠传输

　　1、生产者确认模式RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。消息发送到MQ以后，会返回一个结果给发送者，表示消息是否处理成功。结果有两种请求： publisher-confirm，发送者确认 消息成功投递到交换机，返回ack 消息未投递到交换机，返回nack publisher-return，发送者回执 消息投递到交换机了，但是没有路由到队列。返回ACK，及路由失败原因。

　　　　配置说明：

　　　　 publish-confirm-type：开启publisher-confirm，这里支持两种类型：

　　　　　　simple：同步等待confirm结果，直到超时

　　　　　　correlated：异步回调，定义ConfirmCallback，MQ返回结果时会回调这个ConfirmCallback

　　　　publish-returns：开启publish-return功能，同样是基于callback机制，不过是定义ReturnCallback template.mandatory：定义消息路由失败时的策略。true，则调用ReturnCallback；false：则直接丢弃消息

 

　　2、持久化

　　　　交换机持久化： 队列持久化： 消息持久化，SpringAMQP中的的消息默认是持久的，可以通过MessageProperties中的DeliveryMode来指定的。

　　3、消费者确认机制

　　　　RabbitMQ支持消费者确认机制，即：消费者处理消息后可以向MQ发送ack回执，MQ收到ack回执后才会删除该消息。

　　　　而SpringAMQP则允许配置三种确认模式：

　　　　　　manual：手动ack，需要在业务代码结束后，调用api发送ack。

　　　　　　auto：自动ack，由spring监测listener代码是否出现异常，没有异常则返回ack；抛出异常则返回nack

　　　　　　none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除

　　4、重试机制

　　　　当消费者出现异常后，消息会不断requeue（重新入队）到队列，再重新发送给消费者，然后再次异常，再次requeue，无限循环，导致mq的消息处理飙升，带来不必要的压力。我们可以利用Spring的retry机制，在消费者出现异常时利用本地重试，而不是无限制的requeue到mq队列。

 

　　　　在开启重试模式后，重试次数耗尽，如果消息依然失败，则需要有MessageRecoverer接口来处理，它包含三种不同的实现：

　　　　　　RejectAndDontRequeueRecoverer：重试耗尽后，直接reject，丢弃消息。默认就是这种方式

　　　　　　ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队

　　　　　　RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机

 

　　保证消息可靠总结总结：

　　　　开启生产者确认机制，确保生产者的消息能到达队列

　　　　开启持久化功能，确保消息未消费前在队列中不会丢失

　　　　开启消费者确认机制为auto，由spring确认消息处理成功后完成ack

　　　　开启消费者失败重试机制，并设置MessageRecoverer，多次重试失败后将消息投递到异常交换机，交由人工处理

死信交换机

　　当一个队列中的消息满足下列情况之一时，可以成为死信（dead letter）：

　　　　消费者使用basic.reject或 basic.nack声明消费失败，并且消息的requeue参数设置为false

　　　　消息是一个过期消息，超时无人消费

　　　　要投递的队列消息堆积满了，最早的消息可能成为死信

　　　　如果该队列配置了dead-letter-exchange属性，指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机称为死信交换机（Dead Letter Exchange，简称DLX）。

　　

 

 

什么样的消息会成为死信？

　　消息被消费者reject或者返回nack

　　消息超时未消费

　　队列满了

如何给队列绑定死信交换机？

　　给队列设置dead-letter-exchange属性，指定一个交换机

　　给队列设置dead-letter-routing-key属性，设置死信交换机与死信队列的RoutingKey

 

延迟队列

　　利用TTL（Time-To-Live）结合死信交换机，我们实现了消息发出后，消费者延迟收到消息的效果。这种消息模式就称为延迟队列（Delay Queue）模式。

　　延迟队列的使用场景包括：

　　延迟发送短信

　　用户下单，如果用户在15 分钟内未支付，则自动取消

　　预约工作会议，20分钟后自动通知所有参会人员

消息超时的两种方式是？

　　给队列设置ttl属性，进入队列后超过ttl时间的消息变为死信

　　给消息设置ttl属性，队列接收到消息超过ttl时间后变为死信

　　两者共存时，以时间短的ttl为准

如何实现发送一个消息20秒后消费者才收到消息？

　　给消息的目标队列指定死信交换机

　　消费者监听与死信交换机绑定的队列

　　发送消息时给消息设置ttl为20秒

SpringAMQP使用延迟队列插件

　　DelayExchange的本质还是官方的三种交换机，只是添加了延迟功能。因此使用时只需要声明一个交换机，交换机的类型可以是任意类型，然后设定delayed属性为true即可。

　　基于注解的实现

　　

　　基于java代码的实现

　　

 

　　然后我们向这个delay为true的交换机中发送消息，一定要给消息添加一个header：x-delay，值为延迟的时间，单位为毫秒：

延迟队列总结

　　延迟队列插件的使用步骤包括哪些？

　　　　声明一个交换机，添加delayed属性为true

　　　　发送消息时，添加x-delay头，值为超时时间

 

惰性队列

　　当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。最早接收到的消息，可能就会成为死信，会被丢弃，这就是消息堆积问题。

　　解决消息堆积有三种种思路：

　　　　增加更多消费者，提高消费速度

　　　　在消费者内开启线程池加快消息处理速度

　　　　扩大队列容积，提高堆积上限

　　从RabbitMQ的3.6.0版本开始，就增加了Lazy Queues的概念，也就是惰性队列。

　　惰性队列的特征如下：

　　　　接收到消息后直接存入磁盘而非内存

　　　　消费者要消费消息时才会从磁盘中读取并加载到内存

　　　　支持数百万条的消息存储

　　　　而要设置一个队列为惰性队列，只需要在声明队列时，指定x-queue-mode属性为lazy即可。可以通过命令行将一个运行中的队列修改为惰性队列：

　　　　"queue-mode":"lazy"

　　用SpringAMQP声明惰性队列分两种方式：

　　基于@Bean

　　

　　基于注解

　　

　　

如何保证高可用的？RabbitMQ 的集群 　　RabbitMQ 是比较有代表性的，因为是基于主从（非分布式）做高可用性的，我们就以 RabbitMQ为例子讲解第一种 MQ 的高可用性怎么实现。

　　RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。

1. 单机模式，就是 Demo 级别的，一般就是你本地启动了玩玩儿的?，没人生产用单机模式

2. 普通集群模式：意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你创建的 queue，只会放在一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操作。

3. 镜像集群模式：这种模式，才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是，在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。这样的好处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue的完整数据，别的 consumer 都可以到其它节点上去消费数据。坏处在于，第一，这个性能开销也太大了吧，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！RabbitMQ一个 queue 的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个 queue 的完整数据。