MQ消息中间件,面试能问些什么?
为什么使用消息队列?消息队列的优点和缺点?
kafka、activemq、rabbitmq、rocketmq都有什么优缺点?
面试官角度分析:
(1)你知不知道你们系统里为什么要用消息队列这个东西?
(2)既然用了消息队列这个东西,你知不知道用了有什么好处?
(3)既然你用了MQ,那么当时为什么选用这一款MQ?
1. 为什么使用消息队列?
面试官问这个问题的期望之一的回答是,你们公司有什么业务场景,这个业务场景有什么技术挑战,如果不用MQ可能会很麻烦,但是再用了之后带来了很多好处。
消息队列的常见使用场景有很多但是核心的有三个:解耦、异步、削峰
解耦
场景描述:A系统发送个数据到BCD三个系统,接口调用发送,那如果E系统也要这个数据呢?那如果C系统现在不需要了呢?现在A系统又要发送第二种数据了呢?A系统负责人崩溃中...再来点崩溃的事儿,A系统要时时刻刻考虑BCDE四个系统如果挂了怎么办?那我要不要重发?我要不要把消息存起来?头发都白了啊...
使用了MQ之后的解耦场景
面试技巧:你需要考虑下,你负责的系统中是否有类似的场景,就是一个系统或者一个模块,调用了多个系统或者模块,相互之间的调用很复杂,维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的,如果MQ给他异步化解耦也是可以的,你就需要去考虑在你的项目里是不是可以运用这个MQ去进行系统解耦 。
异步
场景描述:系统A接受一个请求,需要在自己本地写库,还需要在系统BCD三个系统写库,自己本地写库需要3ms。BCD分别需要300ms、450ms、200ms。最终总好时长:953ms,接近1s。给用户的体验感觉一点也不好。
不用MQ的同步高延时请求场景
使用MQ异步化之后的接口性能优化
削峰
场景描述:每天 0 点到 11 点,系统A风平浪静,每秒并发请求数量就 100 个。结果每一一到11点到1点,每秒并发请求数量就会暴增大1万条 。但是系统最大的处理能力就只能每秒钟处理1000个请求。
没有用MQ的时候高峰期系统被打死的场景
使用MQ来进行削峰的场景
2. 消息队列的有点和缺点?
优点:特殊场景下解耦、异步、削峰。
缺点:
系统可用性降低:系统引入的外部依赖越多,越容易挂掉,本来你就是A系统调用BCD三个系统的接口就好了,人ABCD四个系统好好的没什么问题,你偏加个MQ进来,万一MQ挂了怎么办,整套系统崩溃了,就完蛋了
系统复杂性提高:硬生生加个MQ进来,你怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性?
一致性问题:系统A处理完了直接返回成功了,人家都认为你这个请求成功了;但问题是,要是BCD三个系统哪里BD系统成功了,结果C系统写库失败了,咋整?数据就不一致了,
所以消息队列是一种非常复杂的架构,引入它有很多好处,但是也得针对他带来的坏处做各种额外的技术方案和架构来规避掉。做好之后你会发现系统复杂度提升了一个数量积,但是关键时刻,用,还是要用的。
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源码级别的研究和 |