RabbitMQ 的7种工作模式

        RabbitMQ 共提供了7种⼯作模式,进⾏消息传递,.

官⽅⽂档:RabbitMQ Tutorials | RabbitMQ

1.Simple(简单模式)

        P:⽣产者,也就是要发送消息的程序

        C:消费者,消息的接收者

        Queue:消息队列,图中⻩⾊背景部分.类似⼀个邮箱,可以缓存消息;⽣产者向其中投递消息,消费者从其中取出消息.

        特点:⼀个⽣产者P,⼀个消费者C,消息只能被消费⼀次.也称为点对点(Point-to-Point)模式.适⽤场景:消息只能被单个消费者处理

2.Work Queue(工作队列)

        ⼀个⽣产者P,多个消费者C1,C2.在多个消息的情况下,Work Queue 会将消息分派给不同的消费者,每个消费者都会接收到不同的消息.

        特点:消息不会重复,分配给不同的消费者.

        适⽤场景:集群环境中做异步处理。⽐如 12306 短信通知服务,订票成功后,订单消息会发送到RabbitMQ,短信服务从 RabbitMQ 中获取订单信息,并发送通知信息(在短信服务之间进⾏任务分配)

3.Publish/Subscribe(发布/订阅)

图中 X 表⽰交换机,在订阅模型中,多了⼀个 Exchange ⻆⾊,过程略有变化

        ⼀个⽣产者P,多个消费者C1,C2,X 代表交换机消息复制多份,每个消费者接收相同的消息 ⽣产者发送⼀条消息,经过交换机转发到多个不同的队列,多个不同的队列就有多个不同的消费者         适合场景:消息需要被多个消费者同时接收的场景.如:实时通知或者⼴播消息

        ⽐如中国⽓象局发布"天⽓预报"的消息送⼊交换机,新浪,百度,搜狐,⽹易等⻔户⽹站接⼊消息,通过队列绑定到该交换机,⾃动获取⽓象局推送的⽓象数据

概念介绍:Exchange:交换机(X)

        作⽤:⽣产者将消息发送到 Exchange,由交换机将消息按⼀定规则路由到⼀个或多个队列中(上图中⽣产者将消息投递到队列中,实际上这个在 RabbitMQ 中不会发⽣,因为在 RabbitMQ  中生产者的信息要经过交换机路由,不会直接发给队列

        RabbitMQ 交换机有四种类型:

        fanout,direct,topic,headers,不同类型有着不同的路由策略.AMQP 协议⾥还有另外两种类型, System 和 ⾃定义,此处不再描述.

        1. Fanout:⼴播,将消息交给所有绑定到交换机的队列( Publish/Subscribe 模式)

        2. Direct:定向,把消息交给符合指定 routing key 的队列(Routing模式)

        3. Topic:通配符,把消息交给符合 routing pattern(路由模式)的队列 (Topics模式)

        4. headers 类型的交换器不依赖于路由键的匹配规则来路由消息,⽽是根据发送的消息内容中的 headers 属性进⾏匹配.headers 类型的交换器性能会很差,⽽且也不实⽤,基本上不会看到它的存在.

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

        RoutingKey 路由键.⽣产者将消息发给交换器时,指定的⼀个字符串,⽤来告诉交换机应该如何处理这个消息.

        BindingKey:绑定.RabbitMQ 中通过Binding(绑定)将交换器与队列关联起来,在绑定的时候⼀般会指定⼀个 Binding Key,这样 RabbitMQ 就知道如何正确地将消息路由到队列了.

⽐如下图:如果在发送消息时,设置了 RoutingKey 为 orange,消息就会路由到Q1

        当消息的 Routingkey与队列绑定的 Bindingkey 相匹配时,消息才会被路由到这个队列. BindingKey其实也属于路由键中的⼀种,

        官⽅解释为:the routingkey to use for the binding. 可以翻译为:在绑定的时候使⽤的路由键.⼤多数时候,包括官⽅⽂档和 RabbitMQ Java API 中都把 BindingKey 和 RoutingKey看作RoutingKey,为了避免混淆,可以这么理解:

        1. 在使⽤绑定的时候,需要的路由键是 BindingKey.

        2. 在发送消息的时候,需要的路由键是 RoutingKey.

4.Routing(路由模式)

        路由模式是发布订阅模式的变种,在发布订阅基础上,增加路由 key 发布订阅模式是⽆条件的将所有消息分发给所有消费者,路由模式是 Exchange 根据 RoutingKey 的规则,将数据筛选后发给对应的消费者队列 适合场景:需要根据特定规则分发消息的场景.

        ⽐如系统打印⽇志,⽇志等级分为 error,warning,info,debug,就可以通过这种模式,把不同的⽇志发送到不同的队列,最终输出到不同的文件

5.Topics(通配符模式)

        路由模式的升级版,在 routingKey 的基础上,增加了通配符的功能,使之更加灵活.Topics 和Routing 的基本原理相同,即:⽣产者将消息发给交换机,交换机根据 RoutingKey 将消息转 发给与 RoutingKey 匹配的队列.类似于正则表达式的⽅式来定义 Routingkey 的模式.

        不同之处是:routingKey 的匹配⽅式不同,Routing 模式是相等匹配,topics 模式是通配符匹配.

        在 topic 类型的交换机在匹配规则上,有些要求:

        1. RoutingKey是⼀系列由点( . )分隔的单词,⽐如" stock.usd.nyse "," nyse.vmw ", " quick.orange.rabbit "

        2. BindingKey 和 RoutingKey ⼀样,也是点( . )分割的字符串.

        3. Binding Key中可以存在两种特殊字符串,⽤于模糊匹配

              * 表⽰⼀个单词,如 m ,mq

              # 表⽰多个单词(0-N个) ⽐如

                 • Binding Key为"d.a.b"会同时路由到 Q1 和 Q2

                • Binding Key 为"d.a.f" 会路由到Q1

                • Binding Key 为"c.e.f" 会路由到Q2

                • Binding Key 为"d.b.f" 会被丢弃,或者返回给⽣产者(需要设置 mandatory 参数)

        适合场景:需要灵活匹配和过滤消息的场景

6.RPC(RPC通信)

        在 RPC 通信的过程中,没有⽣产者和消费者,⽐较像咱们 RPC 远程调⽤,⼤概就是通过两个队列实现了⼀个可回调的过程.

        1. 客户端发送消息到⼀个指定的队列,并在消息属性中设置 replyTo 字段,这个字段指定了⼀个回调队列,⽤于接收服务端的响应.

        2. 服务端接收到请求后,处理请求并发送响应消息到 replyTo 指定的回调队列

        3. 客户端在回调队列上等待响应消息.⼀旦收到响应,客户端会检查消息的 correlationId 属性,以确保它是所期望的响应.

7.Publisher Confirms(发布确认)

        Publisher Confirms 模式是 RabbitMQ 提供的⼀种确保消息可靠发送到 RabbitMQ 服务器的机制。在这种模式下,⽣产者可以等待 RabbitMQ 服务器的确认,以确保消息已经被服务器接收并处理.

        1. ⽣产者将 Channel 设置为 confirm 模式(通过调⽤ channel.confirmSelect()完成)后,发布的每⼀条消息都会获得⼀个唯⼀的ID,⽣产者可以将这些序列号与消息关联起来,以便跟踪消息的状态.

        2. 当消息被 RabbitMQ 服务器接收并处理后,服务器会异步地向⽣产者发送⼀个确认(ACK)给⽣产者 (包含消息的唯⼀ID),表明消息已经送达.通过 Publisher Confirms 模式,⽣产者可以确保消息被 RabbitMQ 服务器成功接收,从⽽避免消息丢失的问题.

消息丢失问题

        作为消息中间件,都会⾯临消息丢失的问题.消息丢失⼤概分为三种情况:

        1. ⽣产者问题.因为应⽤程序故障,⽹络抖动等各种原因,⽣产者没有成功向 broker 发送消息.

        2. 消息中间件⾃⾝问题.⽣产者成功发送给了Broker,但是 Broker 没有把消息保存好,导致消息丢失.

        3. 消费者问题.Broker 发送消息到消费者,消费者在消费消息时,因为没有处理好,导致 broker 将消费失败的消息从队列中删除了.

        RabbitMQ 也对上述问题给出了相应的解决⽅案.问题 2 可以通过持久化机制.问题 3 可以采⽤消息应答机制.针对问题1,可以采⽤发布确认( Publisher Confirms )机制实现.

        适⽤场景:对数据安全性要求较⾼的场景.比如⾦融交易,订单处理.

原理

        ⽣产者将信道设置成 confirm(确认) 模式,⼀旦信道进⼊ confirm 模式,所有在该信道上⾯发布的消息都会被指派⼀个唯⼀的ID(从1开始),⼀旦消息被投递到所有匹配的队列之后,RabbitMQ 就会发送⼀个确认给⽣产者(包含消息的唯⼀ID)

        这就使得⽣产者知道消息已经正确到达⽬的队列了,如果消息和队列是可持久化的,那么确认消息会在将消息写⼊磁盘之后发出.broker 回传给⽣产者的确认消息中 deliveryTag 包含了确认消息的序号,此外 broker 也可以设置 channel.basicAck⽅法中的 multiple 参数,表⽰到这个序号之前的所有消息都已经得到了处理.

        发送⽅确认机制最⼤的好处在于它是异步的,⽣产者可以同时发布消息和等待信道返回确认消息.

        1. 当消息最终得到确认之后,⽣产者可以通过回调⽅法来处理该确认消息.

        2. 如果 RabbitMQ 因为⾃⾝内部错误导致消息丢失,就会发送⼀条 nack(Basic.Nack) 命令,⽣产者同样 可以在回调⽅法中处理该 nack 命令

实现思路

        异步 confirm ⽅法的编程实现最为复杂. Channel 接⼝提供了⼀个⽅法 addConfirmListener. 这个⽅法可以添加 ConfirmListener 回调接⼝. ConfirmListener 接⼝中包含两个⽅法:

        handleAck(long deliveryTag, boolean multiple) 和 handleNack(long deliveryTag, boolean multiple) ,分别对应处理 RabbitMQ 发送给⽣产者的 ack(成功处理) 和 nack(未成功处理)

        deliveryTag 表⽰发送消息的序号.multiple 表⽰是否批量确认.我们需要为每⼀个 Channel 维护⼀个已发送消息的序号集合.当收到 RabbitMQ 的 confirm 回调时,从集合中删除对应的消息.当Channel 开启 confirm 模式后,channel 上发送消息都会附带⼀个从 1 开始递增的 deliveryTag 序号.我们可以使⽤ SortedSet 的有序性来维护这个已发消息的集合.

        1. 当收到 ack 时,从序列中删除该消息的序号.如果为批量确认消息,表⽰⼩于等于当前序号 deliveryTag 的消息都收到了,则清除对应集合

        2. 当收到 nack 时,处理逻辑类似,不过需要结合具体的业务情况,进⾏消息重发等操作.

3种消息确认模式的对比

        可以看到异步确认模式的效率远超于另外的两种消息确认模式。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/494825.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

WebAPI编程(第一天,第二天)

WebAPI编程(第一天,第二天) day01 - Web APIs 1.1. Web API介绍 1.1.1 API的概念1.1.2 Web API的概念1.1.3 API 和 Web API 总结 1.2. DOM 介绍 1.2.1 什么是DOM1.2.2. DOM树 1.3. 获取元素 1.3.1. 根据ID获取1.3.2. 根据标签名获取元素1.3.…

java如何使用poi-tl在word模板里渲染多张图片

1、poi-tl官网地址 http://deepoove.com/poi-tl/ 2、引入poi-tl的依赖 <dependency><groupId>com.deepoove</groupId><artifactId>poi-tl</artifactId><version>1.12.1</version></dependency>3、定义word模板 释义&#xf…

web三、 window对象,延时器,定时器,时间戳,location对象(地址),本地存储-localStorage,数组去重new Set

一、window对象 window对象 是一个全局对象&#xff0c;也可以说是JavaScript中的 顶级对象 像document、alert()、console.log()这些都是window的属性&#xff0c;基本BOM的属性和方法都是window的 所有通过 var定义 在全局作用域中的 变量 、 函数 都会变成window对象的属…

利用Spring Cloud Gateway Predicate优化微服务路由策略

利用Spring Cloud Gateway Predicate优化微服务路由策略 一、Predicate简介 Spring Cloud Gateway 是 Spring 生态系统中用于构建 API 网关的框架&#xff0c;它基于 Project Reactor 和 Netty 构建&#xff0c;旨在提供一种高效且灵活的方式来处理 HTTP 请求和响应。 Spring …

C#代码实现把中文录音文件(.mp3 .wav)转为文本文字内容

我们有一个中文录音文件.mp3格式或者是.wav格式&#xff0c;如果我们想要提取录音文件中的文字内容&#xff0c;我们可以采用以下方法&#xff0c;不需要使用Azure Speech API 密钥注册通过离线的方式实现。 1.首先我们先在NuGet中下载两个包 NAudio 2.2.1、Whisper.net 1.7.3…

CASA(Carnegie-Ames-Stanford Approach) 模型原理及实践

植被作为陆地生态系统的重要组成部分对于生态环境功能的维持具有关键作用。植被净初级生产力&#xff08;Net Primary Productivity, NPP&#xff09;是指单位面积上绿色植被在单位时间内由光合作用生产的有机质总量扣除自养呼吸的剩余部分。植被NPP是表征陆地生态系统功能及可…

申请腾讯混元的API Key并且使用LobeChat调用混元AI

申请腾讯混元的API Key并且使用LobeChat调用混元AI 之前星哥写了一篇文章《手把手教拥有你自己的大模型ChatGPT和Gemini等应用-开源lobe-chat》搭建的开源项目&#xff0c;今天这篇文章教大家如何添加腾讯云的混元模型&#xff0c;并且使用LobeChat调用腾讯混元AI。 申请腾讯混…

alertmanager告警持久化方案:alertsnitch

Prometheus告警记录持久化 Prometheus将基于告警规则生成的告警存储为时间序列&#xff0c;不会将Alertmanager的告警信息持久化存储&#xff0c; 那么针对历史告警的检索、统计等需求就无法实现。因此需要一种持久化机制用于存储历史告警信息&#xff0c; 本文主要探究基于al…

springboot481基于springboot社区老人健康信息管理系统(论文+源码)_kaic

摘 要 如今社会上各行各业&#xff0c;都喜欢用自己行业的专属软件工作&#xff0c;互联网发展到这个时候&#xff0c;人们已经发现离不开了互联网。新技术的产生&#xff0c;往往能解决一些老技术的弊端问题。因为传统社区老人健康信息管理系统信息管理难度大&#xff0c;容错…

109.【C语言】数据结构之求二叉树的高度

目录 1.知识回顾&#xff1a;高度&#xff08;也称深度&#xff09; 2.分析 设计代码框架 返回左右子树高度较大的那个的写法一:if语句 返回左右子树高度较大的那个的写法二:三目操作符 3.代码 4.反思 问题 出问题的代码 改进后的代码 执行结果 1.知识回顾&#xf…

重温设计模式--享元模式

文章目录 享元模式&#xff08;Flyweight Pattern&#xff09;概述享元模式的结构C 代码示例1应用场景C示例代码2 享元模式&#xff08;Flyweight Pattern&#xff09;概述 定义&#xff1a; 运用共享技术有效地支持大量细粒度的对象。 享元模式是一种结构型设计模式&#xff0…

Pytorch | 从零构建EfficientNet对CIFAR10进行分类

Pytorch | 从零构建EfficientNet对CIFAR10进行分类 CIFAR10数据集EfficientNet设计理念网络结构性能特点应用领域发展和改进 EfficientNet结构代码详解结构代码代码详解MBConv 类初始化方法前向传播 forward 方法 EfficientNet 类初始化方法前向传播 forward 方法 训练过程和测…

【教程】第十一章 子任务 工时——化繁为简

小伙伴们&#xff0c;终于迎来了新章节&#xff01;随着业务的扩展&#xff0c;任务越来越多&#xff0c;越来越复杂&#xff0c;我们逐渐意识到&#xff0c;简单的任务管理已经不够用了。现在&#xff0c;我们需要对任务进行更细致的管理&#xff0c;分解成多个层级&#xff0…

git clone必须使用sudo否则失败 git推送错误想再次编辑和推送

git clone必须使用sudo否则失败 我的问题比较特别用env | grep -i proxy发现没问题所幸直接删掉~/.ssh下的秘钥&#xff0c;重新弄 搭建SSH秘钥方法: &#xff08;一&#xff09;配置git 操作&#xff1a;linux镜像--桌面--右键--打开终端。 > git config --global user.n…

Docker搭建kafka环境

系统&#xff1a;MacOS Sonoma 14.1 Docker版本&#xff1a;Docker version 27.3.1, build ce12230 Docker desktop版本&#xff1a;Docker Desktop 4.36.0 (175267) 1.拉取镜像 先打开Docker Desktop&#xff0c;然后在终端执行命令 docker pull lensesio/fast-data-dev …

Java复习|图形用户界面AWT、Swing----银行客户管理系统【校课版】【1】

校课总结&#xff0c;部分&#xff0c;未完待续...... 背景了解 Java的AWT和Swing的现状 AWT&#xff08;Abstract Window Toolkit&#xff09; AWT是Java中最早期的图形用户界面&#xff08;GUI&#xff09;工具包&#xff0c;它直接与操作系统提供的图形函数进行交互&a…

cudnn版本gpu架构

nvcc --help 可以看 --gpu-architecture 写到的支持的架构 NVIDIA 的 GPU 架构是按代次发布的&#xff0c;以下是这些架构的对应说明&#xff1a; NVIDIA Hopper: 这是 NVIDIA 于 2022 年推出的架构之一&#xff0c;面向高性能计算&#xff08;HPC&#xff09;和人工智能&…

视频汇聚融合云平台Liveweb一站式解决视频资源管理痛点

随着5G技术的广泛应用&#xff0c;各领域都在通信技术加持下通过海量终端设备收集了大量视频、图像等物联网数据&#xff0c;并通过人工智能、大数据、视频监控等技术方式来让我们的世界更安全、更高效。然而&#xff0c;随着数字化建设和生产经营管理活动的长期开展&#xff0…

【Mysql】truncate 和 delete的区别

【Mysql】truncate 和 delete的区别 【一】删除内容【二】执行速度【三】事务日志记录【四】回滚【五】触发器【六】外键约束【七】锁定【八】使用场景【九】总结【1】truncate【2】drop【3】delete 【一】删除内容 &#xff08;1&#xff09;TRUNCATE TABLE&#xff1a;删除表…

为什么要用云电脑玩游戏?5大好处揭秘,ToDesk云机性能强又易用

电脑在人们日常的工作与生活中无疑是颇为重要的。无论是学生撰写论文报告、企业白领处理数据图形等事项&#xff0c;还是游戏迷、影视迷们畅玩游戏或观看视频都难免要经常用到。拥有一台性能配置优质并且内置软件全面的电脑&#xff0c;对各类群体来说都大有益处&#xff0c;尤…