RabbitMQ精讲

最新推荐文章于 2023-07-31 15:08:18 发布

weixin_42904118

最新推荐文章于 2023-07-31 15:08:18 发布

阅读量303

点赞数

分类专栏： MQ

本文链接：https://blog.csdn.net/weixin_42904118/article/details/106077000

版权

MQ 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

基础

前言

RabbitMQ是一个开源的消息代理软件（面向消息的中间件），它的核心作用就是创建消息队列，异步接收和发送消息，MQ的全程是：Message Queue中文的意思是消息队列。

使用场景

削峰填谷：用于应对间歇性流量提升对于系统的“破坏”，比如秒杀活动，可以把请求先发送到消息队列在平滑的交由系统去处理，当访问量大于一定数量的时候，还可以直接屏蔽后续操作，给前台的用户友好的显示；
延迟处理：可以进行事件后置，比如订单超时业务，用户下单30分钟未支付取消订单；
系统解耦：消息队列也可以帮开发人员完成业务的解耦，比如用户上传头像的功能，最初的设计是用户上传完之后才能发帖，后面有增加了经验系统，需要在上传头像之后增加经验值，到后来又上线了金币系统，上传头像之后可以增加金币，像这种需求的不断升级，如果在业务代码里面写死每次该业务代码是很不优雅的，这个时候如果使用消息队列，那么只需要增加一个订阅器用于介绍用户上传头像的消息，再执行经验的增加和金币的增加是非常简单的，并且在不改动业务模块业务代码的基础上可以轻松实现，如果后期需要撤销某个模块了，只需要删除订阅器即可，就这样就降低了系统开发的耦合性；

为什么使用RabbitMQ？

现在市面上比较主流的消息队列还有Kafka、RocketMQ、RabbitMQ，它们的介绍和区别如下：

Kafka： 是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache定级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。

RabbitMQ： 是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。

RocketMQ： 是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。

简单总结： Kafka的性能最好，适用于对消息吞吐量达，对消息丢失不敏感的系统；RocketMQ借鉴了Kafka并提高了消息的可靠性，修复了Kafka的不足；RabbitMQ性能略低于Kafka，并实现了AMQP（Advanced Message Queuing Protocol）高级消息队列协议的标准，有非常好的稳定性。

支持语言对比

RocketMQ 支持语言：Java、C++、Golang
Kafka 支持语言：Java、Scala
RabbitMQ支持语言：C#、Java、Js/NodeJs、Python、Ruby、Erlang、Perl、Clojure、Golang

RabbitMQ特点

RabbitMQ的特点是易用、扩展性好（集群访问）、高可用，具体如下：

可靠性：持久化、消息确认、事务等保证了消息的可靠性；
伸缩性：集群服务，可以很方便的添加服务器来提高系统的负载；
高可用：集群状态下部分节点出现问题依然可以运行；
多语言支持：RabbitMQ几乎支持了所有的语言，比如Java、.Net、Nodejs、Golang等；
易用的管理页面：RabbitMQ提供了易用了网页版的管理监控系统，可以很方便的完成RabbitMQ的控制和查看；
插件机制：RabbitMQ提供了许多插件，可以丰富和扩展Rabbit的功能，用户也可编写自己的插件；

RabbitMQ基础知识

在了解消息通讯之前首先要了解3个概念：生产者、消费者和代理。
生产者：消息的创建者，负责创建和推送数据到消息服务器；
消费者：消息的接收方，用于处理数据和确认消息；
代理：就是RabbitMQ本身，用于扮演“快递”的角色，本身不生产消息，只是扮演“快递”的角色。

（一）消息发送原理
首先你必须连接到Rabbit才能发布和消费消息，那怎么连接和发送消息的呢？
你的应用程序和Rabbit Server之间会创建一个TCP连接，一旦TCP打开，并通过了认证，认证就是你试图连接Rabbit之前发送的Rabbit服务器连接信息和用户名和密码，有点像程序连接数据库，使用Java有两种连接认证的方式，后面代码会详细介绍，一旦认证通过你的应用程序和Rabbit就创建了一条AMQP信道（Channel）。

信道是创建在“真实”TCP上的虚拟连接，AMQP命令都是通过信道发送出去的，每个信道都会有一个唯一的ID，不论是发布消息，订阅队列或者接收消息都是通过信道完成的。

（二）为什么不通过TCP直接发送命令？
对于操作系统来说创建和销毁TCP会话是非常昂贵的开销，假设高峰期每秒有成千上万条连接，每个连接都要创建一条TCP会话，这就造成了TCP连接的巨大浪费，而且操作系统每秒能创建的TCP也是有限的，因此很快就会遇到系统瓶颈。

如果我们每个请求都使用一条TCP连接，既满足了性能的需要，又能确保每个连接的私密性，这就是引入信道概念的原因。

在这里插入图片描述

（三）RabbitMQ名称解释
ConnectionFactory（连接管理器）：应用程序与Rabbit之间建立连接的管理器，程序代码中使用；

Channel（信道）： 消息推送使用的通道；

Exchange（交换器）： 用于接受、分配消息；

Queue（队列）： 用于存储生产者的消息；

RoutingKey（路由键）： 用于把生成者的数据分配到交换器上；

BindingKey（绑定键）： 用于把交换器的消息绑定到队列上；

看到上面的解释，最难理解的路由键和绑定键了，那么他们具体怎么发挥作用的，请看下图：

在这里插入图片描述

交换器分类

RabbitMQ的Exchange（交换器）分为四类：
direct（默认）
headers
fanout
topic
其中headers交换器允许你匹配AMQP消息的header而非路由键，除此之外headers交换器和direct交换器完全一致，但性能却很差，几乎用不到，所以我们这里不做解释。

direct交换器

direct为默认的交换器类型，也非常的简单，如果路由键匹配的话，消息就投递到相应的队列，如下图：

在这里插入图片描述

fanout交换器

fanout有别于direct交换器，fanout是一种发布/订阅模式的交换器，当你发送一条消息的时候，交换器会把消息广播到所有附加到这个交换器的队列上。

注意：对于fanout交换器来说routingKey（路由键）是无效的，这个参数是被忽略的。

topic交换器

topic交换器运行和fanout类似，但是可以更灵活的匹配自己想要订阅的信息，这个时候routingKey路由键就排上用场了，使用路由键进行消息（规则）匹配。

topic路由器的关键在于定义路由键，定义routingKey名称不能超过255字节，使用“.”作为分隔符，例如：com.mq.rabbit.error。

匹配规则
匹配表达式可以用“”和“#”匹配任何字符，具体规则如下：
“”匹配一个分段(用“.”分割)的内容；
“#”匹配所有字符；
例如发布了一个“cn.mq.rabbit.error”的消息：
能匹配上的路由键：

cn.mq.rabbit.*
cn.mq.rabbit.#
#.error
cn.mq.#
#

不能匹配上的路由键：

cn.mq.*
*.error
*

消息持久化

RabbitMQ队列和交换器有一个不可告人的秘密，就是默认情况下重启服务器会导致消息丢失，那么怎么保证Rabbit在重启的时候不丢失呢？答案就是消息持久化。

当你把消息发送到Rabbit服务器的时候，你需要选择你是否要进行持久化，但这并不能保证Rabbit能从崩溃中恢复，想要Rabbit消息能恢复必须满足3个条件：

投递消息的时候durable设置为true，消息持久化，代码：channel.queueDeclare(x, true, false, false, null)，参数2设置为true持久化；
设置投递模式deliveryMode设置为2（持久），代码channel.basicPublish(x, x, MessageProperties.PERSISTENT_TEXT_PLAIN,x)，参数3设置为存储纯文本到磁盘；
消息已经到达持久化交换器上；
消息已经到达持久化的队列；

持久化工作原理

Rabbit会将你的持久化消息写入磁盘上的持久化日志文件，等消息被消费之后，Rabbit会把这条消息标识为等待垃圾回收。

持久化的缺点

消息持久化的优点显而易见，但缺点也很明显，那就是性能，因为要写入硬盘要比写入内存性能较低很多，从而降低了服务器的吞吐量，尽管使用SSD硬盘可以使事情得到缓解，但他仍然吸干了Rabbit的性能，当消息成千上万条要写入磁盘的时候，性能是很低的。

所以使用者要根据自己的情况，选择适合自己的方式。

生产端 Confirm 消息确认机制

Confirm 确认机制流程图

在这里插入图片描述

如何实现Confirm确认消息?

第一步:在 channel 上开启确认模式: channel.confirmSelect()
第二步:在 channel 上添加监听: channel.addConfirmListener(ConfirmListener listener);, 监听成功和失败的返回结果，根据具体的结果对消息进行重新发送、或记录日志等后续处理!

注意事项

我们采用的是异步 confirm 模式：提供一个回调方法，服务端 confirm 了一条或者多条消息后 Client 端会回调这个方法。除此之外还有单条同步 confirm 模式、批量同步 confirm 模式，由于现实场景中很少使用我们在此不做介绍，如有兴趣直接参考官方文档。

我们运行生产端会发现每次运行结果都不一样,会有多种情况出现，因为 Broker 会进行优化，有时会批量一次性 confirm ，有时会分开几条 confirm。

Return 消息机制

Return Listener 用于处理一-些不可路由的消息!

消息生产者，通过指定一个 Exchange 和 Routingkey，把消息送达到某一个队列中去，然后我们的消费者监听队列，进行消费处理操作!

但是在某些情况下，如果我们在发送消息的时候，当前的 exchange 不存在或者指定的路由 key 路由不到，这个时候如果我们需要监听这种不可达的消息，就要使用 Return Listener !

在基础API中有一个关键的配置项:Mandatory：如果为 true，则监听器会接收到路由不可达的消息，然后进行后续处理，如果为 false，那么 broker 端自动删除该消息!

Return 消息机制流程图

在这里插入图片描述

Return 消息示例

首先我们需要发送三条消息，并且故意将第 0 条消息的 routing Key设置为错误的，让他无法正常路由到消费端。

mandatory 设置为 true 路由不可达的消息会被监听到，不会被自动删除.即channel.basicPublish(exchangeName, errRoutingKey, true,null, msg.getBytes());

最后添加监听即可监听到不可路由到消费端的消息channel.addReturnListener(ReturnListener r))

消费端 Ack 和 Nack 机制

消费端进行消费的时候，如果由于业务异常我们可以进行日志的记录，然后进行补偿!如果由于服务器宕机等严重问题，那我们就需要手工进行ACK保障消费端消费成功!消费端重回队列是为了对没有处理成功的消息，把消息重新会递给Broker!一般我们在实际应用中，都会关闭重回队列，也就是设置为False。

参考 api

void basicNack(long deliveryTag, boolean multiple, boolean requeue) throws IOException;

void basicAck(long deliveryTag, boolean multiple) throws IOException;

1.需要注意的 basicAck 方法需要传递两个参数
deliveryTag（唯一标识 ID）：当一个消费者向 RabbitMQ 注册后，会建立起一个 Channel ，RabbitMQ 会用 basic.deliver 方法向消费者推送消息，这个方法携带了一个 delivery tag， 它代表了 RabbitMQ 向该 Channel 投递的这条消息的唯一标识 ID，是一个单调递增的正整数，delivery tag 的范围仅限于 Channel
multiple：为了减少网络流量，手动确认可以被批处理，当该参数为 true 时，则可以一次性确认 delivery_tag 小于等于传入值的所有消息
 
2.basicNack方法需要传递三个参数

deliveryTag（唯一标识 ID）：上面已经解释了。
multiple：上面已经解释了。
requeue： true ：重回队列，false ：丢弃，我们在nack方法中必须设置 false，否则重发没有意义。
 

3.basicReject方法需要传递两个参数

deliveryTag（唯一标识 ID）：上面已经解释了。
requeue：上面已经解释了，在reject方法里必须设置true。
 
4.basic.recover：是路由不成功的消息可以使用recovery重新发送到队列中

还要说明一下，建议大家不要重发，重发后基本还是失败，因为出现问题一般都是异常导致的，出现异常的话，我的观点是丢弃这个消息，然后在catch里做补偿操作

补偿机制

出现场景

rabbitmq 默认情况下,如果消费者程序出现异常，会自动实现补偿机制
消费者出现异常,消息不会消费成功

实现原理

rabbitmq 默认情况下,如果消费者程序出现异常，会自动实现补偿机制
消费者出现异常,消息不会消费成功

自定义重试

spring:
  rabbitmq:
    # 连接地址
    host: 127.0.0.1
    # 端口号
    port: 5672
    # 账号
    username: guest
    # 密码
    password: guest
    # 地址
    virtual-host: /
    listener:
      simple:
        retry:
          # 开启消费者（程序出现异常的情况下会）进行重试
          enabled: true
          # 最大重试次数
          max-attempts: 5
          # 重试间隔次数
          initial-interval: 3000
        # 开启手动ack
        acknowledge-mode: manual

如何选择重试机制

需要重试

调用第三方接口,提示连接超时,可以重试通常来说:无需发布版本即可解决的异常都可以重试

无需重试

系统异常,如:空指针,数据转换异常等

通常来说:需发布版本即可解决的异常都无需重试

采用日志记录+定时任务+人工补偿进行解决

幂等性

设置消息id,如果消息消费成功,不在消费
如果业务逻辑中存在唯一id,如订单id,也可用订单id判重

设置自动ACK弊端：
1.设置消息自动ack，这种情况下，MQ只要确认消息发送成功，无须等待应答就会丢弃消息，这会导致客户端还未处理完时，出异常或断电了，导致消息丢失的后果，
2.自动ack还有个弊端，只要队列不空，RabbitMQ会源源不断的把消息推送给客户端，而不管客户端能否消费的完（不限流）

https://blog.csdn.net/youbl/article/details/80425959?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase

weixin_42904118

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
RabbitMQ精讲

RabbitMQ消息确认机制生产端 Confirm 消息确认机制Confirm 确认机制流程图如何实现Confirm确认消息?注意事项Return 消息机制Return 消息机制流程图Return 消息示例消费端 Ack 和 Nack 机制参考 api补偿机制出现场景实现原理自定义重试如何选择重试机制生产端 Confirm 消息确认机制Confirm 确认机制流程图如何实现Confirm确认消息?第一步:在 channel 上开启确认模式: channel.confirmSelect()第二步:
复制链接

扫一扫