RabbitMQ

RabbitMQ

消息中间件的学习MQ

---

mq

---

前言

随着互联网的发展，在信息传输的过程中的通信成了大问题。列如mysql的每秒写入算力在1000条，那么当消息大于1000条时就会出现数据库的卡死无法正常的进行数据存储那么在数据传输的过程中能够有一个在过程中实现拦截分流的话就会好太多。那么这就是MQ出现的意义。

---

一、MQ的介绍

1.1MQ概述

• MQ全称Message Queue（消息队列），是在消息的传输过程中保存消息的容器。多用于分布式系统之间进行通信。

应用之间的远程调用

加入MQ后应用之间的调用

1.2MQ的优势

1、应用解耦

• MQ相当于一个中介，生产方通过MQ与消费方交互，它将应用程序进行解耦合。

1.系统的耦合性越高，容错性就越低，可维护性就越低
2.使用MQ使得应用之间解耦，提升容错性和可维护性

2、任务异步处理

• 将不需要同步处理的并且耗时长的操作由消息队列通知消息接收方进行异步处理。提高了应用程序的响应时间。

3、削峰填谷

• 如订单系统，在下单的时候就会往数据库写数据。但是数据库只能支撑每秒1000左右的并发写入，并发量再高就容易宕机。低峰期的时候并发也就100多个，但是在高峰期时候，并发量会突然激增到5000以上，这个时候数据库肯定卡死了

但是使用了MQ之后，限制消费消息的速度为1000，但是这样一来，高峰期产生的数据势必会被积压在MQ中，高峰就被“削”掉了。但是因为消息积压，在高峰期过后的一段时间内，消费消息的速度还是会维持在1000QPS，直到消费完积压的消息,这就叫做“填谷”

1.3MQ的劣势

• 系统可用性降低
• 系统复杂度提高
• 一致性问题

1.4 AMQP 和 JMS

• 实现MQ的大致有两种主流方式：AMQP、JMS。

1.4.1 AMQP

• AMQP，即 Advanced Message Queuing Protocol（高级消息队列协议），是一个网络协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，遵循此协议，不收客户端和中间件产品和开发语言限制。2006年，AMQP 规范发布。类比HTTP。

1.4.2 JMS

• JMS 即 Java 消息服务（JavaMessage Service）应用程序接口，是一个 Java 平台中关于面向消息中间件的API
• JMS 是 JavaEE 规范中的一种，类比JDBC
• 很多消息中间件都实现了JMS规范，例如：ActiveMQ。RabbitMQ 官方没有提供 JMS 的实现包，但是开源社区有

1.4.3 AMQP 与 JMS 区别

• JMS是定义了统一的接口，来对消息操作进行统一；AMQP是通过规定协议来统一数据交互的格式
• JMS限定了必须使用Java语言；AMQP只是协议，不规定实现方式，因此是跨语言的。
• JMS规定了两种消息模式；而AMQP的消息模式更加丰富

二、 RabbitMQ介绍

1、rabbitMQ概念介绍

• RabbitMQ 基础架构如下图：

RabbitMQ 中的相关概念：

• 1、Broker：接收和分发消息的应用，RabbitMQ Server就是 Message Broker

• 2、Virtual host：出于多租户和安全因素设计的，把 AMQP 的基本组件划分到一个虚拟的分组中，类似于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务时，可以划分出多个vhost，每个用户在自己的 vhost 创建 exchange／queue 等

• 3、Connection：publisher／consumer 和 broker 之间的 TCP 连接

• 4、Channel：如果每一次访问 RabbitMQ 都建立一个 Connection，在消息量大的时候建立 TCPConnection的开销将是巨大的，效率也较低。Channel 是在 connection 内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的 channel 进行通讯，AMQP method 包含了channel id 帮助客户端和message broker 识别 channel，所以 channel 之间是完全隔离的。
  Channel 作为轻量级的 Connection 极大减少了操作系统建立TCPconnection 的开销

• 5、Exchange：message 到达 broker 的第一站，根据分发规则，匹配查询表中的 routing key，分发消息到queue 中去。常用的类型有：direct (point-to-point), topic (publish-subscribe) andfanout (multicast)

• 6、Queue：消息最终被送到这里等待 consumer 取走

• 7、Binding：exchange 和 queue 之间的虚拟连接，binding 中可以包含 routing key。Binding 信息被保存到 exchange 中的查询表中，用于message 的分发依据

• RabbitMQ提供了6种模式：简单模式，work模式、Publish/Subscribe发布与订阅模式，Routing路由模式，Topics主题模式，RPC远程调用模式（远程调用，不太算MQ；暂不作介绍）；

2、RabbitMQ提供的5种模式中的使用以及介绍

2.1简单模式

• 图解

P：生产者，也就是要发送消息的程序
C：消费者：消息的接收者，会一直等待消息到来
queue：消息队列，图中红色部分。类似一个邮箱，可以缓存消息；生产者向其中投递消息，消费者从其中取出消息

• 简单模式就是简单的一对一模式

生产者产生消息，消费者消费消息

2.2work模式

• 应用场景：对于 任务过重或任务较多情况使用工作队列可以提高任务处理的速度。
• 这是简单的争抢模式

一个生产者多个消费者，生产者产生消息，对个消费者去争抢这个消息

2.3Publish/Subscribe发布与订阅模式

• 订阅模式
  
• P：生产者，也就是要发送消息的程序，但是不再发送到队列中，而是发给X（交换机）
• C：消费者，消息的接受者，会一直等待消息到来。
• Queue：消息队列，接收消息、缓存消息。
• Exchange：交换机，图中的X。一方面，接收生产者发送的消息。另一方面，知道如何处理消息，例如递交给某个特别队列、递交给所有队列、或是将消息丢弃。到底如何操作，取决于Exchange的类型。Exchange有常见以下3种类型：

Fanout：广播，将消息交给所有绑定到交换机的队列
Direct：定向，把消息交给符合指定routing key 的队列
Topic：通配符，把消息交给符合routing pattern（路由模式） 的队列
Exchange（交换机）只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与Exchange绑定，或者没有符合路由规则的队列，那么消息会丢失！

• 发布订阅模式： 1、每个消费者监听自己的队列。 2、生产者将消息发给broker，由交换机将消息转发到绑定此交换机的每个队列，每个绑定交换机的队列都将接收到消息。
• 这个是发布订阅模式–一个发布，订阅的（这里是交换机与多个队列绑定）那么收到消息的消费者就是这个队列的。那么都能够收到消息。

2.4Routing路由模式

• 图解

P：生产者，向Exchange发送消息，发送消息时，会指定一个routing key。
X：Exchange（交换机），接收生产者的消息，然后把消息递交给 与routing key完全匹配的队列
C1：消费者，其所在队列指定了需要routing key 为 error 的消息
C2：消费者，其所在队列指定了需要routing key 为 info、error、warning 的消息

• 队列与交换机的绑定，不能是任意绑定了，而是要指定一个 RoutingKey（路由key）消息的发送方在 向 Exchange发送消息时，也必须指定消息的 RoutingKey 。
• Exchange不再把消息交给每一个绑定的队列，而是根据消息的 Routing Key 进行判断，只有队列的 Routingkey 与消息的 Routing key 完全一致，才会接收到消息

2.5Topics主题模式

• 模式说明

Topic 类型与 Direct 相比，都是可以根据 RoutingKey 把消息路由到不同的队列。只不过 Topic 类型Exchange 可以让队列在绑定 Routing key 的时候使用通配符！

• Routingkey 一般都是有一个或多个单词组成，多个单词之间以”.”分割，例如： item.insert
  通配符规则：

“#” ：匹配一个或多个词
（）：匹配不多不少恰好1个词 括号里面是***
举例：
item.# ：能够匹配 item.insert.abc 或者 item.insert
item.* ：只能匹配 item.insert

• 图解

红色Queue：绑定的是 usa.# ，因此凡是以 usa. 开头的 routing key 都会被匹配到.
黄色Queue：绑定的是 #.news ，因此凡是以 .news 结尾的 routing key 都会被匹配.

3、高级特性

3.1消息的可靠投递

• 在使用 RabbitMQ 的时候，作为消息发送方希望杜绝任何消息丢失或者投递失败场景。RabbitMQ 为我们提供了两种方式用来控制消息的投递可靠性模式。

confirm 确认模式
return 退回模式

• rabbitmq 整个消息投递的路径为：
  producer—>rabbitmq broker—>exchange—>queue—>consumer
  消息从 producer 到 exchange 则会返回一个 confirmCallback 。
  消息从 exchange–>queue 投递失败则会返回一个 returnCallback 。
  我们将利用这两个 callback 控制消息的可靠性投递

3.1.1确认模式

3.1.2退回模式

• 消息从 exchange–>queue 投递失败则会返回一个 returnCallback

3.2Consumer Ack

• ack指Acknowledge，确认。 表示消费端收到消息后的确认方式。
  有三种确认方式

自动确认：acknowledge=“none”
手动确认：acknowledge=“manual”

根据异常情况确认：acknowledge=“auto”，（这种方式使用麻烦，不作讲解
其中自动确认是指，当消息一旦被Consumer接收到，则自动确认收到，并将相应 message 从RabbitMQ 的消息缓存中移除。但是在实际业务处理中，很可能消息接收到，业务处理出现异常，那么该消息就会丢失。如果设置了手动确认方式，则需要在业务处理成功后，调用channel.basicAck()，手动签收，如果出现异常，则调用channel.basicNack()方法，让其自动重新发送消息。

3.3消费端限流

3.4TTL

• Time To Live，消息过期时间设置

3.5 死性队列

• 死信队列，英文缩写：DLX 。Dead Letter Exchange（死信交换机），当消息成为Deadmessage后，可以被重新发送到另一个交换机，这个交换机就是DLX
  
• 消息成为死信的三种情况：（面试常考）

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

• 队列绑定死信交换机：
  给队列设置参数： x-dead-letter-exchange 和 x-dead-letter-routing-key

3.6延迟队列

• 延迟队列，即消息进入队列后不会立即被消费，只有到达指定时间后，才会被消费。
• 需求

1. 下单后，30分钟未支付，取消订单，回滚库存。
2. 新用户注册成功7天后，发送短信问候。

• 实现方式：

1. 定时器
2. 延迟队列

• 但是rabbitMQ并没有队列延迟但是可以使用：TTL+死信队列 组合实现延迟队列的效果。

---

总结

rabbitMQ作为一个优秀的中间通信中间件，能够实现在分布式开发中的并发数据问题，在之后的项目中也能够通过对rabbitMQ的实现，实现多种的功能。