消息队列面试官爱问的问题(一)

1.面试官心理分析

• 希望得知候选人是否清楚，系统里为什么使用消息队列 绝对不能让面试官看出，为了用而用。
• 既然用了MQ，知不知道用了MQ有什么好处 不能让面试官觉着自己是挖坑型选手
• 使用某一种MQ，那么有无做过调研

(1)为什么使用消息队列？

期望回答，就是公司有个什么业务场景，这个业务场景有什么技术挑战，如果不使用MQ会很麻烦，用了MQ会带来很多好处。

 

解耦前

 

 

 

解耦后

解耦后 

面试技巧

现场画图说明一下， 需要考虑一下自己负责的系统是否有类似的场景，一个系统或者一个模块，调用了多个系统或模块，互相之间调用很复杂，维护起来很麻烦。但其实系统不需要同步调用接口，就可以使用MQ异步化解耦。在简历中体现出来。

1.描述下消息队列的使用场景

我们有一个订单系统，订单系统每次生成一个新订单的时候，就会发送一条消息到MQ。后台的库存系统获取了消息，然后更新了库存

2.为什么使用消息队列

简单说一下消息队列的使用场景，比较核心的有：解耦、异步、削峰

(1)解耦

 解耦后 

(2)异步

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

使用MQ进行异步化之后接口性能优化

(3)削峰

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

使用MQ进行削峰 

2.消息队列有啥缺点

优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰

缺点呢？显而易见的

系统可用性降低：系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。

系统复杂性提高：硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已

一致性问题：A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。

所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，最好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时刻，用，还是得用的。。。

3.kafka、activemq、rabbitmq、rocketmq都有什么优点和缺点啊？

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，吞吐量比RocketMQ和Kafka要低了一个数量级	万级，吞吐量比RocketMQ和Kafka要低了一个数量级	10万级，RocketMQ也是可以支撑高吞吐的一种MQ	10万级别，这是kafka最大的优点，就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic数量对吞吐量的影响			topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降这是RocketMQ的一大优势，在同等机器下，可以支持大量的topic	topic从几十个到几百个的时候，吞吐量会大幅度下降，所以在同等机器下，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唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集

总结：

综上所述，各种对比之后，我个人倾向于是：

一般的业务系统要引入MQ，最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；

后来大家开始用RabbitMQ，但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他，对公司而言，几乎处于不可控的状态，但是确实人是开源的，比较稳定的支持，活跃度也高；

不过现在确实越来越多的公司，会去用RocketMQ，确实很不错，但是我提醒一下自己想好社区万一突然黄掉的风险，对自己公司技术实力有绝对自信的，我推荐用RocketMQ，否则回去老老实实用RabbitMQ吧，人是活跃开源社区，绝对不会黄

所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择

如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范

(三)引入消息队列后如何保证队列的高可用

1.面试题如何保证消息队列的高可用？

2.面试官心理分析

消息队列面试中高可用是必问的。MQ缺点很多，系统可用性降低，复杂性，一致性问题。要围绕MQ的缺点解决问题

3.面试题分析

所有水平的面试官，问的是MQ高可用怎么保证，就是自己用的MQ的高可用怎么保证

(1)RabitMQ的高可用性 RabitMQ的高可用是基于主从的，有三种模式：

• 单机模式

就是demo级别的，本地启动玩玩的，没人生产用单机模式

• 普通集群模式

在多台机器上启动多个rabitmq实例，每个机器启动一个。但是创建的queue只会放在一个rabitmq实例上，但是每个实例都同步queue的元数据。消费的时候，如果实际上连接到另一个实例上，那么实例会从queue所在的实例拉取数据过来。 这种方式麻烦，没有做到分布式，只是个普通集群。导致消费者要么随机连接一个实例而然后拉取数据(有数据拉取的开销)，要么固定连接那个queue所在的实例上(导致单例性能瓶颈)

而且如果那个queue的实例宕机了，会导致其他实例无法从这个实例中拉取，如果开启消息持久化，让rabitmq落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以从这个queue拉取数据。

这个方案没有啥高可用性可言，主要用来提高吞吐量的，就是说集群多个节点来服务某个queue的读写操作

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

• 镜像集群模式

这种模式才是所谓的rabitmq的高可用模式，创建的queue无论数据还是queue的消息会存在多个实例上，每次写消息到queue时，会自动把消息同步到多个实例的queue里。

好处是，任何一个机器宕机，别的机器都可以用。 坏处是，第一，性能开销太大，消息同步所有机器，导致网络带宽压力和消耗很重； 第二，扩展性很差，如果某个queue负载很重，加机器，新增的机器也包含了这个queue的所有数据，没法线性扩展queue

镜像集群模式 

怎么开启镜像集群模式？ 在后台新增一个策略，就是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点上，也可以要求指定数量的节点，再次创建queue的时候，应用这个策略时，自动将数据同步到其他节点上

 

(2)kafkaMQ的高可用性 RabitMQ的高可用是分布式的

kafka最基本的架构的认识：多个broker组成，每个broker是一个节点；创建一个topic，topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition存放一部分数据。

天然的分布式消息队列，就是说一个topic的数据，是分散在多个机器上的，每个机器存放一部分数据。

实际上rabitmq之类，并不是分布式的消息队列，传统的消息队列，不过提供了一场集群、HA机制而已，无论怎么使用，rabitmq一个queue的数据都是放在一个节点里，镜像集群下，每个节点存放的queue也是完整的数据

kafka0.8以前没有HA机制，就是任何一个broker宕机了，那个broker上的数据就废了，没法读也没法写，没有什么高可用性可言

kafka 0.8以后，提供了HA机制，就是replica副本机制。每个partition的数据都会同步到其他机器上，形成自己多个replica副本。然后所有的副本就会选举一个leader出来，生产者和消费者都和这个leader打交道，其他replica就是follower。写的时候，leader会负责把所有的数据都同步到follower上去。读的时候直接读leader上的数据即可。 为啥只能读写leader？很简单，如果可以随意读写每个follower的数据，那么就要考虑数据一致性问题，系统复杂度太高，容易出问题。kafka会均匀将一个partition的所有replica分布在不同机器上，提高容错性。