消息队列 RabbitMQ 工作流程

消息队列概述

  1. 大多数应用中,可以通过消息中间件来提升系统的异步通信以及应用解耦的能力。
  2. 当消息发送者发送消息以后,将由消息代理接管,保证消息传递到指定目的地
  3. 消息队列主要有两种类型的目的地:队列和主题。队列用于点对点通信模式中,而主题用于发布/订阅模式中。
  4. 点对点模式:
    a. 消息发送者将消息发送给消息代理,消息代理将其放入一个队列。消息接收者从队列中获取消息后,消息被移除队列。
    b. 一条消息只有唯一的发送者和接收者,但并不意味着只能有一个接收者。
  5. 发布/订阅模式:发送者(消息发布者)发送消息到主题,多个接收者(消息订阅者)监听(订阅)这个主题。只要消息到达主题,所有订阅者都会收到消息。
  6. JMS(Java Message Service):基于JVM消息代理的规范。ActiveMQ、HornetMQ是其实现。
  7. AMQP(Advanced Message Queuing Protocol):高级消息队列协议,RabbitMQ是其实现。
  8. Spring 对JSM 和 AMQP 都提供了支持
    a. spring-jms 提供了对JMS的支持
    b. spring-rabbit 提供了对AMQP的支持
    c. JmsTemplate和RabbitTemplate可以发送消息
    d. @JmsListener,@RabbitListener 注解在方法上监听消息代理发布的消息
    c. @EnableJms、@EnableRabbit 开启对消息队列的支持

RabbitMQ相关概念

  1. Message 消息,消息是不具名,它由消息头和消息体组成。消息体是不透明的,而消息头则由一系列的可选属性组成,包括routing-key(路由键)、priority(相当于其它消息的优先权)、delivery-mode等。
  2. Publisher 消息的生产者
  3. Exchange 交换器,用来接收生产者发送的消息并将这些消息路由给服务器中的队列。Exchange 有4种类型:direct、fanout、topic、headers,不同类型的Exchange转发消息的策略有所区别。
  4. Queue 消息队列,用来保存消息直到消费者消费消息。一条消息可以保存在一个或多个队列中。
  5. Binding 绑定,用于Queue 和 Exchange 之间的关联。一个绑定就是基于 routing-key 将 exchange 和 Queue 连接起来的路由规则。
  6. Channel 信道,多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内的虚拟连接,AMQP命令都是通过信道发出去的。不管是消息发布,还是接收消息,这些动作都是通过信道完成的。因为对于操作系统来说,建立和销毁TCP连接都是非常昂贵的开销,所以引入信道的概念,以复用一条TCP连接。
  7. Consumer 消费者
  8. Virtual Host 虚拟主机,表示一批交换器、消息队列和相关对象的组合。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个vhost本质上是一个mini版的RabbitMQ服务器,拥有自己的队列、交换器、绑定和权限机制。RabbitMQ默认的 vhost是 /。
  9. Broker 表示消息队列服务器实体。
  10. Connection 网络连接,如一个TCP连接。
    在这里插入图片描述
### Redis 消息队列RabbitMQ 的使用场景与性能对比 #### 功能复杂度 RabbitMQ 提供了丰富的功能集,包括复杂的路由规则、死信队列以及延迟队列等功能。这些特性使得它非常适合需要高度定制化的消息传递场景[^2]。相比之下,Redis 的消息队列功能较为基础,主要依赖其发布订阅模型或者列表数据结构来实现简单的消息队列功能。 #### 性能表现 在高吞吐量和低延迟的要求下,Redis 表现出色。由于 Redis 将所有数据存储在内存中并支持高效的读写操作,因此它的速度通常优于 RabbitMQ[^3]。然而,在面对大规模消息堆积的情况下,Redis 的内存消耗会显著增加,可能导致性能下降甚至崩溃[^2]。 #### 部署与维护 RabbitMQ 的部署过程相对繁琐,涉及多个方面的考量,比如集群搭建、数据持久化策略制定及后续的性能优化等工作,这无疑提高了系统的运维门槛[^2]。与此同时,为了充分发挥 RabbitMQ 的潜力,开发者还需掌握 AMQP 协议及其内部工作机制等相关知识[^4]。与此相反的是,基于 Redis 构建的消息队列则显得更加轻便快捷,易于集成到现有的应用程序当中去[^3]。 #### 数据可靠性 尽管 Redis 支持 AOF (Append Only File) 或 RDB (Redis Database Backup) 这样的持久化方式以保障数据安全,但是在某些极端条件下(例如突然断电),仍有可能造成少量的数据损失;再加上其 Pub/Sub 不具备任何形式上的确认机制,这意味着如果订阅端未能及时接收信息,则该条目极有可能永久遗失[^2]。另一方面,得益于 Erlang 编程语言天生优秀的容错能力和内置事务管理器的帮助,即使遭遇突发状况,RabbitMQ 也能较好地保护未被成功投递出去的信息免受损害[^4]。 ```python import pika connection = pika.BlockingConnection(pika.ConnectionParameters('localhost')) channel = connection.channel() channel.queue_declare(queue='hello') def callback(ch, method, properties, body): print(f"Received {body}") channel.basic_consume(queue='hello', on_message_callback=callback, auto_ack=True) print('Waiting for messages.') channel.start_consuming() ``` 以上是一个利用 Python 库 `pika` 来连接 RabbitMQ 并消费消息的例子。 ```python import redis r = redis.Redis(host='localhost', port=6379, db=0) pubsub = r.pubsub() pubsub.subscribe(['test-channel']) for message in pubsub.listen(): if message['type'] == 'message': print(message['data']) ``` 这是另一个采用 Python 官方推荐库 `redis-py` 实现监听来自指定频道广播事件的功能片段。 #### 结论 综上所述,当项目需求侧重于简化架构设计同时追求极致效率时可优先选用 Redis;而对于那些期望获得更全面解决方案的企业级应用而言,或许 RabbitMQ 才是最理想的选择[^1]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值