RabbitMQ｜RabbitMQ的总结

最新推荐文章于 2022-12-15 09:27:00 发布
最新推荐文章于 2022-12-15 09:27:00 发布
阅读量861 收藏 2
点赞数 2
文章标签： 队列 分布式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/MarkusZhang/article/details/108298118
版权

文章目录

RabbitMQ

RabbitMQ概念

RabbitMQ简介:

RabbitMQ是一个由erlang开发的AMQP(Advanved Message Queue Protocol)的开源实现。

核心概念

Message

消息，消息是不具名的，它由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组
成，这些属性包括routing-key, (路由键)、priority (相对于其他消息的优先权)、delivery-mode (指
出该消息可能需要持久性存储)’等。

Publisher

消息的生产者，也是一个向交换器发布消息的客户端应用程序。

Exchange

交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。
Exchange有4种类型: direct(默认), fanout, topic,和headers,不同类型的Exchange转发消息的策略有所区别
fanout交换机：它是将消息发送给所有绑定该交换机的队列中去，不会考虑RoutingKey的内容
direct：它会把消息路由到与RoutingKey完全匹配的队列中去
topic：它与direct类似，不过它采用的是模糊匹配的方式来将消息发送到对应的队列中去
headers：它不是根据路由键来匹配，而是通过消息中headers属性来匹配的。性能很差，不建议使用

Queue

消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息
可投入一个或多个队列。消息-直在队列里面，等待消费者连接到
这个队列将其取走。

Binding

绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连
接起来的路由规则，所以可以将交换器理解成-个由绑定构成的路由表。
Exchange和Queue的绑定可以是多对多的关系。

Connection

网络连接，比如一个TCP连接。

Channel

信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内的虚、
拟连接，AMQP命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这
些动作都是通过信道完成。因为对于操作系统来说建立和销毁TCP都是非常昂贵的开销，所
以引入了信道的概念，以复用一条TCP连接。

Consumer

消息的消费者,表示一个从消息队列中取得消息的客户端应用程序。

Virtual Host

虚拟主机，表示-一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加
密环境的独立服务器域。每个vhost本质上就是一个mini版的RabbitMQ服务器，拥有
自己的队列、交换器、绑定和权限机制。vhost 是AMQP概念的基础，必须在连接时指定,
RabbitMQ默认的vhost是/。

Broker

表示消息队列服务器实体

一张图解决RabbitMQ几个概念

面试连环炮

1、你在项目里是怎么使用消息队列的

我的使用场景

我这里有个场景就是，使用RabbitMQ来解决分布式事务的问题，在提交订单的时候，会涉及到锁库存的情况，这是两个系统的之间的操作，在分布式情况下，如果涉及到一个系统的执行失败，就比如我这个订单系统提交订单这块，涉及到创建订单，锁库存的功能需要两个微服务共同完成，假如我在订单系统中出现了问题，导致订单事务回滚，这样锁库存服务的事务是不会回滚的。这样就导致了在分布式下事务不一致的情况。为了完成这块的功能，我引入了RabbitMQ，将创建完订单之后，调用远程的锁库存服务，然后将订单信息写到消息队列中去，库存服务监听这个消息。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UQ7jaUVc-1598698199249)(./image/13.png)]

在创建订单的时候大致就是做这些事情：

  • 订单服务创建一笔订单–>远程调用库存服务锁库存–>将创建成功的订单消息写入到队列当中去–>(这里入的队列是延时队列，针对订单30分钟内还没完成支付的，需要进行关闭订单操作和解锁库存操作)–>1、在解锁库存方面，这里我业务做成幂等的了，只会将锁库存表里未被解锁状态的库存进行解锁 2、关闭订单方面

2、为什么使用消息队列

使用场景：

消息队列应用的场景有很多，最核心的有三种：解耦、异步、削峰

解耦：

我们现在先来画个图来描述一下在不使用消息队列的时候的系统调用情况

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8sDukExV-1598698199251)(./image/1.png)]

使用消息队列之后的解耦场景

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cHqaN1pz-1598698199254)(./image/2.png)]

异步：

不用MQ的同步高延时请求场景：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DfwfhNzV-1598698199257)(./image/3.png)]

使用MQ后进行异步之后的接口性能优化场景：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gg6gAdvY-1598698199258)(./image/4.png)]

削峰：

没有用MQ的时候高峰期系统被打死的场景：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1eKXI80C-1598698199259)(./image/5.png)]

使用MQ来进行削峰：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ynBF8kJV-1598698199260)(./image/6.png)]

3、消息队列都有什么优点和缺点

优点

优点就是可以达到：解耦、异步、削峰的作用！

缺点

引入MQ后可能存在的一些问题：

  • 系统可用性降低
  • 系统的复杂性会提高
  • 一致性问题

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4EzPSH0b-1598698199261)(./image/7.png)]

4、kafka、activemq、rabbitmq、rocketmq都有什么区别？

​

特性ActiveMQRabbitMQRocketMQKafka
单机吞吐量万级，吞吐量比RocketMQ和Kafka要低了一个数量级万级，吞吐量比RocketMQ和Kafka要低了一个数量级10万级，RocketMQ也是可以支撑高吞吐的一种MQ10万级别，这是kafka最大的优点，就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic数量对吞吐量的影响topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降 这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topictopic从几十个到几百个的时候，吞吐量会大幅度下降 所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源
时效性ms级微秒级，这是rabbitmq的一大特点，延迟是最低的ms级延迟在ms级以内
可用性高，基于主从架构实现高可用性高，基于主从架构实现高可用性非常高，分布式架构非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性有较低的概率丢失数据经过参数优化配置，可以做到0丢失经过参数优化配置，消息可以做到0丢失
功能支持MQ领域的功能极其完备基于erlang开发，所以并发能力很强，性能极其好，延时很低MQ功能较为完善，还是分布式的，扩展性好功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准
优劣势总结非常成熟，功能强大，在业内大量的公司以及项目中都有应用 偶尔会有较低概率丢失消息 而且现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本 而且确实主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用erlang语言开发，性能极其好，延时很低； 吞吐量到万级，MQ功能比较完备 而且开源提供的管理界面非常棒，用起来很好用 社区相对比较活跃，几乎每个月都发布几个版本分 在国内一些互联网公司近几年用rabbitmq也比较多一些 但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。 而且erlang开发，国内有几个公司有实力做erlang源码级别的研究和定制？如果说你没这个实力的话，确实偶尔会有一些问题，你很难去看懂源码，你公司对这个东西的掌控很弱，基本职能依赖于开源社区的快速维护和修复bug。 而且rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障 日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景 而且一个很大的优势在于，阿里出品都是java系的，我们可以自己阅读源码，定制自己公司的MQ，可以掌控 社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码 还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ挺好的kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展 同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量 而且kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略 这个特性天然适合大数据实时计算以及日志收集

上面的这些优缺点，都是我们在做技术选型时候的考虑点。

因为ActiveMQ、RocketMQ是基于JMS(java message server)协议的，而RabbitMQ是基于AMQP协议的，它是网络协议的一种，相比JMS，它能跨语言兼容，只需要将对象序列化就可以进行各语言之间的传输。并且ActiveMQ社区活跃度非常的低，现在基本上没有公司再用了，RabbitMQ社区非常活跃，版本更新很快，而RocketMQ是阿里的品牌，也有保证，Kafka几乎是业内处理大数据的中间件标杆，它的吞吐量非常大。选择RabbitMQ就是因为它的社区比较活跃，在吞吐量上RabbitMQ并不及RocketMQ和Kafka，但是RabbitMQ是很多公司的技术选型的一种方案，相对大公司来讲，选择RocketMQ比较好，在处理大数据领域问题以及日志采集那选kafka是无疑的

5、如何保证消息队列的高可用

RabbitMQ的普通集群模式原理分析

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pei0VRle-1598698199263)(./image/8.png)]

RabbitMQ的镜像集群模式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qzpX6Z3k-1598698199264)(./image/9.png)]

如何开启镜像集群模式呢？

其实很简单rabbitmq有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。

Kafka高可用架构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9PYrYg7X-1598698199265)(./image/10.png)]

6、如何保证消息不被重复消费啊？(如何保证消费的时候是幂等的啊？)

不被重复消费

不被重复消费，有以下解决方案：

  • 将接口设计成幂等的，比如我项目中的库存表就添了一个解锁状态来标识该库存是否被解锁过
  • 使用防重表，发送的每一个消息都有业务的唯一标识，处理过就不用处理
  • RabbitMQ本身有一个redelivered字段，它可以获取是否被重新投递过来的，而不是第一次投递过来的
如何保证幂等性

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T56lAekT-1598698199266)(./image/12.png)]

7、如何保证消息的可靠性传输啊？要是消息丢失了怎么办啊？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-auBlPdG4-1598698199267)(./image/14.png)]

1、生产者到RabbitMQ这块的消息丢失可走：事务、confirm保证消息不丢，事务吞吐量会降低，confirm采用异步的，一般采用这个

2、RabbitMQ持久化到磁盘：设置持久化，在创建queue的时候就将它设置成持久化的，这样就可以保证RabbitMQ持久化queue的元数据，但不会持久化queue里面的数据，需要发送消息的时候将消息的deliveryMode设置为2，就是将消息持久化的。

3、消费者搞丢：可能消费者是autoAck的机制，一定要开启手动ack，消费成功才移除，出异常就重新回到队列当中等待被消费

8、那如何保证消息的顺序性？

可能会出现数据顺序不对的场景

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6tgipSgN-1598698199267)(./image/15.png)]

RabbitMQ如何完全保证消息的顺序性

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VlX2KtNk-1598698199268)(./image/16.png)]

如果有很多的消费者，就创建多个队列，将需要保证顺序的消息全部给路由到一个队列中去，那么它在被消费者消费的时候就一定是顺序执行的了。

9、大量消息积压几个小时！

快速处理积压消息

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JTZ2ybKg-1598698199269)(./image/17.png)]

消息延时，设置过期时间

​ 假设你用的是rabbitmq，rabbitmq是可以设置过期时间的，就是TTL，如果消息在queue中积压超过一定的时间就会被rabbitmq给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在mq里，而是大量的数据会直接搞丢。

​ 这个情况下，就不是说要增加consumer消费积压的消息，因为实际上没啥积压，而是丢了大量的消息。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。

​ 这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入mq里面去，把白天丢的数据给他补回来。也只能是这样了。

​ 假设1万个订单积压在mq里面，没有处理，其中1000个订单都丢了，你只能手动写程序把那1000个订单给查出来，手动发到mq里去再补一次

MQ都快积压满了

如果走的方式是消息积压在mq里，那么如果你很长时间都没处理掉，此时导致mq都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。

10、如果让你写一个消息队列，该如何进行架构设计啊？说一下你的思路

（1）首先这个mq得支持可伸缩性吧，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计个分布式的系统呗，参照一下kafka的设计理念，broker -> topic -> partition，每个partition放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给topic增加partition，然后做数据迁移，增加机器，不就可以存放更多数据，提供更高的吞吐量了？

（2）其次你得考虑一下这个mq的数据要不要落地磁盘吧？那肯定要了，落磁盘，才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是kafka的思路。

（3）其次你考虑一下你的mq的可用性啊？这个事儿，具体参考我们之前可用性那个环节讲解的kafka的高可用保障机制。多副本 -> leader & follower -> broker挂了重新选举leader即可对外服务。

（4）能不能支持数据0丢失啊？可以的，参考我们之前说的那个kafka数据零丢失方案

其实一个mq肯定是很复杂的，面试官问你这个问题，其实是个开放题，他就是看看你有没有从架构角度整体构思和设计的思维以及能力。确实这个问题可以刷掉一大批人，因为大部分人平时不思考这些东西。

MarkusZhang
关注
专栏目录
【RabbitMQ | RabbitMQ操作】删除所有的队列以及消息
彭先森的博客
06-27 3741
注：【本文为个人学习中所记录，可能包含从网上摘抄的内容，侵删！如有错误望指正，一起交流、共同进步，感谢！】 前言 本机环境： VMware Fusion Pro 12.1.2 ​CentOS 6.5 RabbitMQ 3.4.1 方法一、命令行删除 在安装 RabbitMQ的服务器上，执行以下操作 关闭应用# 可以先执行 rabbitmqctl list_queues，查看现在的队列信息 rabbitmqctl stop_app 清除rabbitmqctl reset 启动应用rabbi.
RabbitMQ｜异步
Bert-Sun的博客
05-09 1932
我们日常生活中肯定遇到“分身乏术”的情况，在出现这种情况时我们肯定只能按部就班一件一件事情来处理，这样就会浪费一些不必要的时间，如在书写作业的时候我们只有在写完一门课作业后才能取完成另外一门的作业。但在计算机中这个问题在一定程度上被很好的解决，这就是使用来**异步**的思想，本文就来论述这个问题。
RabbitMQ （五）主题（Topic）
weixin_30664615的博客
07-11 491
转载请标明出处：http://blog.csdn.net/lmj623565791/article/details/37706355 上一篇博客中，我们进步改良了我们的日志系统。我们使用direct类型转发器，使得接收者有能力进行选择性的接收日志,，而非fanout那样，只能够无脑的转发，如果你还不了解：RabbitMQ （四） 路由选择 (Routing)。 虽然使用direct...
rabbitMQ（消息堆积问题）
qq_46624276的博客
09-03 1933
当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。最早接收到的消息，可能就会成为死信，会被丢弃，这就是消息堆积问题。
谷粒商城：订单锁库存保证事务最终一致性
qq_44600705的博客
02-28 3184
RabbitMQ延时队列（实现定时任务） 场景：比如未付款订单，超过一定时间后，系统自动取消订单并释放占有物品 常用解决方案：spring的schedule定时任务轮询数据库 缺点：消耗系统内存，增加数据库压力，存在较大的时间误差 解决：RabbitMQ的消息TTL的死信Exchange结合 消息的TTL就是消息的存活时间 RabbitMQ可以对队列和消息分别设置TTL：推荐给队列设置过期时间 对队列设置就是队列没有消费者连着的保留时间，也可以对每个单独的消息做单独的设置，超过了这个时间，我们认为这个.
RabbitMQ 队列消息的条数限制、队列字节长度限制、队列溢出行为方式
热门推荐
From Zero To Hero
06-20 3万+
目录 队列长度限制 默认最大队列长度限制行为 队列溢出行为 使用配置定义最大队列长度 在声明队列期间使用 x-arguments 定义最大队列长度（重点阅读即可） 队列长度限制 概述 队列的最大长度可以限制为一组消息数或一组字节数(忽略消息属性和其他开销的所有消息体长度总和)，或者两者兼有。 对于任何给定的队列，最大长度(任一类型)可以由客户端使用队列的参数来定义，也可以在服务器...
转：Kafka、RabbitMQ、RocketMQ等消息中间件的介绍和对比
PacosonSWJTU的博客
10-13 785
转自：https://blog.csdn.net/yunfeng482/article/details/72856762 前言 在分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,前段时间产品 RocketMQ (MetaQ的内核) 也顺利开源,得到大家的关注。 概念 MQ简介 MQ,Message queue,消息队列，就是指保存消息的一个容器。具体的定义这里就不类似于数据库、缓存等，用来保存数据的。当然，与数据库、缓存等产品比较，也...
RabbitMQ Server3.13.0
最新发布
04-02
**RabbitMQ Server 3.13.0** RabbitMQ 是一个开源的消息代理和队列服务器，它基于AMQP（Advanced Message Queuing Protocol）协议，用于在分布式系统中高效地路由和传递消息。RabbitMQ 3.13.0 版本是其稳定版本之一...
RabbitMQ使用总结
03-13
### RabbitMQ 使用总结 #### 一、安装与配置 **1. 安装顺序** - **ERLANG安装**: 首先确保安装了Erlang环境。安装时注意选择带有`windowdll`选项的版本，这有助于后续RabbitMQ的稳定运行。 - **RabbitMQ安装**: ...
rabbitmq-server3.10.5
01-10
RabbitMQ服务器3.10.5是一款广泛使用的开源消息代理和队列服务器，它基于高级消息队列协议（AMQP）实现。这个版本的RabbitMQ提供了稳定且高效的中间件服务，允许分布式系统中的应用程序进行异步通信，确保数据可靠...
RabbitMQ——最大连接数
hncscwc的博客
08-30 1万+
默认情况下，rabbitmq文件句柄数设置是1024。连接数最多为829，连接数的具体计算方式为： 连接数=（文件句柄数-100）*0.9，计算后的值取整再减2。 例如：（1024-100）*0.9=831.6，取整831再减2得到829。 真正使用时，1024可能无法满足实际需求。这个时候，一般通过ulimit来调整程序的最大文件句柄数。下图为通过ulimit将文件句柄数调整到1024...
RabbitMQ详解
prefect_start的博客
05-11 4188
rabbitmq详解
rabbitmq生成消费+获取某一队列中消息数量
qq_43062134的博客
07-16 4962
rabbitmq生成消费+获取某一队列中消息数量 package com.zkjz.eyes.rabbitmq; import com.rabbitmq.client.Channel; import com.rabbitmq.client.Connection; import com.rabbitmq.client.ConnectionFactory; import com.rabbitmq.c...
RabbitMQ
HDUCheater的博客
08-17 1766
官方教程：https://www.rabbitmq.com/tutorials/tutorial-one-java.html RabbitMQ是主流的消息队列之一，消息队列是用来传递消息的，生产消息的为生产者producer，消费消息的为消费者consumer。 RabbitMQ使用的是AMQP Advanced Message Queuing Protocol 高级消息队列协议。 一. HelloWorld 导入maven依赖 这里不导入slf4j-nop这个包的话，就会报错 <dependenc
RabbitMQ之Topic
lamwolf的博客
12-15 848
发送到类型是topic交换机的消息的routing_key不能随意写，必须满足一定的要求，它必须是一个单词列表，以点号分隔开。这些单词可以是任意单词，比如说：“stock.usd.nyse”,“nyse,vmw”,"quick.orange.rabbit"这种类型的。Q1–>绑定的是 中间带 orange 带 3 个单词的字符串(第一个单词是 lazy 的多个单词(lazy.#)最后一个单词是 rabbit 的 3 个单词(#(井号)可以替代零个或多个单词。(星号)可以代替一个单词。
(8)RabbitMQ之topic（主题）交换机
没头脑遇到不高兴
03-19 3110
本节将会介绍RabbitMQ中的topic（主题）交换机，通过在上一篇博客的基础上，利用topic形式的exchange对程序进行改进，将会变得更加灵活。 Topic exchange（主题交换机） 发送到topic交换机的消息不能具有任意的 routing_key —— 它必须是由点分隔的单词列表。单词可以是任何内容，但通常它们指定与消息相关的一些功能。一些有效的路由键示例：“ stock...
RabbitMQ的一些总结以及疑问
weixin_41805792的博客
10-27 241
View.inflate() 源码其实已经实现了LayoutInflater.from(getApplicationContext()).inflate()… //注意：一般后面是false LayoutInflater.from(this).inflate(R.layout.transtion_animator_clip, contain, false); //后面是三个参数，null View...
消息队列重要机制讲解以及MQ设计思路（kafka、rabbitmq、rocketmq）
hanhan的博客
11-23 2483
1、消息队列如何保证消息可靠传输 消息可靠传输代表两层意思：不多也不少 1、为了保证消息不多，也就是消息不能重复，也就是生产者不能重复生产消息，或者消费者不能重复消费消息 要确保消息不多发，这个不容易出现，难以控制 要避免不重复消费，最保险机制就是消费者实现幂等性，保证就算是重复消费，也不会出现问题 2、 ...
4.RabbitMQ高级特性
weixin_44519169的博客
08-26 208
RabbitMQ高级特性
systemctl -a |grep -E "UNIT|chronyd|memcached|rabbitmq|mariadb|glance|httpd|nova"
05-27
这是一个命令，它的作用是列出所有系统服务的状态，然后使用 grep 工具过滤出与指定关键字匹配的行。具体地说，它会列出与 UNIT、chronyd、memcached、rabbitmq、mariadb、glance、httpd 或 nova 相关的系统服务的状态。这个命令通常用于检查特定服务的状态或调试系统问题。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值