RabbitMQ、RocketMQ、Kafka、ActiveMQ消息中间件常见的面试题目

RabbitMQ、RocketMQ、Kafka、ActiveMQ 消息中间件常见的面试题目 了解消息中间件的使用场景是非常重要的，面试官可能会问你为什么使用消息队列，消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？其实，这个问题期望的一个回答是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。 消息队列的常见使用场景其实场景有很多，但是比较核心的有三个：解耦、异步、削峰。 解耦：A 系统发送个数据到 BCD 三个系统，接口调用发送，那如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？现在 A 系统又要发送第二种数据了呢？而且 A 系统要时时刻刻考虑 BCDE 四个系统如果挂了咋办？要不要重发？我要不要把消息存起来？你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给他异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个 MQ 去进行系统的解耦。 异步：A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 30ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 30 + 300 + 450 + 200 = 980ms，接近 1s，异步后，BCD 三个系统分别写库的时间，A 系统就不再考虑了。 削峰：每天 0 点到 16 点，A 系统风平浪静，每秒并发请求数量就 100 个。结果每次一到 16 点~23 点，每秒并发请求数量突然会暴增到 1 万条。但是系统最大的处理能力就只能是每秒钟处理 1000 个请求啊。怎么办？需要我们进行流量的削峰，让系统可以平缓的处理突增的请求。 消息队列有什么优点和缺点？优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。缺点呢？系统可用性降低系统引入的外部依赖越多，越容易挂掉，本来你就是 A 系统调用 BCD 三个系统的接口就好了，ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了怎么办？MQ 挂了，整套系统崩溃了，业务也就停顿了。系统复杂性提高硬生生加个 MQ 进来，怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？一致性问题A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，你这数据就不一致了。 RabbitMQ 的 queue 中存放的 message 是否有数量限制？默认情况下一般是无限制，因为限制取决于机器的内存，但是消息过多会导致处理效率的下降。可以通过参数来限制，x-max-length：对队列中消息的条数进行限制，x-max-length-bytes：对队列中消息的总量进行限制。 RabbitMQ 概念里的 channel、exchange 和 queue 这些东东是逻辑概念，还是对应着进程实体？这些东东分别起什么作用？queue 具有自己的 erlang 进程；exchange 内部实现为保存 binding 关系的查找表；channel 是实际进行路由工作的实体，即负责按照 routing_key 将 message 投递给 queue。 消息的重复 原因第一类原因消息发送端应用的消息重复发送,有以下几种情况。消息发送端发送消息给消息中间件,消息中间件收到消息并成功存储,而这时消息中间件出现了问题,导致应用端没有收到消息发送成功的返回因而进行重试产生了重复。消息中间件因为负载高响应变慢,成功把消息存储到消息存储中后,返回“成功”这个结果时超时。消息中间件将消息成功写入消息存储,在返回结果时网络出现问题,导致应用发送端重试,而重试时网络恢复,由此导致重复。可以看到,通过消息发送端产生消息重复的主要原因是消息成功进入消息存储后,因为各种原因使得消息发送端没有收到“成功”的返回结果,并且又有重试机制,因而导致重复。 第二类原因消息到达了消息存储,由消息中间件进行向外的投递时产生重复，有以下几种情况。消息被投递到消息接收者应用进行处理,处理完毕后应用出问题了,消息中间件不知道消息处理结果,会再次投递。消息被投递到消息接收者应用进行处理,处理完毕后网络出现问题了,消息中间件没有收到消息。