当前位置: 首页 > news >正文

RabbitMQ 工作模式

RabbitMQ 一共有 7 中工作模式,可以先去官网上了解一下(一下截图均来自官网):RabbitMQ 官网

Simple

  • P:生产者,要发送消息的程序;
  • C:消费者,消息的接受者;
  • hello:要发送的消息,这个消息存在在一个队列中;

“简单模式”:这种模式的消息只能被消费一次,也称为“点对点”模式(Point-to-Point),适用于消息只能被单个消费者处理的场景,并且也是最简单的一种模式。

Work Queue

这中模式叫做“工作队列模式”,从图上看就可以发现它是一对多模型,一个生产者,多个消费者,生产者产生的消息是由多个消费者共同消费的,也就是所消息的总量是不会变的,适合集群环境中做异步处理。比如一个订单服务,下单成功之后,订单消息就会发送到 RabbitMQ ,然后订单服务就会从 RabbitMQ 中获取订单详情并进行下一步的处理(在多个订单服务之间进行分配)。

Publish/Subscribe

这种叫“发布/订阅模式”,相比于“工作队列模式”只是在生产者和队列之间加一层 X (交换机)。

交换机(Exchange)的作用就是将生产者发送的消息按照一定的规则路由到一个或多个队列中,它只负责转发消息,不具备存储消息的能力,因此如果没有任何队列与 Exchange 绑定,或者没有符合路由规则的队列,那么消息就会丢失;RabbitMQ 的交换机一共有一下几种类型:

  • fanout:广播类型,将所有消息交给所有绑定到交换机的队列(发布/订阅模式);
  • direct:定向路由类型,把消息交给符合指定 routing key 的队列;
  • topic:通配符类型,把消息交给符合 routing pattern (路由模式)的队列;
  • headers:这个类型的交换机不依赖于路由键的匹配规则来路由消息,而是根据发送的消息内容中的 headers 属性进行匹配,但是这个交换机的性能较差使用频率也少;

这里还有两个概念就是 RountingKey 和 BindingKey:

  • RoutingKey:路由键,生产者将消息发送给交换器的时候会指定路由键,然后交换机就会根据这个路由键去决定下一步该怎么做;
  • BaindingKey:绑定键,通过 BindingKey 将交换机与队列关联起来,在绑定的时候一般会指定一个 BindingKey,这样 RabbitMQ 就可以根据 RoutingKey 和 BindingKey 来正确转发消息到指定的队列中;

Routing

这种叫“路由模式”,在“发布/订阅模式”的基础上,增加 RoutingKey,发布订阅模式就是直接把消息全部发送到与交换机关联的队列中,没有其他规则判断;路由模式下,Exchange 会根据用户传过来的 RoutingKey 和交换机与队列绑定的 BindingKey 进行比较,只有相同的话才会把消息发送到对应对立中,适合需要根据特定规则分发消息的场景;

Topics

这种叫做“通配符模式”,如果理解了上面的“路由模式”的话理解这个应该不难,它比“路由模式”更加灵活,Exchange 可以根据使用通配符的方式对消息路由到指定队列,比如要是 RoutintKey :test.orange.rabbit 的话,那么 Exchange 会将消息发送到 Q1 和 Q2 中;

RPC

RPC 通讯就是客户端去远程调用服务器的服务,在通讯过程中,没有生产者和消费者;客户端发送消息到一个指定的队列(request queue),并在消息属性中设置 replyTo 字段,这个字段的意思就是指定一个回调队列用于接收服务端的响应,然后服务端接收到请求之后,处理请求并发送响应消息到 replyTo 指定的回调队列中,客户端再再回调队列上等待响应消息,一旦收到消息,客户端就会检查消息的 correlationId 属性,以确保它是期望的响应,其中 correlationId 的值也是客户端定义的,然后服务端再根据约定好的规则进行检查;

Publisher Confirms

“发布确认模式”是 RabbitMQ 提供的一种确保消息可靠发送到 RabbitMQ 服务器的机制。在这中模式下,生产者可以等待 RabbitMQ 服务器的确认,确保消息已经被正确接收并处理:

  • 生产者将 channel 设置为 confirm 模式,发布的每一条消息都会获得一个唯一的ID,生产者可以将这些序列号与消息关联起来,用来跟踪消息的状态。
  • 当消息被 RabbitMQ 服务器接收并处理后,服务器会异步的向生产者发送一个确认 ACK 给生产者(包含消息的唯一ID),表明消息已经正确到达。

通过 Publisher Confirm 模式,可以避免消息丢失的场景,适合对数据安全性较高的场景如金融交易和订单处理等等。

相关文章:

  • Android音频解码中的时钟同步问题:原理、挑战与解决方案
  • Power BI 实操案例,将度量值转化为切片器(动态切换分析指标)
  • Redis——达人探店
  • 产品思维30讲-(梁宁)--实战2
  • 【Linux】在Arm服务器源码编译onnxruntime-gpu的whl
  • LeRobot 项目部署运行逻辑(七)—— ACT 在 Mobile ALOHA 训练与部署
  • 系统架构-嵌入式系统架构
  • python-75-Nacos技术之Python+Nacos实现微服务架构
  • LInux系统文件与目录管理(二)
  • 风电功率预测方法与准确性提升方案详解
  • node .js 启动基于express框架的后端服务报错解决
  • Spark,RDD中的转换算子
  • 《Vue.js》阅读之响应式数据与副作用函数
  • Html5新特性_js 给元素自定义属性_json 详解_浅克隆与深克隆
  • 动态会话日志记录 ngx_stream_log_module
  • 介电测试的基本原理与方法及应用领域
  • 摆脱拖延症的详细计划示例
  • C——五子棋小游戏
  • 坐标系概述
  • 湖北理元理律师事务所:企业债务危机的“止血”与“造血”平衡术
  • 特朗普访中东绕行以色列,专家:凸显美以利益分歧扩大
  • 教育部基础教育教指委:小学阶段禁止学生独自使用开放式内容生成功能
  • 媒体谈法院就“行人相撞案”道歉:执法公正,普法莫拉开“距离”
  • 新买宝马竟是“维修车”,男子发视频维权被4S店索赔100万
  • 见微知沪|优化营商环境,上海为何要当“细节控”自我加压?
  • 奥利弗·斯通回顾越战50周年:我们不善于总结历史教训