MQ相关面试题
如果你的简历中有写到mq,那么面试官一般会问到如下几个问题,至少我在面试中经常常被问到,所以今天总结一下,有不对的地方还望多多包涵:
首先第一个问题,为什么要用mq?
如果这个问题你都没考虑过,那么说明你只是一个单纯会用mq技术的一个coder,而不是一个会独立思考的程序员,如果被面试官问到这个问题,你都没有回答上来,那么你的第一印象肯定会很差。
一、为什么要用mq?
(1)解耦:如果多个模块或者系统中,互相调用很复杂,维护起来比较麻烦,但是这个调用又不是同步调用,就可以运用mq到这个业务中。
(2)异步:这个很好理解,比如用户的操作日志的维护,可以不用同步处理,节约响应时间。
(3)削峰:在高峰期的时候,系统每秒的请求量达到 5000,那么调用 mysql 的请求也是 5000,一般情况下 mysql 的请求大概在 2000 左右,那么在高峰期的时候,数据库就被打垮了,那系统就不可用了。此时引入mq,在系统 a 前面加个 mq,用户请求先到 mq,系统 a 从 mq 中每秒消费 2000 条数据,这样就把本来 5000 的请求变为 mysql 可以接受的请求数量了,可以保证系统不挂掉,可以继续提供服务。mq 里的数据可以慢慢的把它消费掉。
二、使用了mq会有什么问题?
这个问题记住一个降低一个增加即可。
(1)降低了系统可用性 (2)增加了系统的复杂性
三、怎样选型mq?
如果你被问及这个问题,面试官主要是想看你选型的时候是否会比较架构的区别,是否满足业务需求。
特性 | activemq | rabbitmq | rocketmq | kafka |
单机吞吐量 | 万级 | 万级 | 十万级 | 十万级 |
topic 数量对吞吐量的影响 | - | - | topic 可以达到几百,几千个的级别,吞吐量会有较小幅度的下降 | topic 从几十个到几百个的时候,吞吐量会大幅度下降 |
时效性 | 毫秒级 | 微妙级 | 毫秒级 | 毫秒级 |
可用性 | 高 | 高 | 非常高,分布式架构 | 非常高,分布式架构 |
消息可靠性 | 有较低的概率丢失数据 | - | 经过参数优化配置,可以做到 0 丢失 | 经过参数优化配置,消息可以做到 0 丢失 |
功能支持 | 完善 | 并发能力很强,性能极其好,延时很低 | mq 功能较为完善,还是分布式的,扩展性好 | 功能较为简单,主要支持简单的 mq 功能,在大数据领域的实时计算以及日志采集被大规模使用,是事实上的标准 |
优劣势总结 | 非常成熟,功能强大;偶尔会有较低概率丢失消息;社区不活跃了 | 性能极其好,延时很低;功能完善;提供管理界面;社区比较活跃;吞吐量较低;使用 erlang 开发源码阅读不方便; | 接口简单易用;吞吐量高;分布式扩展方便;社区还算活跃;经过双 11 的考验 | mq 功能比较少;吞吐量高;分布式架构;可能存在消息重复消费问题;主要适用大数据实时计算以及日志收集; |
个人建议:
中小型公司,技术一般,可以考虑用 rabbitmq;
大型公司,基础架构研发实力较强,用 rocketmq 是很好的选择
实时计算、日志采集:使用 kafka;
四、怎样保证mq的高可用?
rabbitmq是比较有代表性的,因为是基于主从做高可用性的。以他为例,自行查阅以下模式。
rabbitmq有三种模式:单机模式、普通集群模式、镜像集群模式。
五、如何保证不被重复消费?
不通的消费队列都会有一个消费通知的机制,如:
rabbitmq提供了一个ack确认消息机制,
rocketmq返回一个consume_success成功标志
(1)比如,你拿到这个消息做数据库的insert操作。那就容易了,给这个消息做一个唯一主键,那么就算出现重复消费的情况,就会导致主键冲突,避免数据库出现脏数据。
(2)再比如,你拿到这个消息做redis的set的操作,那就容易了,不用解决,因为你无论set几次结果都是一样的,set操作本来就算幂等操作。
(3)如果上面两种情况还不行,上大招。准备一个第三方介质,来做消费记录。以redis为例,给消息分配一个全局id,只要消费过该消息,将<id,message>以k-v形式写入redis。那消费者开始消费前,先去redis中查询有没消费记录即可。
六、如何保证消费的可靠传输性?
每个mq都要从生产者丢失数据、消费队列丢失数据、消费丢失数据三个层面回答
(1) 生产者丢失数据
以rabbitmq为例,rabbitmq提供了transaction和confirm模式来确保生产者不丢失数据,事务机制,发送消息前,开启事务(channel.txselect()),发送消息后出现异常,事务回滚(channel.txrollback()),发送成功提交事务(channel.txcommit())。
上面这种方式吞吐量会下降,因此生产上应该使用confirm模式居多。
一旦channel进入confirm模式,所有在该通道发布上的消息都会被指派一个唯一的id(从1开始),消息进来如队列后,rabbitmq会立即发送一个ack给生产者,其中包含了消息的唯一id,这就使得生产者知道消息已经到达了消息队列里。如果消息队列没能处理该消息,则会发送一个nack给生产者进行重试操作。
channel.addconfirmlistener(new confirmlistener() { @override public void handlenack(long deliverytag, boolean multiple) throws ioexception { system.out.println("nack: deliverytag = "+deliverytag+" multiple: "+multiple); } @override public void handleack(long deliverytag, boolean multiple) throws ioexception { system.out.println("ack: deliverytag = "+deliverytag+" multiple: "+multiple); } });
(2) 消息队列丢失数据
消息队列丢失的情况一般是开启持久化硬盘配置,这个持久化配置可以和confirm机制配合使用,可以在持久化硬盘之后,发送一个ack给生产者,如果生产者收不到ack信息,会重发信息。
如何持久化硬盘:
①将queue的持久化标识durable设置为true,
②发送消息的时候将deliverymode=2
这样设置就算rabbitmq挂了,重启后也能恢复数据
(3) 消费者丢失数据
消费者丢失数据一般都是以为采用了自动确认消息模式。消费者收到消息后,rabbitmq会立即从队列里面删除该消息,这是情况如果消费者出现异常而没有及时处理该消息就会丢失数据。
解决方案:采用手动确认消息。
七、如何保证消息的时序性?
先进先出队列,比如linkedblockingqueue。