淘宝网站页面设计,创意广告设计网站,wordpress百家号插件,万博法务网站1. 什么是RabbitMQ
RabbitMQ是一个开源的消息队列系统#xff0c;它使用AMQP#xff08;高级消息队列协议#xff09;标准。RabbitMQ的主要目标是提供可靠的消息传递#xff0c;确保消息的可靠性和顺序性#xff0c;同时提供灵活的路由和消息确认机制。
RabbitMQ基于AMQ…1. 什么是RabbitMQ
RabbitMQ是一个开源的消息队列系统它使用AMQP高级消息队列协议标准。RabbitMQ的主要目标是提供可靠的消息传递确保消息的可靠性和顺序性同时提供灵活的路由和消息确认机制。
RabbitMQ基于AMQP协议工作它通过消息的发布/订阅模式实现消息的传递。主要包括三个角色生产者Producer、交换机Exchange和队列Queue。生产者负责生成消息交换机负责接收生产者的消息并根据指定的规则路由到队列而队列则负责存储这些消息等待消费者Consumer来消费。
2. RabbitMQ支持哪些协议
RabbitMQ支持AMQP协议也支持MQTT、STOMP等其他协议。
3. 解耦、异步、削峰是什么
解耦A 系统发送数据到 BCD 三个系统通过接口调用发送。如果 E 系统也要这个数据呢那如果 C 系统现在不需要了呢A 系统负责人几乎崩溃…A 系统跟其它各种乱七八糟的系统严重耦合 A 系统产生一条比较关键的数据很多系统都需要 A 系统将这个数据发送过来。如果使用 MQA系统产生一条数据发送到 MQ 里面去哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据直接从 MQ 里消费即可如果某个系统不需要这条数据了就取消对 MQ 消息的消费即可。这样下来A 系统压根儿不需要去考虑要给谁发送数据不需要维护这个代码也不需要考虑人家是否调用成功、失败超时等情况。
就是一个系统或者一个模块调用了多个系统或者模块互相之间的调用很复杂维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的如果用 MQ 给它异步化解耦。
异步A 系统接收一个请求需要在自己本地写库还需要在 BCD 三个系统写库自己本地写库要 3msBCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 300 450 200 953ms接近 1s用户感觉搞个什么东西慢死了慢死了。用户通过浏览器发起请求。如果使用 MQ那么 A 系统连续发送 3 条消息到 MQ 队列中假如耗时 5msA 系统从接受一个请求到返回响应给用户总时长是 3 5 8ms。
削峰减少高峰时期对服务器压力。
4. 消息队列有什么缺点
系统可用性降低
本来系统运行好好的现在你非要加入个消息队列进去那消息队列挂了你的系统不是呵呵了。因此系统可用性会降低
系统复杂度提高
加入了消息队列要多考虑很多方面的问题比如一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此需要考虑的东西更多复杂性增大。
一致性问题
A 系统处理完了直接返回成功了人都以为你这个请求就成功了但是问题是要是 BCD 三个系统那里BD 两个系统写库成功了结果 C 系统写库失败了咋整你这数据就不一致了。
所以消息队列实际是一种非常复杂的架构你引入它有很多好处但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉做好之后你会发现妈呀系统复杂度提升了一个数量级也许是复杂了 10 倍。但是关键时刻用还是得用的。
5. Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点
特性ActiveMQRabbitMQRocketMQKafka单机吞吐量万级比RocketMOKafka 低一个数量级同ActiveMQ10 万级支撑高吞吐10 万级高吞吐一般配合大数据类的系统来进行实时数据计算、日志采集等场景topic数量对吞吐量的影响————topic 可以达到几百/几千的级别吞叶量会有较小幅度的下降这是 RocketMO 的一大优势在同等机器下可以支撑大量的 topictopic 从几十到几百个时候吞吐量会大幅度下降在同等机器下Kafka 尽量保证 topic 数量不要过多如果要支撑大规模的 topic需要增加更多的机器资源时效性ms级微秒级这是RabbitMQ的一大特点延迟最低ms级延迟在 ms 级以内可用性高基于主从架构实现高可用同ActiveMQ非常高分布式架构非常高分布式一个数据多个副本少数机器宕机不会丢失数据不会导致不可用消息可靠性有较低的概率丢失数据基本不丢经过参数优化配置可以做到 0丢失同 RocketMQ功能支持MQ 领域的功能极其完备基于erlang开发并发能力很强性能极好延时很低MQ 功能较为完善还是分布式的扩展性好功能较为简单主要支持简单的 MO 功能在大数据领域的实时计算以及日志采集被大规模使用
综上各种对比之后有如下建议
一般的业务系统要引入 MQ最早大家都用 ActiveMQ但是现在确实大家用的不多了没经过大规模吞吐量场景的验证社区也不是很活跃所以大家还是算了吧我个人不推荐用这个了后来大家开始用RabbitMQ但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它对公司而言几乎处于不可控的状态但是确实人家是开源的比较稳定的支持活跃度也高不过现在确实越来越多的公司会去用 RocketMQ确实很不错毕竟是阿里出品但社区可能有突然黄掉的风险目前 RocketMQ 已捐给 Apache但 GitHub 上的活跃度其实不算高对自己公司技术实力有绝对自信的推荐用 RocketMQ否则回去老老实实用 RabbitMQ 吧人家有活跃的开源社区绝对不会黄。所以中小型公司技术实力较为一般技术挑战不是特别高用 RabbitMQ 是不错的选择大型公司基础架构研发实力较强用 RocketMQ 是很好的选择。如果是大数据领域的实时计算、日志采集等场景用 Kafka 是业内标准的绝对没问题社区活跃度很高绝对不会黄何况几乎是全世界这个领域的事实性规范。
6. MQ 有哪些常见问题如何解决这些问题
消息的顺序问题
消息有序指的是可以按照消息的发送顺序来消费。假如生产者产生了2 条消息M1、M2假定 M1 发送到 S1M2 发送到 S2如果要保证 M1 先于 M2 被消费怎么做 解决方案
保证生产者 - MQServer - 消费者是一对一对一的关系 缺陷
并行度就会成为消息系统的瓶颈吞吐量不够更多的异常处理比如只要消费端出现问题就会导致整个处理流程阻塞我们不得不花费更多的精力来解决阻塞的问题。通过合理的设计或者将问题分解来规避。不关注乱序的应用实际大量存在队列无序并不意味着消息无序 所以从业务层面来保证消息的顺序而不仅仅是依赖于消息系统是一种更合理的方式。
消息的重复问题
造成消息重复的根本原因是网络不可达。所以解决这个问题的办法就是绕过这个问题。那么问题就变成了如果消费端收到两条一样的消息应该怎样处理消费端处理消息的业务逻辑保持幂等性。只要保持幂等性不管来多少条重复消息最后处理的结果都一样。保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现。利用一张日志表来记录已经处理成功的消息的 ID如果新到的消息 ID 已经在日志表中那么就不再处理这条消息。
7. 什么是RabbitMQ
RabbitMQ是一款开源的Erlang编写的消息中间件 最大的特点就是消费并不需要确保提供方存在实现了服务之间的高度解耦可以用它来解耦、异步、削峰。
8. rabbitmq 的使用场景
1服务间异步通信
2顺序消费
3定时任务
4请求削峰
9. RabbitMQ基本概念
Broker简单来说就是消息队列服务器实体Exchange消息交换机它指定消息按什么规则路由到哪个队列Queue消息队列载体每个消息都会被投入到一个或多个队列Binding绑定它的作用就是把exchange和queue按照路由规则绑定起来Routing Key路由关键字exchange根据这个关键字进行消息投递VHostvhost 可以理解为虚拟 broker 即 mini-RabbitMQ server。其内部均含有独立的queue、exchange 和 binding 等但最最重要的是其拥有独立的权限系统可以做到 vhost 范围的用户控制。当然从 RabbitMQ 的全局角度vhost 可以作为不同权限隔离的手段一个典型的例子就是不同的应用可以跑在不同的 vhost 中。Producer消息生产者就是投递消息的程序Consumer消息消费者就是接受消息的程序Channel消息通道在客户端的每个连接里可建立多个channel每个channel代表一个会话任务
由Exchange、Queue、RoutingKey三个才能决定一个从Exchange到Queue的唯一的线路。
10. RabbitMQ的工作模式
simple模式即最简单的收发模式 消息产生消息将消息放入队列 消息的消费者(consumer) 监听 消息队列如果队列中有消息就消费掉消息被拿走后
自动从队列中删除(隐患消息可能没有被消费者正确处理已经从队列中消失了造成消息的丢失这里可以设置成手动的ack但如果设置成手动ack处理完后要及时发送ack消息给队列否则会造成内存溢出)。
work工作模式(资源的竞争) 消息产生者将消息放入队列消费者可以有多个消费者1消费者2同时监听同一个队列消息被消费。C1 C2共同争抢当前的消息队列内容谁先拿到谁负责消费消息(隐患高并发情况下默认会产生某一个消息被多个消费者共同使用可以设置一个开关(syncronize) 保证一条消息只能被一个消费者使用)。
**publish/subscribe发布订阅(共享资源) ** 每个消费者监听自己的队列 生产者将消息发给broker由交换机将消息转发到绑定此交换机的每个队列每个绑定交换机的队列都将接收到消息。
routing路由模式 消息生产者将消息发送给交换机按照路由判断路由是字符串(info) 当前产生的消息携带路由字符(对象的方法)交换机根据路由的key只能匹配上路由key对应的消息队列对应的消费者才能消费消息 根据业务功能定义路由字符串 从系统的代码逻辑中获取对应的功能字符串将消息任务扔到对应的队列中。 业务场景:error 通知EXCEPTION错误通知的功能传统意义的错误通知客户通知利用key路由可以将程序中的错误封装成消息传入到消息队列中开发者可以自定义消费者实时接收错误
topic 主题模式(路由模式的一种) 星号井号代表通配符 星号代表多个单词井号代表一个单词 路由功能添加模糊匹配 消息产生者产生消息把消息交给交换机 交换机根据key的规则模糊匹配到对应的队列由队列的监听消费者接收消息消费
看来就是routing查询的一种模糊匹配就类似sql的模糊查询方式
11. 如何保证RabbitMQ消息的顺序性
拆分多个 queue(消息队列)每个 queue(消息队列) 一个 consumer(消费者)就是多一些 queue(消息队列)而已确实是麻烦点或者就一个 queue (消息队列)但是对应一个 consumer(消费者)然后这个 consumer(消费者)内部用内存队列做排队然后分发给底层不同的 worker 来处理。
12. 消息如何分发
若该队列至少有一个消费者订阅消息将以循环round-robin的方式发送给消费者。每条消息只会分发给一个订阅的消费者前提是消费者能够正常处理消息并进行确认。通过路由可实现多消费的功能。
13. 消息怎么路由
消息提供方-路由-一至多个队列消息发布到交换器时消息将拥有一个路由键routing key在消息创建时设定。通过队列路由键可以把队列绑定到交换器上。消息到达交换器后 RabbitMQ 会将消息的路由键与队列的路由键进行匹配针对不同的交换器有不同的路由规则
常用的交换器主要分为一下三种 fanout如果交换器收到消息将会广播到所有绑定的队列上 direct如果路由键完全匹配消息就被投递到相应的队列 topic可以使来自不同源头的消息能够到达同一个队列。 使用 topic 交换器时可以使用通配符
14. 消息基于什么传输
由于 TCP 连接的创建和销毁开销较大且并发数受系统资源限制会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的 TCP 连接内的虚拟连接且每条 TCP 连接上的信道数量没有限制。
15. 如何保证消息不被重复消费或者说如何保证消息消费时的幂等性
先说为什么会重复消费正常情况下消费者在消费消息的时候消费完毕后会发送一个确认消息给消息队列消息队列就知道该消息被消费了就会将该消息从消息队列中删除但是因为网络传输等等故障确认信息没有传送到消息队列导致消息队列不知道自己已经消费过该消息了再次将消息分发给其他的消费者。针对以上问题一个解决思路是保证消息的唯一性就算是多次传输不要让消息的多次消费带来影响保证消息等幂性
比如在写入消息队列的数据做唯一标示消费消息时根据唯一标识判断是否消费过假设你有个系统消费一条消息就往数据库里插入一条数据要是你一个消息重复两次你不就插入了两条这数据不就错了但是你要是消费到第二次的时候自己判断一下是否已经消费过了若是就直接扔了这样不就保留了一条数据从而保证了数据的正确性
16. 如何确保消息正确地发送至 RabbitMQ 如何确保消息接收方消费了消息
发送方确认模式
将信道设置成 confirm 模式发送方确认模式则所有在信道上发布的消息都会被指派一个唯一的 ID。一旦消息被投递到目的队列后或者消息被写入磁盘后可持久化的消息信道会发送一个确认给生产者包含消息唯一 ID。如果 RabbitMQ 发生内部错误从而导致消息丢失会发送一条 nacknotacknowledged未确认消息。发送方确认模式是异步的生产者应用程序在等待确认的同时可以继续发送消息。当确认消息到达生产者应用程序生产者应用程序的回调方法就会被触发来处理确认消息。
接收方确认机制
消费者接收每一条消息后都必须进行确认消息接收和消息确认是两个不同操作。只有消费者确认了消息RabbitMQ 才能安全地把消息从队列中删除。这里并没有用到超时机制RabbitMQ 仅通过 Consumer 的连接中断来确认是否需要重新发送消息。也就是说只要连接不中断RabbitMQ 给了 Consumer 足够长的时间来处理消息。保证数据的最终一致性
下面罗列几种特殊情况
如果消费者接收到消息在确认之前断开了连接或取消订阅RabbitMQ 会认为消息没有被分发然后重新分发给下一个订阅的消费者。可能存在消息重复消费的隐患需要去重。如果消费者接收到消息却没有确认消息连接也未断开则 RabbitMQ 认为该消费者繁忙将不会给该消费者分发更多的消息。
17. 如何保证RabbitMQ消息的可靠传输
消息不可靠的情况可能是消息丢失劫持等原因
丢失又分为生产者丢失消息、消息列表丢失消息、消费者丢失消息 生产者丢失消息 从生产者弄丢数据这个角度来看RabbitMQ提供transaction和confirm模式来确保生产者不丢消息transaction机制就是说发送消息前开启事务channel.txSelect()然后发送消息如果发送过程中出现什么异常事务就会回滚channel.txRollback()如果发送成功则提交事务channel.txCommit()。然而这种方式有个缺点吞吐量下降 confirm模式用的居多一旦channel进入confirm模式所有在该信道上发布的消息都将会被指派一个唯一的ID从1开始一旦消息被投递到所有匹配的队列之后rabbitMQ就会发送一个ACK给生产者包含消息的唯一ID这就使得生产者知道消息已经正确到达目的队列了 如果rabbitMQ没能处理该消息则会发送一个Nack消息给你你可以进行重试操作。 消息队列丢数据消息持久化。 处理消息队列丢数据的情况一般是开启持久化磁盘的配置。 这个持久化配置可以和confirm机制配合使用你可以在消息持久化磁盘后再给生产者发送一个Ack信号。 这样如果消息持久化磁盘之前rabbitMQ阵亡了那么生产者收不到Ack信号生产者会自动重发。 那么如何持久化呢这里顺便说一下吧其实也很容易就下面两步 将queue的持久化标识durable设置为true则代表是一个持久的队列 发送消息的时候将deliveryMode2这样设置以后即使rabbitMQ挂了重启后也能恢复数据 消费者丢失消息 消费者丢数据一般是因为采用了自动确认消息模式改为手动确认消息即可 消费者在收到消息之后处理消息之前会自动回复RabbitMQ已收到消息如果这时处理消息失败就会丢失该消息 解决方案处理消息成功后手动回复确认消息。
18. 为什么不应该对所有的 message 都使用持久化机制
首先必然导致性能的下降因为写磁盘比写 RAM 慢的多message 的吞吐量可能有 10 倍的差距。其次message 的持久化机制用在 RabbitMQ 的内置 cluster 方案时会出现“坑爹”问题。矛盾点在于若 message 设置了 persistent 属性但 queue 未设置 durable 属性那么当该 queue 的owner node 出现异常后在未重建该 queue 前发往该 queue 的 message 将被 blackholed 若 message 设置了 persistent 属性同时 queue 也设置了 durable 属性那么当 queue 的owner node 异常且无法重启的情况下则该 queue 无法在其他 node 上重建只能等待其owner node 重启后才能恢复该 queue 的使用而在这段时间内发送给该 queue 的 message将被 blackholed 。所以是否要对 message 进行持久化需要综合考虑性能需要以及可能遇到的问题。若想达到100,000 条/秒以上的消息吞吐量单 RabbitMQ 服务器则要么使用其他的方式来确保message 的可靠 delivery 要么使用非常快速的存储系统以支持全持久化例如使用 SSD。另外一种处理原则是仅对关键消息作持久化处理根据业务重要程度且应该保证关键消息的量不会导致性能瓶颈。
19. RabbitMQ 的集群如何保证高可用的 单机模式就是 Demo 级别的一般就是你本地启动了玩玩儿的没人生产用单机模式。 普通集群模式 意思就是在多台机器上启动多个 RabbitMQ 实例每个机器启动一个。 你创建的 queue只会放在一个 RabbitMQ 实例上但是每个实例都同步 queue 的元数据元数据可以认为是 queue 的一些配置信息通过元数据可以找到 queue 所在实例。你消费的时候实际上如果连接到了另外一个实例那么那个实例会从 queue 所在实例上拉取数据过来。这方案主要是提高吞吐量的就是说让集群中多个节点来服务某个 queue 的读写操作。 镜像集群模式 这种模式才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是在镜像集群模式下你创建的 queue无论元数据还是 queue 里的消息都会存在于多个实例上就是说每个 RabbitMQ 节点都有这个 queue 的一个完整镜像包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候都会自动把消息同步到多个实例的 queue 上。RabbitMQ 有很好的管理控制台就是在后台新增一个策略这个策略是镜像集群模式的策略指定的时候是可以要求数据同步到所有节点的也可以要求同步到指定数量的节点再次创建 queue 的时候应用这个策略就会自动将数据同步到其他的节点上去了。 这样的好处在于你任何一个机器宕机了没事儿其它机器节点还包含了这个 queue的完整数据别的 consumer 都可以到其它节点上去消费数据。坏处在于第一这个性能开销也太大了吧消息需要同步到所有机器上导致网络带宽压力和消耗很重RabbitMQ一个 queue 的数据都是放在一个节点里的镜像集群下也是每个节点都放这个 queue 的完整数据。
20. 如何处理消息的顺序问题
RabbitMQ通过单一的生产者和单一的消费者可以保证消息的顺序。如果需要多个消费者处理消息则可以通过设置公平分发策略或使用“autorecknowledge”模式来保证消息的处理顺序。
21. 如何处理高并发场景下的性能问题
RabbitMQ通过提供集群功能来处理高并发场景下的性能问题。通过将多个节点组成一个集群可以实现负载均衡和分发提高系统的整体处理能力。同时还可以通过调整各种参数来优化性能如调整消息的持久化设置、调整交换机和队列的匹配规则等。
22. 如何实现消息的优先级处理
RabbitMQ支持消息的优先级处理。可以通过设置消息的优先级字段来实现优先级高的消息会优先被消费者消费。此外还可以通过使用优先级队列来实现更细粒度的优先级控制。
23. 如何在RabbitMQ中实现延迟队列
RabbitMQ通过插件支持延迟队列的实现。延迟队列是指将消息放入队列中等待一段时间后再进行处理。要实现延迟队列可以使用RabbitMQ的插件“rabbitmq_delayed_message_exchange”它提供了一个延迟交换器Delayed Message Exchange可以将消息路由到指定的队列中等待指定的延迟时间。
24. 如何在RabbitMQ中实现优先级队列
RabbitMQ通过插件支持优先级队列的实现。优先级队列是指根据消息的优先级进行排序和处理的队列。要实现优先级队列可以使用RabbitMQ的插件“rabbitmq_priority_queue”它提供了一个优先级队列交换机Priority Queue Exchange可以将具有不同优先级的消息路由到不同的队列中。
25. 如何在RabbitMQ中实现死信队列
RabbitMQ通过插件支持死信队列的实现。死信队列是指当消息无法被成功消费或处理时将其放入指定的死信队列中。要实现死信队列可以使用RabbitMQ的插件“rabbitmq_dead_letter_exchange”它提供了一个死信交换机Dead Letter Exchange可以将无法被处理的消息路由到指定的死信队列中。 itMQ通过插件支持优先级队列的实现。优先级队列是指根据消息的优先级进行排序和处理的队列。要实现优先级队列可以使用RabbitMQ的插件“rabbitmq_priority_queue”它提供了一个优先级队列交换机Priority Queue Exchange可以将具有不同优先级的消息路由到不同的队列中。
25. 如何在RabbitMQ中实现死信队列
RabbitMQ通过插件支持死信队列的实现。死信队列是指当消息无法被成功消费或处理时将其放入指定的死信队列中。要实现死信队列可以使用RabbitMQ的插件“rabbitmq_dead_letter_exchange”它提供了一个死信交换机Dead Letter Exchange可以将无法被处理的消息路由到指定的死信队列中。
