消息队列MQ口试题解，底子口试题
一、为什么使用MQ？MQ的长处简答
[*]异步处置处罚 - 相比于传统的串行、并行方式，进步了体系吞吐量。
[*]应用解耦 - 体系间通过消息通讯，不消关心其他体系的处置处罚。
[*]流量削锋 - 可以通过消息队列长度控制哀求量；可以缓解短时间内的高并发哀求。
[*]日志处置处罚 - 办理大量日志传输。
[*]消息通讯 - 消息队列一样平常都内置了高效的通讯机制，因此也可以用在纯的消息通讯。比如实现点对
[*]点消息队列，大概谈天室等。
详答
告急是：解耦、异步、削峰。
解耦：
A 体系发送数据到 BCD 三个体系，通过接口调用发送。假如 E 体系也要这个数据呢？那假如 C体系现在不须要了呢？A 体系负责人险些瓦解…A 体系跟别的各种七零八落的体系严厉耦合，A 体系产生一条比力关键的数据，很多体系都须要 A 体系将这个数据发送过来。假如使用 MQ，A 体系产生一条数据，发送到 MQ 内里去，哪个体系须要数据本身去 MQ 内里消耗。假如新体系须要数据，直接从MQ 里消耗即可；假如某个体系不须要这条数据了，就取消对 MQ 消息的消耗即可。如许下来，A 体系压根儿不须要去思量要给谁发送数据，不须要维护这个代码，也不须要思量人家是否调用乐成、失败超时等情况。
就是一个体系大概一个模块，调用了多个体系大概模块，相互之间的调用很复杂，维护起来很贫困。但是着实这个调用是不须要直接同步调用接口的，假如用 MQ 给它异步化解耦。
异步：
A 体系吸收一个哀求，须要在本身当地写库，还须要在 BCD 三个体系写库，本身当地写库要
3ms，BCD 三个体系分别写库要 300ms、450ms、200ms。终极哀求总延时是 3 + 300 + 450 + 200 = 953ms，靠近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过欣赏器发起哀求。假如使用MQ，那么 A 体系连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 体系从继续一个哀求到返回相应给用户，总时长是 3 + 5 = 8ms。
削峰：
镌汰高峰时期对服务器压力。
二、说说引入消息队列有什么优缺点？
长处上面已经说了，就是在特殊场景下有其对应的利益，解耦、异步、削峰。
缺点有以下几个：
体系可用性低落
原来体系运行好好的，现在你非要参加个消息队列进去，那消息队列挂了，你的体系不是呵呵了。因此，体系可用性会低落；
体系复杂度进步
参加了消息队列，要多思量很多方面的题目，比如：同等性题目、怎样包管消息不被重复消耗、怎样包管消息可靠性传输等。因此，须要思量的东西更多，复杂性增大。
同等性题目
A 体系处置处罚完了直接返回乐成了，人都以为你这个哀求就乐成了；但是题目是，要是 BCD 三个体系那里，BD 两个体系写库乐成了，效果 C 体系写库失败了，咋整？你这数据就不同等了。
以是消息队列实际是一种非常复杂的架构，你引入它有很多利益，但是也得针对它带来的弊端做各种额外的技能方案和架构来规避掉，做好之后，你会发现，妈呀，体系复杂度提升了一个数目级，大概是复杂了 10 倍。但是关键时间，用，还是得用的。
三、聊聊市面上各MQ的特点
ActiveMQ
ActiveMQ是老牌的消息中心件，国内很多公司已往运用的还黑白常广泛的，功能很强大。
但是题目在于没法确认ActiveMQ可以支持互联网公司的高并发、高负载以及高吞吐的复杂场景，在国内互联网公司落地较少。而且使用较多的是一些传统企业，用ActiveMQ做异步调用和体系解耦。
RabbitMQ
他的利益在于可以支持高并发、高吞吐、性能很高，同时有非常完满便捷的配景管理界面可以使用。别的，他还支持集群化、高可用摆设架构、消息高可靠支持，功能较为完满。而且颠末调研，国内各大互联网公司落地大规模RabbitMQ集群支持自身业务的case较多，国内各种中小型互联网公司使用RabbitMQ的实践也比力多。
除此之外，RabbitMQ的开源社区很活泼，较高频率的迭代版本，来修复发现的bug以及举行各种优化，因此综合思量过后，公司采取了RabbitMQ。但是RabbitMQ也有一点缺陷，就是他自身是基于erlang语言开发的，以是导致较为难以分析内里的源码，也较难举行深条理的源码定制和改造，究竟须要较为踏实的erlang语言功底才可以。
RocketMQ
是阿里开源的，颠末阿里的生产情况的超高并发、高吞吐的查验，性能杰出，同时还支持分布式事件等特殊场景。而且RocketMQ是基于Java语言开发的，恰当深入阅读源码，有须要可以站在源码层面办理线上生产题目，包罗源码的二次开发和改造。
Kafka
Kafka提供的消息中心件的功能显着较少一些，相对上述几款MQ中心件要少很多。但是Kafka的上风在于专为超高吞吐量的实时日志收罗、实时数据同步、实时数据盘算等场景来操持。因此Kafka在大数据范畴中共同实时盘算技能（比如Spark Streaming、Storm、Flink）使用的较多。但
是在传统的MQ中心件使用场景中较少接纳。
四、MQ消息堆积有碰到过吗
产生MQ消息堆积的缘故因由
[*]1. 生产者投递消息的速率与我们消耗者消耗的速率完全不匹配。
[*]2. 生产者投递消息的速率>消耗者消耗的速率 导致我们消息会堆积在我们 mq 服务器端中，没有实时的被消耗者消耗 以是就会产生消息堆积的题目
[*]3. 注意的是：rabbitmq 消耗者我们的消息消耗假如乐成的话 消息会被立即删除。 kafka 大概rocketmq 消息消耗假如乐成的话，消息是不会立即被删除。
办理办法
[*]1. 进步消耗者消耗的速率；（对我们的消耗者实现集群）
[*]2. 消耗者应该批量情势获取消息 镌汰网络传输的次数
五、MQ消息堆积有碰到过吗
为什么会出现重复消耗？
MQ的消息流程告急有两个阶段来完成，发送消息到消息队列以及消息队列将消息投递到消耗者，
由于各种网络缘故因由会造成发送方与以及吸收方消息重试，就会造成重复消耗
发送方消息重试
由于网络缘故因由以及MQ自身缘故因由会导致发送的消息未乐成投递到MQ，假如出现未乐成投递就会重复投递消息，这个时间是正常的，但是大概由于网络缘故因由导致消息确认消息延时，实际上已经投递到了MQ但是确认消息没有己实被发送方吸收到，就会重新发起消息重试，如许就会造成消息重复，这种是发送方消息重试，但是发送方重试次数是有限定的，假如到达肯定次数后还是失败假如没有做其他处置处罚就会造成消息丢失。
消耗方消息重试
当消息正常投递到MQ后，就须要消耗消息了，正常情况下消息会被发送到消耗方举行消耗，消耗方一样平常须要开启手动确认来确定消息肯定会被消耗掉，但是大概网络缘故因由导致消息未被消耗，这个时间消耗方就会重试消耗消息，假如是出现消耗超时大概非常就会举行消息重复消耗，假如非常没有处置处罚好导致消息重复消耗大概造成业务出现幂等性题目，但是假如做了幂等性题目，多次消耗还是失败就会造成消息丢失。
假如出现重复消耗怎样办理
唯一主键
手动给每一条消息增长一个唯一的消息ID，使用消息ID作为唯一主键，假如消息重复，消息插入不进去，用这种方式来办理消息重复
使用幂等
使用幂等方式来办理重复消耗题目，手动给每一条消息增长一个唯一的消息ID，不要使用体系天生的消息ID，假如天生消息后就将消息生存到Redis中，假如消息消耗乐成后删除Redis中的消息，假如失败了不须要管redis中的消息，如许就完来实现消息的幂等。
https://i-blog.csdnimg.cn/direct/6f57bb286b484821a08f7a9dfcd2f322.png
六、MQ怎样包管消息的有序消耗
什么是有序消耗
一个queue，有多个consumer去消耗，如许就会造成次序的错误，consumer从MQ内里读取数据是有序的，但是每个consumer的实行时间是不固定的，无法包管先读到消息的consumer肯定先完成使用，如许就会出现消息并没有按照次序实行，造成数据次序错误，而且实行的时间是多线程实行的，并不能包管明行的次序性。
https://i-blog.csdnimg.cn/direct/74d317342b514387b5bb937c5ac0869c.png
有序消耗的实践落地
单队列次序
[*]生产者：将消息按照次序发送到同一个队列。
[*]消耗者：单线程或一个消耗实例按消息进入队列的次序逐条消耗。
多队列分区次序
通太过区或分组机制，让同一分区内的消息保持有序。(Kafka、RocketMQ)
生产者：
[*]根据消息的业务属性（如订单 ID、用户 ID 等），盘算出哈希值或分区键。
[*]将类似分区键的消息发送到同一个队列或分区。
消耗者：
[*]每个分区对应一个固定的消耗实例，按次序拉取消息。
[*]在消息消耗完毕后，渐渐处置处罚下一条。
分布式锁机制
当存在多个消耗者时，可以使用Redis大概ZooKeeper等工具提供的分布式锁机制，确保同一时间只有一个消耗者可以或许处置处罚特定的消息。
消息重排序机制
[*]生产者：消息按恣意次序发送。
[*]消耗者：
[*]读取一批消息后，根据消息的时间戳、业务标识等排序规则对消息排序。
[*]消耗排序后的消息。
七、你会怎样操持一个MQ？说说操持MQ思绪？
起首这个 mq 得支持可伸缩性吧，就是须要的时间快速扩容，就可以增长吞吐量和容量，那怎么搞？
操持个分布式的体系呗，参照一下 kafka 的操持理念，broker -> topic -> partition，每个 partition 放一个呆板，就存一部分数据。假如现在资源不敷了，简单啊，给 topic 增长 partition，然后做数据迁移，增长呆板，不就可以存放更多数据，提供更高的吞吐量了？
其次你得思量一下这个 mq 的数据要不要落地磁盘吧？
那肯定要了，落磁盘才华包管别历程挂了数据就丢了。那落磁盘的时间怎么落啊？次序写，如许就没有磁盘随机读写的寻址开销，磁盘次序读写的性能是很高的，这就是 kafka 的思绪。
其次你思量一下你的 mq 的可用性啊？
这个事儿，具体参考之前可用性谁人环节讲授的 kafka 的高可用保障机制。多副本 -> leader & follower -> broker 挂了重新推选 leader 即可对外服务。能不能支持数据 0 丢失啊？可以的，参考我们之前说的谁人 kafka 数据零丢失方案。
八、怎样实现延时消息
延时消息就是一个消息须要延时多长时间才华够发送（也就是说，投递到MQ，延伸指定时间才被消耗），比如用户付出订单，假如多长时间未付出就会取消订单，这个就属于延时消息
实现延时消息的方法如下
数据库轮询
通过一个线程定时的去扫描数据库，通过订单时间来判断是否有超时的订单，然后举行update或delete等使用
JDK的延长队列
使用JDK自带的DelayQueue来实现，这是一个无界壅闭队列，该队列只有在延恒久满的时间才华从中获取元素，放入DelayQueue中的对象，是必须实现Delayed接口的。
https://i-blog.csdnimg.cn/direct/d8d0227596a145da91d298473513ea1d.png
时间轮算法
https://i-blog.csdnimg.cn/direct/d403d92e18264ea6977eea403746aa44.png
RabbitMQ
可以接纳RabbitMQ的死信队列来实现延时队列，RabbitMQ可以针对Queue和Message设置 xmessage-tt，来控制消息的生存时间，假如超时，则消息变为dead letter，dead letter会被投递到死信交换器，然后通过死信队列将消息发送出去
https://i-blog.csdnimg.cn/direct/bd0c484b8ebb4902b96bd69c98b46042.png
RocketMQ
RocketMQ可以实现18个品级的消息延时，但是不可以实现恣意时间的消息延时，使用RocketMQ的延时消息只须要按照正常消息发送，并指定延时品级即可，简单高效，而且这个延时时间可以在
RocketMQ的设置参数中举行设置
九、谈谈RocketMQ与Kafka的区别
业务为什么使用rocketmq 不消kafka
由于kafka的诞生是作为大数据的一个中心件来使用的，MQ只是kafka的一个功能，相对于RocketMQ，Kafka的功能相对于简单，RocketMQ操持的时间鉴戒了很多kafka的操持，有着后发上风，支持分布式、集群、副本等机制，消息延时也比力少，但是RocketMQ也有很多kafka不具备的功能，比如：严酷次序消息，延时消息，服务端tag过滤，可以或许至少包管消耗一个的可靠性战略，消息失败后重试时间随着次数递增等都是很多业务所须要的，而且RocketMQ是颠末了双十一的验证，以是很多人说RocketMQ是专门为业务而生的。
为什么kafka不能支持大量的topic
这句话假如严酷意义上说的话应该是kafka在topic-partition过多而不是单纯的topic过多
这个要从kafka的存储结构来提及，kafka的最小存储单元是一个partition，一个partition由一个数据文件以及一个索引文件构成，partition的存储文件是通过次序写的方式来包管写入磁盘的服从的，但是假如非常多的partition须要磁盘写入，那么就大概造成次序写变成随机写，由于磁盘的IO流量就那麽大，同时由很多个partition须要写入，就会变成随机写，性能反而会急剧降落，而且partition过多还是导致元数据管理，副本同步的困难，这些都是导致kafka不能支持大量topic的缘故因由。
为什么RcoketMQ可以支持大量的Topic
这个须要从RocketMQ的存储结构来说，RocketMQ的全部的数据存储在一个commitlog,然后则会通过异步线程将commitlog的数据转移到其他对应的消耗者的队列中，由于不管多少个队列也只有一个commitlog文件，全部写入以及读取性能不会随着队列的增长而有显着的变革
https://i-blog.csdnimg.cn/direct/46188feeefd54c28bd4dd978da17f7bb.png
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]