RabbitMQ

RabbitMQ

简介

MQ优点

任务异步处理

应用程序解耦合

RabbitMQ优点

1、使得简单，功能强大

基于AMQP协议

社区活跃，文档完善

高并发性能好，这主要得益于Erlang语言

Spring Boot默认已集成RabbitMQ

基本结构

Broker：消息队列服务进程，此进程包括两个部分：Exchange和Queue

Exchange：消息队列交换机，按一定的规则将消息路由转发到某个队列，对消息进行过虑。

Queue：消息队列，存储消息的队列，消息到达队列并转发给指定的消费方。

Producer：消息生产者，即生产方客户端，生产方客户端将消息发送到MQ。

Consumer：消息消费者，即消费方客户端，接收MQ转发的消息。

消息发布接收流程

发送消息

1、生产者和Broker建立TCP连接。

2、生产者和Broker建立通道。

3、生产者通过通道消息发送给Broker，由Exchange将消息进行转发。

4、Exchange将消息转发到指定的Queue（队列）

接收消息

1、消费者和Broker建立TCP连接

2、消费者和Broker建立通道

3、消费者监听指定的Queue（队列）

4、当有消息到达Queue时Broker默认将消息推送给消费者。

5、消费者接收到消息。

消息确认

消息发送

事物模式

消息异步确认模式

confirm消息确认

消息确认是指：生产者投递消息后，如果broker接收到消息后，会给生产者一个应答 
接收消息成功，返回true；接收消息失败，返回false
如果无应答，可能与broker服务器tcp通信故障

application添加配置：rabbitemq.publisher-confirms: true #开启消息发布确认（消息成功发送到broker）

return消息机制

application配置：rabbitmq.publisher-returns: true #开启消息回调监听器 
 rabbitmq.template.mandatory: true

return listener： 用于处理那些无法路由的消息

生产者通过exchange和routingKey，将消息路由到指定的队列中去；消费者监听队列，进行消息消费；在某些情况下，我们指定的exchange不存在，
或者指定的key路由不到队列，这些消息就是不可达的消息，这个时候就需要用到return listener监听这些不可达的消息；

关键配置项：Mandatory 如果为true：监听会接收到路由不可达的消息，进行后续处理； 如果为false：broker端会自动删除该消息

消息接收

自动确认

消费者接收到消息之后自动确认，同时broker会删除消息，这里有一个问题，如果消费者接收到消息处理业务失败怎么办？

手动ack确认

application配置：rabbitmq.listener.simple.acknowledge-mode: manual

消费端ack与重回队列（配合手动确认消息使用）

basicAck

此方法：告诉服务器收到这条消息，已经被我消费了，可以在队列删掉这样以后就不会再发了，否则消息服务器以为这条消息没处理掉，后续还会重发

basicNack

第三个参数：true 表示消息重新投递，消费者还会重新接收到该消息；
false 表示消息在rabbitmq服务器中删除，消费者不会接收到该消息

工作模式

simplest(简单模式)

一个生产者，一个消费者

Work queues（工作队列）

1、一条消息只会被一个消费者接收；

2、rabbit采用轮询的方式将消息是平均发送给消费者的；

3、消费者在处理完某条消息后，才会收到下一条消息。

一个生产者，多个消费者，每个消费者获取到的消息唯一

Publish/Subscribe（发布订阅）

work queues不用定义交换机，而publish/subscribe需要定义交换机。

publish/subscribe的生产方是面向交换机发送消息，work queues的生产方是面向队列发送消息(底层使用默认交换机)。

一个生产者发送的消息会被多个消费者获取

相同点：两者实现的发布/订阅的效果是一样的，多个消费端监听同一个队列不会重复消费消息。

Routing（路由模式）

Routing模式要求队列在绑定交换机时要指定routingkey，消息会转发到符合routingkey的队列

Topics（通配符模式）

队列绑定交换机指定通配符： 统配符规则：

中间以“.”分隔。

符号#可以匹配多个词，符号*可以匹配一个词语。

RPC(客户端远程调用服务端)

死信队列

解释

当一个消息在一个队列中变成死信（dead message）后，它会重新publish到一个exchange上，这个exchange就是dlx

dlx就是一个普通的exchange，他能在任何queue上被指定，实际就是在这个queue上设置属性 
 当这个queue上有死信时，rabbitmq会自动将这个死信重新发布到定义的exchange上（dlx），进而被路由到一个队列上 业务可以监听这个队列的消息，做一些处理

消息变成死信的几种情况

消息TTL过期

队列达到最大长度

集群架构

主备模式

实现rabbitmq的高可用集群，一般在并发和数据量不高的情况下，这种模型非常的好用而且简单。

也称为Warren模式(主节点挂了，从节点提供服务)

分支主题

远程模式

可以实现双活的一种模式，简称Shovel

把消息进行不同数据中心的复制工作，可以跨地域的让两个mq集群互联，远距离通信和复制

镜像模式

能保证100%数据不丢失，集群实现简单，目的是为了保证rabbitmq数据的高可靠性解决方案，主要就是实现数据的同步

一般来讲是2-3个节点实现数据同步

多活模式

也是实现异地数据复制的主流模式，因为Shovel模式配置比较复杂。所以一般来说实现异地集群都使用双活或者多活模型来实现

这种模型需要依赖rabbitmq的federation插件，可以实现持续的可靠的amqp数据通信。

部署架构采用双(多)中心模式，那么两套(多套)数据中心各部署一套rabbitmq集群，各中心的rabbitmq服务除了需要为业务提供正常的消息服务外，中心之间还需要实现部分队列消息共享

消费端限流

RabbitMQ提供了qos（服务质量保证）功能：在非自动消息确认的前提下，如果一定数目的消息未被消费前，不会进行消费新的消息

方法

prefetchSize： 单个消息大小限制，一般为0

prefetchCount：告诉rabbitmq不要给一个消费者一次推送超过N条消息，直到消费者主动ack

global： true\\false是否将上述设置应用于channel，即上面的设置是通道级别还是消费之级别，一般为false

自由主题