消息中间件 - RabbitMQ

什么是MQ

MQ全称为Message Queue，消息队列是应用程序和应用程序之间的通信方法。

有什么好处

1、异步处理

将不需要同步处理的并且耗时长的操作由消息队列通知消息接收方进行异步处理。提高了应用程序的响应时间。
------ 提升用户体验和系统吞吐量

2、程序解耦

MQ相当于一个中介，生产方通过MQ与消费方交互，它将应用程序进行解耦合。
------ 提高系统容错性和可维护性

3、削峰填谷

高并发下(1000qps) 通过一次性拉取指定数量(300)的Message 来处理。
------ 提高系统稳定性

MQ 的使用场景

• 生产者不需要从消费者处获得反馈。引入消息队列之前的直接调用，其接口的返回值应该为空，这才让明明下层的动作还没做，上层却当成动作做完了继续往后走，即所谓异步成为了可能。
• 容许短暂的不一致性。
• 确实是用了有效果。即解耦、提速、削峰这些方面的收益，超过加入MQ，管理MQ这些成本。

主流的MQ产品

 

怎么用RabbitMQ

RabbitMQ 架构图

架构参数

• Broker：接收和分发消息的应用，RabbitMQ Server就是 Message Broker
• Virtual host：出于多租户和安全因素设计的，把 AMQP 的基本组件划分到一个虚拟的分组中，类似于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务时，可以划分出多个vhost，每个用户在自己的 vhost 创建 exchange／queue 等
• Connection：publisher／consumer 和 broker 之间的 TCP 连接
• Channel：如果每一次访问 RabbitMQ 都建立一个 Connection，在消息量大的时候建立 TCP Connection的开销将是巨大的，效率也较低。Channel 是在 connection 内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的 channel 进行通讯，AMQP method 包含了channel id 帮助客户端和message broker 识别 channel，所以 channel 之间是完全隔离的。Channel 作为轻量级的 Connection 极大减少了操作系统建立 TCP connection 的开销
• Exchange：message 到达 broker 的第一站，根据分发规则，匹配查询表中的 routing key，分发消息到queue 中去。常用的类型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)
• Queue：消息最终被送到这里等待 consumer 取走
• Binding：exchange 和 queue 之间的虚拟连接，binding 中可以包含 routing key。Binding 信息被保存到 exchange 中的查询表中，用于 message 的分发依据

 

 RabbitMQ 7种工作模式

1. Simplest 简单模式
2. Work queues 工作队列(一个provice,多个consumer 竞争工作)
3. Publish/Subscribe发布与订阅模式
4. Routing路由模式
5. Topics主题模式
6. RPC远程调用模式 (其实不算是 MQ)
7. Publisher Confirms 发布确认 --- 暂时没图 官网也没 by 2020-09-06

1、简单模式

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

2、Work queues 工作队列

Work Queues：与入门程序的简单模式相比，多了一个或一些消费端，多个消费端共同消费同一个队列中的消息。
应用场景：对于任务过重或任务较多情况使用工作队列可以提高任务处理的速度。

在一个队列中如果有多个消费者，那么消费者之间对于同一个消息的关系是竞争的关系。
Work Queues 对于任务过重或任务较多情况使用工作队列可以提高任务处理的速度。
例如：短信服务部署多个，只需要有一个节点成功发送即可。

3、Publish/Subscribe

在订阅模型中，多了一个 Exchange 角色，而且过程略有变化：

P：生产者，也就是要发送消息的程序，但是不再发送到队列中，而是发给X（交换机）

C：消费者，消息的接收者，会一直等待消息到来

Queue：消息队列，接收消息、缓存消息

Exchange：交换机（X）。一方面，接收生产者发送的消息。另一方面，知道如何处理消息，例如递交给某个特别队列、递交给所有队列、或是将消息丢弃。到底如何操作，取决于Exchange的类型。

Exchange有常见以下3种类型：

Fanout：广播，将消息交给所有绑定到交换机的队列 routingKey任意填写，建议为''

Direct：定向，把消息交给符合指定routing key 的队列

Topic：通配符，把消息交给符合routing pattern（路由模式） 的队列

Exchange（交换机）只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与 Exchange 绑定，或者没有符合路由规则的队列，那么消息会丢失！

1. 交换机需要与队列进行绑定，绑定之后；一个消息可以被多个消费者都收到。

2. 发布订阅模式与工作队列模式的区别：

• 工作队列模式不用定义交换机，而发布/订阅模式需要定义交换机
• 发布/订阅模式的p方是面向交换机发送消息，工作队列模式的p方是面向队列发送消息(底层使用默认交换机 direct)
• 发布/订阅模式需要设置队列和交换机的绑定，工作队列模式不需要设置，实际上工作队列模式会将队列绑 定到默认的交换机

4、Routing

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

队列与交换机的绑定，不能是任意绑定了，而是要指定一个RoutingKey（路由key）

消息的发送方在 向 Exchange发送消息时，也必须指定消息的 RoutingKey。

Exchange不再把消息交给每一个绑定的队列，而是根据消息的RoutingKey进行判断，只有队列的Routingkey与消息的 Routingkey完全一致，才会接收到消息

5、Topic

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

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

通配符规则：

• #：匹配一个或多个词
• *：匹配不多不少恰好1个词

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

RabbitMQ工作模式小结 

1、简单模式 HelloWorld 一个生产者、一个消费者，不需要设置交换机（使用默认的交换机）

2、工作队列模式 Work Queue 一个生产者、多个消费者（竞争关系），不需要设置交换机（使用默认的交换机）

3、发布订阅模式 Publish/subscribe 需要设置类型为fanout的交换机，并且交换机和队列进行绑定，当发送消息到交换机后，交换机会将消息发送到绑定的队列

4、路由模式 Routing 需要设置类型为direct的交换机，交换机和队列进行绑定，并且指定routing key，当发送消息到交换机后，交换机会根据routing key将消息发送到对应的队列

5、通配符模式 Topic 需要设置类型为topic的交换机，交换机和队列进行绑定，并且指定通配符方式的routing key，当发送消息到交换机后，交换机会根据routing key将消息发送到对应的队列

RabbitMQ -- demo 基于Spring

生产：https://gitee.com/love_yu_0698/spring-rabbitmq-producter.git
消费：https://gitee.com/love_yu_0698/spring-rabbitmq-consumer.git

ps：配置文件需要修改

RabbitMQ 高级特性

消息的可靠投递

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

1. confirm 确认模式
2. return  退回模式

rabbitmq 整个消息投递的路径为：
producer--->rabbitmq broker--->exchange--->queue--->consumer
消息从 producer 到 exchange 则会返回一个 confirmCallback 。
消息从 exchange-->queue 投递失败则会返回一个 returnCallback 。

我们将利用这两个 callback 控制消息的可靠性投递

设置ConnectionFactory的publisher-confirms="true" 开启 确认模式。

 

使用rabbitTemplate .setConfirmCallback 设置回调函数。当消息发送到 exchange 后回调 confirm 方法。在方法中判断ack，如果为 true ，则发送成功，如果为 false ，则发送失败，需要处理。

 

设置ConnectionFactory的publisher- return s="true" 开启 退回模式。

 

使用 rabbitTemplate.setReturnCallback 设置退回函数，当消息从 exchange 路由到 queue 失败后，如果设置了rabbitTemplate.setMandatory(true)参数，则会将消息退回给 producer 。并执行回调函数returnedMessage。

Consumer Ack

ack指Acknowledge，确认。 表示消费端收到消息后的确认方式。
有三种确认方式：
自动确认：acknowledge="none"
手动确认：acknowledge="manual" -- 可做延迟消息队列
根据异常情况确认：acknowledge="auto"，（这种方式使用麻烦，不作讲解）

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

在rabbit:listener-container标签中设置acknowledge属性，设置 ack 方式 none ：自动确认，manual：手动确认
 

如果在消费端没有出现异常，则调用channel.basicAck(deliveryTag,false);方法确认签收消息

 

如果出现异常，则在 catch 中调用 basicNack或 basicReject，拒绝消息，让 MQ 重新发送消息。

消费端限流

例如 消息队列里 有2000个消息 每次只拉取100个 处理完后 再拉取100

在 < rabbit:listener-container > 中配置 prefetch 属性设置消费端一次拉取多少消息

消费端的确认模式一定为手动确认。acknowledge="manual"

TTL(Time To Live 存活时间/过期时间)

当消息到达存活时间后，还没有被消费，会被自动清除。

RabbitMQ可以对消息设置过期时间，也可以对整个队列（Queue）设置过期时间。

设置队列过期时间使用参数：x-message-ttl，单位： ms( 毫秒 ) ，会对整个队列消息统一过期。

 

设置消息过期时间使用参数：expiration。 单位： ms( 毫秒 ) ，当该消息在队列头部时（消费时），会单独判断这一消息是否过期。

 

如果两者都进行了设置，以时间短的为准。

死信队列

死信队列，英文缩写：DLX  。Dead Letter Exchange（死信交换机），当消息成为Dead message后，可以被重新发送到另一个交换机，这个交换机就是DLX。

消息成为死信的三种情况

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

队列绑定死信交换机：

给正常队列设置参数： x-dead-letter-exchange 和 x-dead-letter-routing-key

延迟队列(TTL+死信队列)

在RabbitMQ中并未提供延迟队列功能。但是可以使用：TTL+死信队列 组合实现延迟队列的效果。

RabbitMQ -- demo 高级特性-基于SpringBoot

代码地址：https://gitee.com/love_yu_0698/rabbit-senior.git

ps：配置信息需要修改

消息可靠性保障

消息补偿

幂等性

乐观锁机制