rabbitMQ介绍与安装说明（一）

文章目录

---

MQ简介

MQ 全称 Message Quere 消息队列

---

一、消息中间件的作用

1. 异步处理
2. 应用的解耦
3. 流量控制（流量削峰）
4. 作用：大多应用中，可通过消息服务中间件来提升系统异步通信、扩展解耦能力

二、概要

1.1、 消息服务2大概念

1. 消息代理（message broker）
2. 目的地（destination）

当消息发送者发送消息以后，将由消息代理接管，消息代理保证消息传递到指定目的地

1.2、两种形式的目的地

1. 队列（queue）：点对点消息通信（point-to-point）
   点对点式：
   01、消息发送者发送消息，消息代理将其放入一个队列中，消息接收者从队列中获取消息内容，消息读取后被移出队列
   02、消息只有唯一的发送者和接受者，但并不是说只能有一个接收者
   

2. 主题（topic）：发布（publish）/订阅（subscribe）消息通信
   发布订阅式：
   发送者（发布者）发送消息到主题，多个接收者（订阅者）监听（订阅）这个主题，那么就会在消息到达时同时收到消息（可以理解为广播-订阅者都收得信息）
   

三、 JMS和AMQP说明和比较

1.1、什么是JMS和AMQP

1. JMS（Java Message Service）JAVA消息服务：基于JVM消息代理的规范。
   ActiveMQ、HornetMQ是JMS实现
   
2. AMQP（Advanced Message Queuing Protocol）高级消息队列协议
   01、高级消息队列协议，也是一个消息代理的规范，兼容JMS
   02、RabbitMQ是AMQP的实现
   
   

1.2、JMS和AMQP比较

	JMS（Java Message Service）	AMQP（Advanced Message QueuingProtocol）
定义	Java api	网络线级协议
跨语言	否	是
跨平台	否	是
Mode	提供两种消息模型： 01、Peer-2-Peer 点对点 02、Pub/sub 发布订阅	提供了五种消息模型： 01、direct exchange 02、fanout exchange 03、topic change 04、headers exchange 05、system exchange 本质来讲，后四种和JMS的pub/sub模
支持消息类型	多种消息类型： 1、TextMessage 2、MapMessage 3、BytesMessage 4、StreamMessage 5、 ObjectMessage 6、 Message （只有消息头和属性）	一种：byte[] 1、当实际应用时，有复杂的消息，可以将消息序列化后发送 2、在网络通讯中，可以理解为万物皆流
综合	1、JMS 定义了JAVA API层面的标准 2、在java体系中，多个client均可以通过JMS进行交互，不需要应用修改代码。 3、但是其对跨平台的支持较差；	1、AMQP定义了wire-level层的协议标准 2、天然具有跨平台、跨语言特性。

1.3、spring家族对JMS和AMQP的支持

1.3.1、Spring支持

1. spring-jms提供了对JMS的支持
2. spring-rabbit提供了对AMQP的支持
3. 需要ConnectionFactory的实现来连接消息代理
4. 提供JmsTemplate、RabbitTemplate来发送消息
5. @JmsListener（JMS）、@RabbitListener（AMQP）注解在方法上监听消息代理发布的消息
6. @EnableJms、@EnableRabbit开启支持

1.3.2、Spring Boot自动配置

1. JmsAutoConfiguration 对JMS的自动化配置
2. RabbitAutoConfiguration 对rabbit的自动化配置

四、RabbitMQ：

RabbitMQ是一个由erlang开发的AMQP(Advanved Message Queue Protocol)的开源实现

rabbitmq的Message

1. 消息，消息是不具名的，它由消息头和消息体组成。
2. 消息体是不透明的，而消息头则由一系列的可选属性组成。
3. 这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等

1.1、rabbitmq 9大要点

1. Publisher（生产者）
   消息的生产者，也是一个向交换器发布消息的客户端应用程序

2. Consumer(消费者)
   消息的消费者，表示一个从消息队列中取得消息的客户端应用程序。

3. Exchange（交换器）
   （a）用来接收生产者发送的消息并将这些消息路由给服务器中的队列
   （b）Exchange有4种类型：direct(默认)、fanout、topic、 和headers不同类型的Exchange转发消息的策略有所区别

4. Queue （消息队列）
   （a）用来保存消息直到发送给消费者。
   （b）它是消息的容器，也是消息的终点。
   （c）一个消息可投入一个或多个队列。
   （d）消息一直在队列里面，等待消费者连接到这个队列将其取走。

5. Binding (绑定)
   （a）用于消息队列和交换器之间的关联
   （b）一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。
   （c）Exchange 和Queue的绑定可以是多对多的关系。

6. Connection (网络连接)
   网络连接，比如一个TCP连接，rabbitmq采用的是一个长连接

7. Channel (信道)
   （a）信道，多路复用连接中的一条独立的双向数据流通道。
   （b）信道是建立在真实的TCP连接内的虚拟连接，AMQP命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。
   （b）因为对于操作系统来说建立和销毁TCP都是非常昂贵的开销，所以引入了信道的概念，以复用一条 TCP 连接。
   （c）可以理解为一条 TCP 连接是一条公路，信道就是公路的8个分道
   

8. Broker 表示消息队列服务器实体

9. Virtual Host (虚拟主机)
   （a）虚拟主机，表示一批交换器、消息队列和相关对象。
   （b）虚拟主机是共享相同的身份认证和加密环境的独立服务器域。
   （c）每个 vhost 本质上就是一个 mini 版的RabbitMQ服务器，拥有自己的队列、交换器、绑定和权限机制。
   （d）vhost 是 AMQP 概念的基础，必须在连接时指定，RabbitMQ 默认的 vhost 是 / 。
   （e）可以理解为在Broker建立分区，分成多个完整不同的rabbitmq不会互相影响

1.2、9大要点 图示

五、RabbitMQ安装

rabbitMQ
docker镜像官网

1.1、推荐先镜像加速换成阿里的

查看docker的信息

docker info

1.2、安装rabbitmq

拉去镜像命令：

docker run -d --name rabbitmq -p 5671:5671 -p 5672:5672 -p 4369:4369 -p 25672:25672 -p 15671:15671 -p 15672:15672 rabbitmq:management

查看

docker ps

配置自动重启

docker update rabbitmq  --restart=always

1.2.1、防火墙端口放行

如果是云服务器要在安全组配置规则

如图：

防火墙：

# 查看防火墙状态
systemctl status firewalld
# 开启防火墙
systemctl start firewalld
#放行端口
firewall-cmd --zone=public --add-port=端口/tcp --permanent
#刷新生效
firewall-cmd --reload
#查看防火墙放行列表
firewall-cmd --list-all
#查看防火墙状态，是否是running
firewall-cmd --state                           
#重新载入配置，比如添加规则之后，需要执行此命令
firewall-cmd --reload                        
#列出支持的zone
firewall-cmd --get-zones                      
#列出支持的服务，在列表中的服务是放行的
firewall-cmd --get-services             
#查看ftp服务是否支持，返回yes或者no
firewall-cmd --query-service ftp 
#临时开放ftp服务
firewall-cmd --add-service=ftp    
#永久开放ftp服务 
firewall-cmd --add-service=ftp --permanent     
#永久移除ftp服务 
firewall-cmd --remove-service=ftp --permanent  
#永久添加80端口
firewall-cmd --add-port=80/tcp --permanent      
#永久移除80端口 
firewall-cmd --remove-port=80/tcp --permanent  
#查看已经开放的端口
firewall-cmd --list-ports                      
#查看规则，这个命令是和iptables的相同的
iptables -L -n                                
#查看帮助 
man firewall-cmd                               

1.3、端口说明

rabbitmq是Erlang语言编写的

1. 4369, 25672 (Erlang发现&集群端口)
2. 5672, 5671 (AMQP端口)
3. 15672 (web管理后台端口)
4. 61613, 61614 (STOMP协议端口)
5. 1883, 8883 (MQTT协议端口)

1.4、访问rabbitmq控制台

虚拟机Ip:15672 (端口15672)
默认的账号密码都是guest
如图：

1.4.1、rabbitmq控制台说明

总览

链接

通道

交换机

管理

---

六、RabbitMQ运行机制

AMQP 中的消息路由

1. AMQP 中消息的路由过程和 Java 开发者熟悉的 JMS 存在一些差别，
   AMQP 中增加了 Exchange 和Binding 的角色。
2. 生产者把消息发布到 Exchange 上，消息最终到达队列并被消费者接收，而 Binding 决定交换器的消息应该发送到那个队列。

---

七、Exchange交换机

Exchange分发消息时根据类型的不同分发策略有区别，目前共四种类型

1. direct (直接) --点对点模式(单波模式)
2. headers （性能差几乎没什么用） --点对点模式
3. fanout (扇出) – 发布订阅的实现
4. topic （主题）-- 发布订阅的实现

headers 匹配 AMQP 消息的 header 而不是路由键，headers 交换器和 direct
交换器完全一致，但性能差很多，目前几乎用不到了

1.1、direct Exchange（直接交换机）

1. 消息中的路由键（routing key）如果和
   Binding 中的 binding key 一致， 交换器
   就将消息发到对应的队列中
2. 它是完全匹配、单播的模式

1.2、fanout Exchange（广播交换机）

1. 每个发到 fanout 类型交换器的消息都会分到所有绑定的队列上去

2. fanout 交换器不处理路由键，只是简单的将队列绑定到交换器上，每个发送到交换器的消息都会被转发到与该交换器绑定的所有队列上

3. 很像子网广播，每台子网内的主机都获得了一份复制的消息。fanout 类型转发消息是最快的。

1.3、topic Exchange（订阅交换机）

1. topic 交换器通过模式匹配分配消息的路由键属性，将路由键和某个模式进行匹配，此时队列需要绑定到一个模式上
2. 它将路由键和绑定键的字符串切分成单词，这些单词之间用点隔开。
3. 它同样也会识别两个通配符：符号“#”和符号“*”。
4. #匹配0个或多个单词，*匹配一个单词

---

八、默认guest用户问题

因为在rabbitmq的3.3版本以后，加入保护机制，默认的guest用户无法远程连接（springboot整合时候会出现问题），所以推荐自己新建一个用户（或者修改配置文件）。

新建的用户的方法：

进入，准备授权

授权

---

九、什么是ACK模式

保证消息不丢失，可靠抵达，可以使用事务消息，性能下降250倍，为此引入确认机制

1. publisher confirmCallback 确认模
2. publisher returnCallback 未投递到 queue 退回模式
3. consumer ack机制

作用就是保证消息的可靠性

1. 消费者获取到消息，成功处理，可以回复Ack给Broker
   •basic.ack用于肯定确认；broker将移除此消息
   •basic.ack用于肯定确认；broker将移除此消息
   •basic.reject用于否定确认；同上，但不能批量

2. 默认自动ack，消息被消费者收到，就会从broker的queue中移除

3. queue无消费者，消息依然会被存储，直到消费者消费

4. 消费者收到消息，默认会自动ack。但是如果无法确定此消息是否被处理完成，或者成功处理。我们可以开启手动ack模式
   •消息处理成功，ack()，接受下一个消息，此消息broker就会移除
   •消息处理失败，nack()/reject()，重新发送给其他人进行处理，或者容错处理后ack
   •消息一直没有调用ack/nack方法，broker认为此消息正在被处理，不会投递给别人，此时客户端断开，消息不会被broker移除，会投递给别人

   ---

十、延时队列说明与场景

1.1、场景和方案

比如未付款订单，超过一定时间后，系统自动取消订单并释放占有物品。

常用解决方案
spring的 schedule 定时任务轮询数据库
缺点：
消耗系统内存、增加了数据库的压力、存在较大的时间误差

解决： rabbitmq的消息TTL和死信Exchange结合

1.2、死信Exchange和TTL

1.2.1、消息的TTL（Time To Live）

消息的TTL就是消息的存活时间

RabbitMQ可以对队列和消息分别设置TTL

1. 对队列设置就是队列没有消费者连着的保留时间，也可以对每一个单独的消息做单独的设置。超过了这个时间，我们认为这个消息就死了，称之为死信。
2. 如果队列设置了，消息也设置了，那么会取小的。所以一个消息如果被路由到不同的队列中，这个消息死亡的时间有可能不一样（不同的队列设置）。
3. 这里单讲单个消息的TTL，因为它才是实现延迟任务的关键。可以通过设置消息的expiration字段或者x- message-ttl属性来设置时间，两者是一样的效果

什么是死信：

1. 一个消息被Consumer拒收了，并且reject方法的参数里requeue是false。也就是说不会被再次放在队列里，被其他消费者使用。（basic.reject/ basic.nack）requeue=false
2. 上面的消息的TTL到了，消息过期了
3. 队列的长度限制满了。排在前面的消息会被丢弃或者扔到死信路由上

1.2.1.1、 其他参数配置：

1. Message TTL : 消息生存期
2. Auto expire : 队列生存期
3. Max length : 队列可以容纳的消息的最大条数
4. Max length bytes : 队列可以容纳的消息的最大字节数
5. Overflow behaviour : 队列中的消息溢出后如何处理
6. Dead letter exchange : 溢出的消息需要发送到绑定该死信交换机的队列
7. Dead letter routing key : 溢出的消息需要发送到绑定该死信交换机,并且路由键匹配的队列
8. Maximum priority : 最大优先级
9. Lazy mode : 懒人模式

1.2.2、死信交换机

1. 一个消息在满足如下条件下，会进死信路由，记住这里是路由而不是队列，一个路由可以对应很多队列
2. Dead Letter Exchange其实就是一种普通的exchange，和创建其他exchange没有两样。只是在某一个设置Dead Letter Exchange的队列中有消息过期了，会自动触发消息的转发，发送到Dead Letter Exchange中去。
3. 我们既可以控制消息在一段时间后变成死信，又可以控制变成死信的消息被路由到某一个指定的交换机，结合二者，其实就可以实现一个延时队列

1.2.3、建议

手动ack&异常消息统一放在一个队列处理建议的两种方式

1. catch异常后，手动发送到指定队列，然后使用channel给rabbitmq确认消息已消费
2. 给Queue绑定死信队列，使用nack（requque为false）确认消息消费失败

---

十一、消息丢失、重复、积压问题

1.1、消息丢失

有3种情况

1. 消息发送出去，由于网络问题没有抵达服务器
   a. 做好容错方法（try-catch），发送消息可能会网络失败，失败后要有重试机制，可记录到数据库，采用定期扫描重发的方式
   b. 做好日志记录，每个消息状态是否都被服务器收到都应该记录
   c. 做好定期重发，如果消息没有发送成功，定期去数据库扫描未成功的消息进行重发
   

2. 消息抵达Broker，Broker要将消息写入磁盘（持久化）才算成功。此时Broker尚未持久化完成，宕机。
   publisher也必须加入确认回调机制，确认成功的消息，修改数据库消息状态(配合数据库字段-乐观锁)
   

3. • 自动ACK的状态下。消费者收到消息，但没来得及消息然后宕机
   一定开启手动ACK，消费成功才移除，失败或者没来得及处理就noAck并重新入队
   

1.2、消息重复

1. 消息消费成功，事务已经提交，ack时，机器宕机。导致没有ack成功，Broker的消息重新由unack变为ready，并发送给其他消费者
2. 消息消费失败，由于重试机制，自动又将消息发送出去
3. 成功消费，ack时宕机，消息由unack变为ready，Broker又重新发送

解决方案：

1. 消费者的业务消费接口应该设计为幂等性的。比如扣库存有工作单的状态标志
2. 使用防重表（redis/mysql），发送消息每一个都有业务的唯一标识，处理过就不用处理
3. rabbitMQ的每一个消息都有redelivered字段，可以获取是否是被重新投递过来的，而不是第一次投递过来的

1.3、消息积压

1. 消费者宕机积压
2. 消费者消费能力不足积压
3. 发送者发送流量太大

解决方案：

1. 上线更多的消费者，进行正常消费
2. 上线专门的队列消费服务，将消息先批量取出来，记录数据库，离线慢慢处理

---

下一篇：springboot集合rabbitmq