MQ的作用及应用场景
类似问题：
项⽬什么场景下使⽤到了MQ, 为什么需要MQ
RabbitMQ 的作⽤？使⽤场景有哪些
RabbitMQ的主要应⽤场景
消息队列解耦应⽤程序的例⼦
消息队列的应⽤场景
为什么说消息队列可以削峰
回答：
作用：消息队列，用来接收消息并转发消息
应用场景：
1.异步解耦：对于一些非常耗时，但是又不需要立刻知道返回结果的业务处理，就可以利用MQ来进行优化。 比如：用户注册后发送注册短信或者邮箱
2.流量削峰：对于一段时间的流量突增， 为此投入大量的资源无疑是巨大的浪费，这时候就可以利用MQ进行对流量的控制，来根据自己的业务处理能力进行处理。
3.异步通信：很多时候应用不需要立即处理消息，这时候就可以先将消息放入MQ中，然后慢慢的处理消息。
4.消息分发：对于多个系统需要对同一个数据进行响应时，可以采用MQ，减少系统对数据库的轮询操作
5.延迟通知：对于需要在特定时间后进行消息通知的操作，可以使用MQ进行消息延迟处理
了解过那些MQ，以及他们之间的区别
类似问题:
了解过哪些MQ, 与其他同类产品的对⽐
kafka 和 RabbitMQ的对⽐
对⽐其他消息队列，不同mq分别⽤在什么场景
kafka和rocketmq⽐较
消息队列除了使⽤RabbitMQ,可以⽤RocketMQ吗?
回答：
1.kafaka（主要用于日志方面，只支持简单的MQ，吞吐十万级）
Kafka主要用于日志收集和传输，追求高吞吐量, 性能卓越, 单机吞吐达到⼗万级, 在日志领域⽐较成熟, 功能较为简单, 主要支持简单的 MQ 功能. 适合⼤数据处理, 日志聚合, 实时分析等场景
2.RabbitMQ（MQ功能完备，支持语言多，开源界面友好，社区活跃度高，文档更新频繁，吞吐万级）
采⽤Erlang语言开发, MQ 功能⽐较完备, 且⼏乎⽀持所有主流语⾔, 开源提供的界⾯也⾮常友好, 性能较 好, 吞吐量能达到万级, 社区活跃度较⾼，⽂档更新频繁, ⽐较适合中⼩型公司, 数据量没那⼤,且并发 没那么⾼的场景
3.RocketMQ（可靠性以及稳定性方面出色，吞吐十万级，但支持语言少，文档少，社区活跃度一般，适合大规模分布式系统）
采⽤Java语⾔开发, 由阿⾥巴巴开源, 后捐赠给了Apache. 在可⽤性, 可靠性以及稳定性等⽅⾯都⾮常出 ⾊, 吞吐量能达到⼗万级, 在Alibaba集团内部⼴泛使⽤, 但⽀持的客⼾端语⾔不多, 产品较新⽂档较少, 且社区活跃度⼀般. 适合于⼤规模分布式系统, 可靠性要求⾼, 且并发⼤的场景, ⽐如互联⽹⾦融. 这些消息队列, 各有侧重, 没有好坏, 只有适合不适合, 在实际选型时, 需要结合⾃⾝需求以及MQ产品特 征, 综合考虑
RabbitMQ的核心概念及工作流程
相关⾯试题:
RabbitMQ的核⼼流程简单介绍⼀下
讲下RabbitMQ的结构
核心概念：
Producer: 生产者，向RabbitMQ发送消息
Consumer: 消费者，从RabbitMQ接收消息
Broker: 消息队列服务器或服务器实例，也就是RabbitMQServer
Connection:网络连接，它允许客户端与RabbitMQ通信
Channel:连接里的一个虚拟通道，发送或者接收消息都是通过通道进行的
Exchange:交换机，负责接受生产者发送的消息，并根据路由算法和规则将消息路由到一个或多个队列
Queue:消息队列，存储消息直到他们被消费者消费
工作流程：
1.创建连接：Producer连接到RabbitMQBroker,建立一个连接(Connection),开启一个信道（Channel）
2.声明交换机和队列，以及绑定规则：Producer声明一个交换机（Exchange）和队列，并绑定Queue到Exchange
3.发布消息：Producer发送消息到RaabbitMQ Broker
4.消息存储：RabbittMQ Broker接收消息,并存入相应的队列（Queue）中，如果未找到对应的队列，则根据生产者的配置，选择丢弃或者退回给生产者。
5.消费消息：消费者监听Queue,当消息到达时，从Queue中获取消息，处理后，向RabbitMQ发送消息确认
6.消息删除：消息被确认后，RabbitMQ会把消息从Queue中删除
RabbitMQ如何保证消息的可靠性
相关⾯试题:
RabbitMQ消息丢失原因及其解决⽅案
如何保证消息不丢失
消息写⼊失败怎么办
消息消费失败如何处理
MQ的主动ack和被动ack有什么区别
RabbitMQ如何解决数据丢失问题, 如何保证⼀致性
消息队列怎么保证消费者的消息不丢失的？
1.Producer → Broker 发送方确认
Producer→Exchange confirm模式 网络问题，交换机不存在
Exchange→Queue returns模式 routing key 不匹配
队列可以设置长度 死信
2.Broker 持久化 交换机，队列，消息 仲裁队列
3.Broker →Consumer 消费者确认
自动确认：消息到达消费者之后，如果消费者逻辑有问题。消费失败，会导致消息丢失
手动确认
RabbitMQ如果保证消息顺序性
相关⾯试题:
RabbitMQ怎么保证消息的顺序性？
如何保证消息能够有序消费
消息的顺序性指的是消费者消费消息和生产者发送消息的顺序是一样的
可能打破MQ消息顺序性的常见场景：
1.多个消费者：当队列配置了多个消费者时，消息可能会被不同的消费者并行处理，从而导致消息处理的顺序性无法保证
2.网络波动或异常：在消息传递的过程中，如果出现网路波动或异常，可能会导致消息确认（ACK）丢失，从而使得消息被重新入队或者重新消费造成顺序性问题
3.消息重试：如果消费者在处理消息后未能及时发送确认，或者确认消息在传输过程中丢失，那么MQ可能会认为消息未被成功消费而进行重试，这也可能导致消息处理的顺序性问题
4.消息路由问题：在复杂的路由场景中，消息可能会根据油路键被发送到不同的队列，从而无法保证全局的顺序性
5.死信队列：消息因为某种原因（如消费端拒绝消息）被放入死信队列，死信队列被消费时，无法保证消息的顺序和生产者发送消息的顺序一致
顺序性的保证方案：
1.单队列单消费者
同一个队列时先进先出的，这是RabbitMQ来帮助我们保证的
2.分区消费
单个消费者的吞吐太低了，当需要多个消费者以提高处理速度的时候，可以使用分区消费，把一个队列分割成多个分区，每个分区由一个消费者处理，以此来保持每个分区内消息的顺序性
3.消息确认机制
使用手动消息确认机制，消费者在处理完一条消息后，显示的发送确认，这样RabbitMQ才会移除并继续发送下一条消息
4.业务逻辑控制
比如通过消息中嵌入序列号，并在消费时根据这些消息来处理
如何保证消息消费时的幂等性
全局唯一ID
1.为每条消息分配一个唯一标识符，比如UUID或者MQ中的唯一ID，但一定要保证唯一性
2.消费者收到消息后，先用该id判断该消息是否已经消费过，如果已经消费过，则放弃处理
3.如果未消费过，消费者开始消费消息，业务处理成功后，把唯一ID保存起来（数据库或Redis等）
业务逻辑判断
在业务逻辑层面实现消息处理的幂等性
例如：通过检查数据库中是否已经存在相关数据记录，或者使用乐观锁机制来避免更新已被其他事务更改的数据，再或者在处理消息之前，先检查相关业务的状态，确保消息对应的操作尚未执行，然后才进行处理，具体根据业务场景来处理
RabbitMQ有哪些特性
1.发送方消息确认 （Producer->Exchange confirm确认机制 Exchange->Quue return退回模式）
2.持久化 （交换性持久化、队列持久化，消息持久化）
3.消费端消息确认 （自动确认、收到确认）
4.重试机制 （在消息处理失败后重新发送，对于程序逻辑的错误，重试再多次也是没有用的，可以配置消息重试次数）
5.TTL （对消息或队列设置过期时间）
设置队列TTL属性的方法，一旦消息过期，就会从队列中删除
设置消息TTL的方法，即使消息过期，也不会马上从队列中删除，而是在即将投递到消费者之前进行判定的
6.死信队列（处理未被正常处理的消息）
7.延迟队列（让消息延迟到达消费者）
8.事务（消息要么全部处理成功，要么全部处理不成功）
9.消息分发（1.限流 2.非公平分发）
介绍一下RabbitMQ的死信队列
类似问题:
RabbitMQ的死信队列以及应⽤场景
1.死信队列的概念
因为种种原因，无法被正常消费的消息，在消息队列系统中，如RabbiotMQ,死信队列用于存储这些死信.消息
2.死信队列的来源
1）消息过期：消息在消费队列中存活的时间超过了设定的TTL
2）消息被拒绝：消费者在处理消息时，可能因为消息内容错误，处理逻辑等原因拒绝处理该消息，如果拒绝时指定不重新入队（requeue=false）,消息也会成为死信。
3）队列满了：当队列达到最大长度，无法再容纳新的消息时，新来的消息会被处理为死信
3.死信队列的应用场景
它可以处理异常情况下，消息不能被消费者正确消费而被置入死信队列中的情况，应用程序可以通过消费这个死信队列中的内容来分析当时所遇到的异常情况，进而改善和优化系统
比如：
支付系统会给订单系统返回当前订单的支付状态，为了保证支付信息不丢失，需要使用到死信队列机制，当消费消费异常时，将消息投入到死信队列，由订单系统的其他消费者来监听这个队列，并对数据进行处理（比如发送工单等，进行人工确认）
消息重试：将死信消息重新发送到原队列或另一个队列进行重试处理
消息丢弃：直接丢弃这些无法处理的消息，以避免他们占用系统资源
日志收集：将死信消息作为日志收集起来，用于后续分析和问题定位
介绍一下RabbitMQ的延迟队列
类似问题:
rabbitmq延迟队列的实现
1.概念
延迟队列，即消息被发送后，等待特定时间后消费者才能拿到这个消息进行消费
2.应用场景
比如：用户注册后，7天后发送短信，提高用户活跃度
日常管理：在会议开始前15分钟提醒参会人参加会议
智能家具：在指定时间进行工作
3.实现方式：
TTL＋死信队列：（如果第一条消息的过期时间比第二条长，则第二条就不会执行）
延迟队列插件
介绍一下RabbitMQ的工作模式
相关⾯试题:
RabbitMQ的⼏种模式, work模式怎么实现的能者多劳
1.Simple(简单模式)
2.Work Queue(工作队列)
3.Publish/Subscribe(发布/订阅)
4.Routing(路由模式)
5.Topics(通配符模式)
6.RPC（RPC通信）
7.Publisher Confirms(发布确认)
消息积压的原因，如何处理
类似问题:
MQ消息堆积问题
如果解决MQ的数据囤积？
消息积压的原因：
1.消息生产过快
2.消费者能力不足（一般一段时间的消息积压，是消息生产过快，一直积压是消费者能力不足）
3.网络问题
4.RabbitMQ服务配置偏低
解决方案：
1.提高消费者效率，比如增加机器，优化业务逻辑
2.限制消费者的生产速率
3.资源配置优化
RabbitMQ是推模式还是拉模式
概念
RabbitMQ支持两种消息传递模式：推模式（push）和拉模式（pull）
推模式：消息中间件主动将消息推给消费者
拉模式：消费者主动从消息中间件拉去消息
RabbitMQ主要是基于推模式工作的，它的核心设计是让消息队列中的消费者接受到生产者发送的消息，使channel.basicConsume方法订阅队列，RabbitMQ就会把消息推送到订阅该队列的消费者，如果只想从队列中获取单条消息而不是持续订阅，则可以使用channel.basicGet方法来进行消费消息。
总结
退模式：对消息的获取更加实时，适合对数据实时性要求比较高时，比如实时数据处理，如监控系统等。
拉模式：消费者可以按照自己的处理速度来消费，避免消息积压，适合需要流量控制，或者需要大量计算资源的任务，拉取模式允许消费者在准备好后再请求消息，避免资源浪费
