RabbitMQ

简介

RabbitMQ是最受欢迎的开源消息中间件之一，在全球范围内被广泛应用。RabbitMQ是轻量级且易于部署的，能支持多种消息协议。RabbitMQ可以部署在分布式系统中，以满足大规模、高可用的要求。

安装及配置

Linux安装：

下载docker镜像

docker pull rabbitmq:3.7.15

使用docker命令启动服务

docker run -d -p 5672:5672 -p 15672:15672 \--name rabbitmq rabbitmq:3.7.15

进入容器并开启管理功能

docker exec -it rabbitmq /bin/bash 
rabbitmq-plugins enable rabbitmq_management

开启防火墙便于外网访问

访问及配置

1. 访问RabbitMQ管理页面地址，查看是否安装成功（Linux下使用服务器IP访问即可）：http://localhost:15672
2. 输入账号密码并登录，这里使用默认账号密码登录：guest guest
3. 创建帐号并设置其角色为管理员：yh yh
   
4. 创建一个新的虚拟host为：/yh
   
5. 点击yh用户，给yh用户配置该虚拟host的权限；
   
6. 至此，RabbitMQ的配置完成。

RabbitMQ简介

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

核心概念

Message

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

Publish

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

Exchange

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

Queue

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

Binding

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

Connection

网络连接，比如一个TCP连接。

Channel

信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内的虚拟连接，AMQP命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些都是通过信道完成的。因为对于操作系统来说建立和销毁TCP都是非常昂贵的开销，所以引入信道的概念，以复用一条TCP连接。

Consumer

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

Virtual Host

虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同身份认证和加密环境的独立服务器域。每个vhost本质上就是一个mini版的RabbitMQ服务器，拥有自己的队列、交换器、绑定和权限机制。vhost是AMQP概念的基础，必须在连接时指定，默认的vhost是/。

Broker

表示消息队列服务器实体

5种消息模式

简单模式

简单模式是最简单的消息模式，它包含一个生产者、一个消费者和一个队列。生产者向队列里发送消息，消费者从队列中获取消息并消费。

工作模式

工作模式是指向多个互相竞争的消费者发送消息的模式，它包含一个生产者、两个消费者和一个队列。两个消费者同时绑定到一个队列上去，当消费者获取消息处理耗时任务时，空闲的消费者从队列中获取并消费消息。

发布/订阅模式（fanout）

发布/订阅模式是指同时向多个消费者发送消息的模式（类似广播的形式），它包含一个生产者、两个消费者、两个队列和一个交换机。两个消费者同时绑定到不同的队列上去，两个队列绑定到交换机上去，生产者通过发送消息到交换机，所有消费者接收并消费消息。

路由模式（direct）

路由模式是可以根据路由键选择性给多个消费者发送消息的模式，它包含一个生产者、两个消费者、两个队列和一个交换机。两个消费者同时绑定到不同的队列上去，两个队列通过路由键绑定到交换机上去，生产者发送消息到交换机，交换机通过路由键转发到不同队列，队列绑定的消费者接收并消费消息。

通配符模式（topic）

通配符模式是可以根据路由键匹配规则选择性给多个消费者发送消息的模式，它包含一个生产者、两个消费者、两个队列和一个交换机。两个消费者同时绑定到不同的队列上去，两个队列通过路由键匹配规则绑定到交换机上去，生产者发送消息到交换机，交换机通过路由键匹配规则转发到不同队列，队列绑定的消费者接收并消费消息。

header模式（header）

header模式与routing不同的地方在于，header模式取消routingkey，使用header中的
key/value（键值对）匹配队列。

RPC模式（direct）

1、客户端即是生产者就是消费者，向RPC请求队列发送RPC调用消息，同时监听RPC响应队列。

2、服务端监听RPC请求队列的消息，收到消息后执行服务端的方法，得到方法返回的结果。

3、服务端将RPC方法 的结果发送到RPC响应队列。

4、客户端（RPC调用方）监听RPC响应队列，接收到RPC调用结果。

消息确认机制-可靠抵达

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

• publish cornfirmCallback确认模式

• publish returnCallback未投递到queue退回模式

• consumer ack机制

如何保证消息可靠性-消息丢失

1.消息丢失

消息发送出去，由于网络原因未到达服务器

• 做好容错方法，发送消息可能会网络失败，失败后要去重试机制，可记录到数据库，定期重发

• 做好日志记录，每个消息状态是否被服务器收到都应该记录

• 做好定期重发，如果消息发送成功，定期去数据库扫描未成功发送的消息进行重发

消息抵达Broker，Broker要将消息持久化才算成功。此时如果宕机，消息持久化未完成

• publisher也必须加入确认回调机制，确认成功的消息，修改数据库消息状态

自动ack的状态下。消费者收到消息，但没来得及处理消息，宕机

• 开启手动ack，消费成功才移除，消费失败就noack并重新入队

2.消息重复

消息消费成功，但是手动ack时宕机，导致ack失败，消息被发送给其他消费者

消息消费失败，由于重试机制，自动又将消息发出去

• 保证消费业务接口幂等性，处理过了就不处理了

• rabbitmq的每一个消息都有redelivered字段，可以获取是否被重新投递过来的，而不是第一次投递

3.消息积压

消费者宕机

消费者消费能力不足

发送者发送流量过大

• 上线更多消费者

• 先将消息记录到数据库，再慢慢处理

RabbitMQ延时队列（实现定时任务）

场景：比如未付款订单，超时一定时间后，系统自动取消订单并释放库存。

常用解决方案：

spring Schedule定时任务轮询数据库

缺点：

消耗系统内存，增加数据库压力，存在时间误差

解决：RabbitMQ的消息ttl和死信Exchange结合

消息的TTL（Time To Live）

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

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

• 对队列设置就是队列没有消费者连着的保留时间，也可以对每个单独的消息做单独的设置。超过这个时间，我们认为消息死了，称之为死信。

• 如果队列设置了。消息也设置了，那么会取小的。所以一个消息如果被路由到不同的队列，这个消息的死亡的时间可能不一样（不同队列设置）。这里单讲单个消息的TTL因为它才是实现延迟任务的关键。可以通过设置消息expiration字段或者x-message-ttl属性来设置时间，两者是一样的效果。

Dead Letter Exchanges(DLX)

• 一个消息在满足如下条件下，会进入死信路由，记住这里是路由不是队列，一个路由可以应对很多队列。（什么是死信）

• 一个消息被消费者拒收了，并且reject方法的参数是requeue是false。也就是说不会被再次放在队列里，被其他消费者使用。（basicNack/basicReject）requeue=false

• 上面的消息ttl到了，消息过期

• 队列的长度限制满了。排在前面的消息会被丢弃或扔到死信路由

• Dead Letter Exchange其实就是一个普通的exchange，和创建其他exchange没两样。只是在某一个设置Dead
  Letter Exchange的队列中有消息过期了，会自动触发消息的转发，发送到Dead Letter Exchange中去。

• 我们既可以控制消息在一段时间后变成死信，又可以控制变成死信的消息被路由到某一个指定的exchange，结合二者，就可以实现一个延迟队列。