浅析RabbitMQ

最新推荐文章于 2024-08-28 15:35:29 发布

吃en橙

最新推荐文章于 2024-08-28 15:35:29 发布

阅读量730

点赞数 10

文章标签： rabbitmq 分布式

本文链接：https://blog.csdn.net/weixin_67847615/article/details/140506637

版权

一、MQ

MQ的基本概念：RabbitMQ是一个开源的消息代理和队列服务器，它使用Erlang语言编写并运行在多种操作系统上，如Linux、Windows等。RabbitMQ可以接收、存储和转发消息（也称为“事件”）到连接的客户端。它适用于多种场景，包括异步通信、流量削峰、应用解耦等。
同步和异步
- 同步: 多个服务之间顺序执行
  - 优点: 时效性强
  - 缺点: 耦合度高,性能降低,有额外的资源消耗,有级联失效的问题
- 异步: 多个服务之间同时执行
  - 事件驱动
    - 事件发布者(Publisher)
    - 中间人(Broker)
    - 事件订阅者(Consumer)
MQ的优势和劣势
- 优势：
  - 应用解耦：MQ允许生产者和消费者彼此独立运作，无需直接通信。生产者将消息发送到队列，消费者从队列中读取消息。这意味着生产者和消费者可以有不同的运行速度、不同的可用性窗口，甚至可以完全不知道对方的存在。
  - 异步提速：MQ支持异步处理，生产者可以立即发送消息而无需等待消费者的响应，从而提高系统的响应速度和吞吐量。消费者可以在自己的时间和节奏上处理消息，这有助于避免阻塞和提高系统的整体效率。
  - 削峰填谷：在高流量或高负载情况下，MQ可以作为一种缓冲，暂时存储消息直到消费者准备好处理它们。这有助于平衡负载，防止系统因瞬间高峰而崩溃。
常见的MQ产品

追求可用性：Kafka、 RocketMQ 、RabbitMQ

追求可靠性：RabbitMQ、RocketMQ

追求吞吐能力：RocketMQ、Kafka

追求消息低延迟：RabbitMQ、Kafka

二、RabbitMQ

RabbitMQ
AMQP：Advanced Message Queuing Protocol（高级消息队列协议），是一个网络协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。2006年，AMQP 规范发布。类比HTTP。2007年，Rabbit 技术公司基于 AMQP 标准开发的 RabbitMQ 1.0 发布。RabbitMQ 采用 Erlang 语言开发。 Erlang 语言由 Ericson 设计，专门为开发高并发和分布式系统的一种语言，在电信领域使用广泛。
Linux安装rabbitMQ，启动rabbitMQ服务 http://localhost:15672
- rabbitmqctl add_user admin Aq71056r 创建用户: admin，密码：Aq71056r
- rabbitmqctl set_user_tags admin administrator 设置用户标签为administrator
- 5672是rabbitMQ的客户端端口
- 15672是rabbitMQ的ui界面访问端口
- 25672是rabbitMQ中的erlang发现口

Producer: 服务的生产者
Consumer: 服务的消费者
Broker：接收和分发消息的应用,RabbitMQ Server就是 Message Broker
Virtual host：出于多用户和安全因素设计的，把 AMQP 的基本组件划分到一个虚拟的分组中，类似于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务时，可以划分出多个vhost，每个用户在自己的 vhost 创建 exccange／queue 等
Connection：publisher／consumer 和 broker 之间的 TCP 连接
Channel：如果每一次访问 RabbitMQ 都建立一个 Connection，在消息量大的时候建立 TCP Connection 的开销将是巨大的，效率也较低。Channel 是在 Connection 内部建立的逻辑连接,所以Connection中可以包含多个Channel
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 信息被保存到 exccange 中的查询表中，用于 message 的分发依据

RabbitMQ 提供了7 种消息模型：

发布确认模式的工作原理如下：
- 简单模式：最基础的消息模型，用于展示如何发送和接收一条消息。它涉及到一个生产者向一个队列发送消息，一个消费者从队列中消费消息。
- 工作队列模式：在工作队列模型中，多个消费者共享一个队列，消息会被平均分配给各个消费者。这种模型适合处理耗时的任务，如图像处理、数据分析等。
- 发布与订阅模式：发布者发送消息到一个交换机，而多个订阅者绑定到这个交换机上。任何发送到交换机的消息都会被广播给所有订阅者。这种模型适用于一对多的通信场景。
- 路由模式：在路由模型中，消息被发送到具有特定路由键的交换机，而队列则绑定到交换机上，并指定一个路由键。只有当消息的路由键与队列的绑定键匹配时，消息才会被路由到相应的队列。
- 主题模式：主题模型是路由模型的扩展，它允许使用通配符来进行路由键的匹配，从而实现更复杂的订阅模式。主题模型适用于需要按类别或主题订阅消息的场景。
- RPC 远程调用模式：RPC模型允许远程过程调用，即一个生产者发送请求消息到队列，等待一个回复。消费者处理请求并发送回复消息。这种模型实现了请求-响应的通信模式。
- 发布确认模式：是一种保证消息可靠性的机制，它确保消息发布者能够得知消息是否成功地到达了RabbitMQ服务器。在没有启用发布确认模式的情况下，如果RabbitMQ服务器在消息到达之前崩溃，生产者将无法获知消息是否已安全存储。启用发布确认模式后，生产者可以得到关于消息投递状态的反馈，从而采取适当的措施，如重新发送失败的消息。
- 确认模式开启：生产者需要将信道设置为确认模式。在Java中，可以通过Channel.confirmSelect()方法来开启确认模式。
- 消息ID分配：当确认模式开启后，所有通过该信道发布的消息都将被分配一个唯一的ID，从1开始递增。
- 确认应答：当消息被成功投递到所有匹配的队列后，RabbitMQ会发送一个确认应答给生产者，确认应答中包含消息的ID。如果消息未能被投递（例如，由于队列满了或者RabbitMQ服务器内部错误），RabbitMQ会发送一个NACK（未确认）消息给生产者。
- 同步确认和异步确认：
  1. 同步确认：生产者在发送每条消息后会阻塞，直到收到RabbitMQ的确认或NACK应答。这种方式可以确保每条消息的投递状态都被确认，但会降低性能，因为生产者需要等待每个确认应答。
  2. 异步确认：生产者可以继续发送消息，而无需等待每个确认应答。RabbitMQ会异步地发送确认应答，生产者需要实现一个监听器来处理确认和NACK消息。这种方式可以提高性能，但需要更复杂的错误处理逻辑。
- 批量确认：异步确认模式还支持批量确认，即生产者可以一次性确认一系列连续的消息ID，而不是逐个确认。
- 持久化确认：如果消息需要持久化存储（例如，在磁盘上），确认应答会在消息被写入磁盘后发送，以确保消息在RabbitMQ重启后仍可恢复。
- 如何保证消息的可靠性？
  - 持久化：设置消息和队列为持久化，确保消息存储在磁盘上。
  - publisher confirms：生产者确认，确保消息被Broker接收。
  - transactions：事务，确保消息的一致性。
  - TTL（Time To Live）：消息过期时间，防止消息无限期积压。
- 如何处理消息丢失？
  - 使用publisher confirms：确保消息被至少一个Broker节点接收。
  - 镜像队列：通过集群模式和镜像队列配置，保证消息在多个节点上有备份。
  - 死信队列：无法正常消费的消息可以被发送到死信队列，便于后续分析和处理。
- RabbitMQ的消息确认机制是什么？
  - Basic.Ack：消费者成功处理消息后向Broker发送确认。
  - Basic.Nack：消费者未能处理消息时，可以选择拒绝或重新入队列。
  - Publisher Confirms：生产者确认，Broker在消息持久化后向生产者发送确认。
- 如何处理消息积压？
  - 增加消费者：增加消费者实例以加快消息处理速度。
  - 优化消费逻辑：减少消息处理时间。
  - 动态调整QoS（Quality of Service）：限制消费者预取消息数量，避免单个消费者阻塞。
  - 死信队列和重试策略：对无法处理的消息进行特殊处理，避免影响主线程。
- RabbitMQ集群如何工作？
  - RabbitMQ集群通过多个节点共同工作，提高系统的可用性和伸缩性。集群中的节点可以共享用户、队列元数据等，但消息并不在节点间自动复制，除非使用镜像队列。镜像队列可以确保消息在多个节点上有副本，从而提高消息的可用性。
- RocketMQ与RabbitMQ如何选择？
  - 如果你的系统是多语言环境，需要高度灵活的消息路由，并且对稳定性要求极高，RabbitMQ可能是更好的选择。
  - 如果您的应用场景侧重于高性能、高吞吐量，尤其是处理大量消息的分布式系统，并且主要使用Java技术栈，或者对消息的顺序性有严格要求，RocketMQ则更适合。
  - 考虑到未来可能的扩展需求、团队的技术栈偏好、以及是否有特定的业务场景需求（如严格的顺序消息、高可用性要求），综合权衡两者的优势与劣势，做出最适合您项目的决定。