RabbitMQ消息中间件的理解

时间 2019-11-13

标签 rabbitmq 消息中间件理解栏目 RabbitMQ 繁體版

原文原文链接

是什么：微服务之间的消息通讯方式

常见的消息中间件：

　　ActiveMQ：基于JMS

　　RabbitMQ：基于AMQP协议，erlang语言开发，稳定性好

　　RocketMQ：基于JMS，阿里巴巴产品，目前交由Apache基金会

　　Kafka：分布式消息系统，高吞吐量

MQ实现方式：AMQP （只是一种协议因此支持跨平台）与jms（必须是java语言）

好处：（转载---为何使用MQ说明： http://www.javashuo.com/article/p-rweywryn-cm.html ）

一、解耦，消费方只须要订阅读取消息便可

二、灵活性，峰值处理好

三、MQ的处理异步的，这样就提高了系统的处理性能。

四、可恢复性

五、顺序保证

六、缓冲能力，消息中间件像是一个巨大的蓄水池，将高峰期大量的请求存储下来慢慢交给后台进行处理，对于秒杀业务来讲尤其重要

缺点：

一、系统复杂度增长，考虑消息的重复问题，消息丢失问题。

二、通常消息中间件的服务崩溃了，涉及的相关系统就不可用了。

Rabbit 执行原理：

消息生产方推送消息到队列，消息放消费队列中的消息。（下图是基本消费模型）

消息模型：*******重要******

基本消息模型消息发送方 -----》队列 ------》一个消息消费方

work 消息模型消息发送方 -----》队列 ------》多个消息消费方

消息发送流程：

1）一个队列绑定多个消费者

2）消费者呈合做者分别处理一部分消息解决消息堆积问题。

发布订阅消息模型（该模型包含基本与work 消息模型的）： 消息发布方 -->交换机 -->队列 -->消息订阅方

1、Fanout：在广播模式下，消息发送流程是这样的：

1）消息生产方生产消息发送到交换机html
2）消费方监听queue（队列）java
3）队列与Exchange（交换机）绑定node
4）生产者发送的消息发送到交换机（在代码中将队列与交换机绑定就发送给对应队列，生产者没法决定）。面试
5）交换机把消息发送给绑定过的全部队列redis
6）队列中的消息被消费者监听到从而执行。实现一条消息被多个消费者消费spring

2、Direct：控制发布的消息的队列被哪些订阅方收到。

特色：消息生产方会指定routingKey 的关键字，这样交换机就会将消息发送给与该routingkey彻底匹配的队列。

例如：在路由模式中，咱们将添加一个功能 - 咱们将只能订阅一部分消息。例如，咱们只能将重要的错误消息引导到日志文件（以节省磁盘空间），同时仍然可以在控制台上打印全部日志消息。可是，在某些场景下，咱们但愿不一样的消息被不一样的队列消费。这时就要用到Direct类型的Exchange。

　　P：生产者，向Exchange发送消息，发送消息时，会指定一个routing key 如：rabbit 服务器

　　X：Exchange（交换机），接收生产者的消息，而后把消息递交给与routing key彻底匹配的队列网络

　　C1：消费者，其所在队列指定了须要routing key 为 error 的消息异步

　　C2：消费者，其所在队列指定了须要routing key 为 info、error、warning 的消息分布式

3、Topic模型 : 和Direct 同样。只是可使用通配符进行匹配(更加灵活通用)

上图中：Q1匹配全部的橙色动物。Q2匹配关于兔子以及懒惰动物的消息。

如下的routingKey 配置后哪些会进入Q1,Q2队列。

　　quick.orange.rabbit Q1 Q2

　　lazy.orange.elephant Q1 Q2

　　quick.orange.fox Q1

　　lazy.pink.rabbit Q2

　　quick.brown.fox 不匹配任意队列，被丢弃

面试热点：如下P方 = 消息生产方 C方 = 消息消费方

1、如何保证消息不丢失？ 问到过！

一、采用消费者消息确认机制（ACK），ACK分为手动和自动，

自动ACK：消费方接受到消息则队列中的消息就会被删除

手动ACK：若是在接受到消息后发生了错误抛异常这种状况应该使用手动确认相似手动启动关闭事务这样

二、采用生产者消息回执确认机制：

消息生产者交换机发送消息发送成功后，交换机回执ACK给消息生产者

2、若是MQ服务器挂掉怎么办？

一、搭建集群

二、将消息持久化，在spring集成中消息和队列以及交换机都是持久化的

3、如何解决队列中的消息积压过大？

work 消息模型配置多台消息的消费方进行消费。

4、幂等性（如何解决消息被重复执行）：问到过！

消息被重复发送，例以下订单我点了两次也许是网络缘由点了2次。

发生缘由：当交换机回执ACK给P方时，因为网络故障致使生产方未收到消息，当网络恢复

P方没有收到ACK回执则从新发送一条消息致使消息重复。

解决方案：

给消息设置惟一ID，判断该消息被消费过，而后再业务方进行去重。

实现方式两种：

一、在ZK中建立node 当判断是否重复的时候就去建立node 若是存在建立会报错。

二、使用redis 当放入MQ后就往redis 中存入一个惟一id 判断重复的时候就去看看是否存在，存在即重复。

5、延迟队列实现方式：问到过！

场景介绍：商品订单超过半小时自动删除。

解决方案：（经过TTL死信与 DLX 死信队列实现。）

一、设置消息的有效期，例如30Min，当超过该效期，则该信息变为死信（TTL）

二、当出现死信，MQ提供对于死信处理的死信队列，例如当订单超过半小时，则将消息放入死信队列，而后由绑定死信队列的消费方进行处理，从而将订单删除。（DLX）这样就利用了MQ的特性实现了延迟队列。

扩展：通常死信处理状况有三种：

一、消息超时

二、消息被拒绝

三、队列达到最大长度