RabbitMQ 常见面试题
1.为什么要用消息队列? (消息队列的应用场景?)
2.各种消息队列产品的比较?
3.消息队列的优点和缺点?
4.如何保证消息队列的高可用?
5.如何保证消息不丢失?
6.如何保证消息不被重复消费?(如何保证消息消费的幂等性)
7.如何保证消息消费的顺序性?
8.大量消息堆积处理怎么处理?
9.消息过期怎么处理?
1.为什么要用消息队列? (消息队列的应用场景?)
面试官心里分析
考察面试者是否知道为什么要用消息队列?
消息队列在项目中解决的是什么样的问题?
消息队列的本质
-
消息队列一种“先进先出”的数据结构
-
常见应用场景:解耦、异步、削峰
解耦
系统的耦合性越高,容错性就越低。以电商应用为例,用户创建订单后,如果耦合调用库存系统、物流系统、支付系统,任何一个子系统出了故障或者因为升级等原因暂时不可用,都会造成下单操作异常,影响用户使用体验。
使用消息队列解耦合,系统的耦合性就会提高了。比如物流系统发生故障,需要几分钟才能修复,在这段时间内,物流系统要处理的数据被缓存到消息队列中,用户的下单操作正常完成。当物流系统恢复后,补充处理存在消息队列中的订单消息即可,终端系统给感知不到物流系统发生过几分钟故障
异步
A系统接收一个请求,需要在自己本地写库,还需要在B、C、D三个系统写库,自己本地写库要3ms,B、C、D三个系统分别写库要300ms、450ms、200ms。最终请求总时是3 + 300 + 450 + 200 = 953ms,接近1s,用户非常不好,一般互联网类的企业,对于用户直接的操作,一般要求是每个请求必须在200ms内完成,对用户几乎是无感知的,如果用户通过浏览器发起请求,等待个1s,这几乎是不可接受的。
如果使用MQ,那么A系统连续发送3条消息到MQ队列中,假如耗时5ms,A系统从接收一个请求到返回响应给用户,总时长是3 + 5 = 8ms,对于用户而言,相应速度大大提升了,改善了用户的体验
流量削峰
应用系统如果遇到系统请求流量的瞬间猛增,有可能会将系统压垮。有了消息队列可以将大量请求缓存起来,分散到很长一段时间处理,这样可以大大提到系统的稳定性和用户体验。
一般情况,为了保证系统的稳定性,如果系统负载超过阈值,就会阻止用户请求。这会影响用户体验,而如果使用消息队列将请求缓存起来,等待系统处理完毕后通知用户下单完毕,这样比不能下单体验要好。
流量削峰的经济考量
业务系统正常时段的QPS如果是1000,流量最高峰是10000,为了应对流量高峰配置高性能的服务器显然不划算,这时可以使用消息队列对峰值流量削峰。
小结
为什么要用消息队列
- 解耦
- 异步
- 削峰
2.各种消息队列产品的比较?
面试官心里分析
考察面试者是否对市面上的MQ产品做过调研?
在选择MQ时是否根据不同MQ的产品特点做过对比和取舍?
几种MQ的对比
小结
- ActiveMQ,早期使用的较多,没经过大规模吞吐量场景的验证,社区也不是很活跃,但是现在确实大家用的不多了,不推荐
- RabbitMQ,开发语言erlang阻止了大量的Java工程师去深入研究和掌控它,对公司而言,几乎处于不可控状态,但是RabbitMQ是开源的,比较稳定的支持,活跃度也高,如不考虑二次开发,最求性能和稳定性,推荐使用。
- RocketMQ,开发语言是Java,在阿里内部经受过高并发业务的考验,稳定性和性能均不错,考虑后期可能二次开发,推荐使用。
- Kafka,大数据领域的实时计算,日志采集等场景,用Kafka是业内标准的,社区活跃度很高,推荐使用。大数据领域日志采集等业务推荐使用。
3.消息队列的优点和缺点?
面试官心里分析
考察面试者在项目中引入一个新的技术后,是否思考过该技术对项目带来的有点和弊端,而不仅仅是停留在机械的使用。
优点:
- 解耦
- 异步
- 削峰
缺点:
- 系统可用性降低
- 系统复杂度提高
- 一致性问题
系统可用性降低
系统引入的外部依赖越多,系统稳定性越差。一旦MQ宕机,就会对业务造成影响。
Q:
如何保证MQ的高可用?
系统复杂度提高
MQ的加入大大增加了系统的复杂度,以前系统间是同步的远程调用,现在是通过MQ进行异步调用。
Q:
- 消息丢失怎么办
- 重复消息怎么处理
- 如何保证消息传递的顺序性?
一致性问题
A系统处理完业务,通过MQ给B、C、D三个系统发消息数据,如果B系统、C系统处理成功,D系统处理失败。
Q:
如何保证消息数据处理的一致性?
4.如何保证消息队列的高可用?
面试官心里分析
项目引入了MQ导致系统的可用性降低,面试官想知道的是面试者针对可用性较低问题的思考和解决思路。
回答此问题时,面试者只需针对自己使用过的一两个MQ产品的高可用方案回答即可。
RabbitMQ高可用-普通集群
-
在多台机器上分别启动RabbitMQ实例。
-
多个实例之间可以相互通信。
-
创建的Queue只会放在一个RabbitMQ上,其他实例都同步元数据
-
消费的时候,如果连接的没有Queue,那么当前实例会从queue所在实例拉取数据。
特点:
- 没有真正做到高可用
- 有数据拉取的开销和单实例的瓶颈问题
RabbitMQ高可用-镜像集群
- 在多台机器上分别启动RabbitMQ实例。
- 多个实例之间可以相互通信
- 每次生产者写消息到queue的时候,都会自动把消息同步到多个实例的queue上。每个RabbitMQ节点上都有Queue的消息数据和元数据。
- 某一个节点宕机,其他节点依然保存完整数据,不影响客户端消费
RocketMQ 高可用-双主双从
- 生产者通过NameServer发现Broker
- 生产者发送队列消息到2个Broker主节点
- Broker主节点分别和各自从节点同步数据
- 消费者从主或从节点订阅消息
小结
MQ的高可用如何保证?
- RabbitMQ : 镜像集群
- RocketMQ: 双主双从
5.如何保证消息不丢失?
面试官心里分析
- 考察面试者是否清楚消息丢失的原因?
- 如何保证消息不丢失?
消息丢失的原因
情况一:消息生产者没有成功发送到MQ Broker
情况二:消息发送给MQ Broker后,Broker宕机导致内存中的消息数据丢失
情况三:消费者消费到了消息,但是没有处理完毕就出现异常导致丢失。
确保消息不丢失方案
- 消息发送者发送给MQ Broker后,MQ Broker给生产者确认收到
- MQ收到消息后进行消息持久化
- 消费者收到消息处理完毕后手动进行ack确认
- MQ收到消费者ack确认后删除持久化的消息
小结
- 消息丢失的原因:
发送方、MQ、消费方都有可能导致消息丢失 - 如何保证消息不丢失
- 发送方可靠发送
- MQ进行消息持久化
- 消费方消费完毕进行ACK确认,MQ收到消费方的ACK确认再删除本地消息
6.如何保证消息不被重复消费?(如何保证消息消费的幂等性)
面试官心里分析
消息的重复消费和保证幂等性会经常被连着问,当出现了重复消息后,为了保证系统数据的正常性,就必须要保证幂等性。针对该问题,面试官实际想要考察的是:
- 面试者对重复消息产生的原因的思考
- 面试者对保证消息幂等性的方案
重复消息产生的原因
消息重复的根本原因是网络不可达
- 发送时消息重复
当一条消息已被成功发送到服务端,此时出现了网络闪断,导致服务端对客户端应答失败。如果此时生产者意识到消息发送失败并尝试再次发送消息,消费者后续会收到两条内容相容的消息
- 消费时消息重复
消息消费的场景下,消息已投递到消费者并完成业务处理,当消费方给MQ服务端反馈应答的时候网络闪断。为了保证消息至少消费一次,MQ服务端将在网络恢复后再次尝试投递之前已被消费方处理过的消息,此时消费者就会收到两条内容相同的消息
消息幂等性
- 消息发送者发送消息时携带一个全局唯一的消息id
- 消费者获取消费后先根据id在redis/db中查询是否存在消费记录
- 如果没有消费过就正常消费,消费完毕后写入redis/db
- 如果消息消费过就直接舍弃
小结
- MQ消息的重复问题和幂等性保证?
- 消息重复原因
- 网络不可达,不可避免
- 幂等性
- 消息携带全局ID,消费方接到消息时先查在处理,根据全局ID判断如果是重复消息直接丢弃
- 消息重复原因
7.如何保证消息消费的顺序性?
面试官心理分析
- 考察消费者是否理解什么是消息顺序消费?
- 考察消费者是否思考过确保消息顺序消费的方案?
消息的顺序性消费
消息有序指的是可以按照消息的发送顺序来消费。
例如:一笔订单产生了3条消息。分别是订单创建、订单付款、订单完成。
消费时,要按照顺序依次消费才有意义。
与此同时多笔订单之间又是可以并行消费的。
模型一:M1、M2按照先后顺序发送到2台Server,被2个消费者分别消费
- 不能保证消息的顺序到达MQ
- 不能保证消息的顺序消费
不能保证
模型二:M1、M2按照先后顺序发送到1台Servier,被2个消费者分别消费
- 可以保证消息的顺序到达MQ。
- 消费方如果出现网络延迟问题,不能严格保证消息的顺序消费。
不能保证
模型三:M1、M2按照先后顺序发送到1台Server,被2个消费者分别消费
- 可以保证消息的顺序到达MQ。
- M1消费完毕并成功应答后,MQServer在发送M2
实现复杂,不推荐
模型四:生产者:MQ Server:消费者=1:1:1
- 可以保证消息顺序到达MQ
- 可以保证消息顺序消费
全局的顺序消费不常见!
- 吞吐量下降
- 容错性降低
模型五:局部顺序消费
- 生产者根据消息ID将同一组消息发送到一个Queue中。
- 多个消费者同时获取Queue中的消息进行消费。
- MQ使用分段锁保证单个Queue中的有序消费
小结
-
什么是消息的顺序消费?
- 消费方按照消息发送的顺序进行消费,分为全局顺序消息和局部顺序消息
- 常见的是局部顺序消息
-
如何保证消息的顺序消费?
-
全局顺序消息,生产者:MQ:消费者 = 1:1:1
-
局部顺序消息:
2.1 生产者将同一组消息发送到单个队列
2.2 多个消费者并行对消息进行消费
2.3 Queue通过分段锁保证消息消费的顺序性
-
8.大量消息堆积处理怎么处理?
面试官心理分析
1.考察面试者是否清楚消息堆积的原因?
2.针对消息堆积如何进行处理?
消息堆积的原因
消费方出现了故障导致消息没有正常消费:
- 网络故障
- 消费方处理消息后没有给MQ Server正常应答
消息堆积的处理方案
- 检查并修复消费方的正常消费速度
- 将堆积消息转存到容量更大的MQ集群
- 增加多个消费者节点并行消费堆积消息
- 消费完毕后,恢复原始架构
小结
- 消息堆积的原因?
- 消费方消费出现故障
- 如何处理堆积消息?
- 将堆积消息分发到更大容量的MQ集群
- 增加消费方节点并行消费
9.消息过期怎么处理?
面试官心里分析
- 考察面试者是否知道消息为什么会过期?
- 针对过期消息如何处理?
消息过期的原因
消息设置了过期时间,如果超时还未被消费,则视为消息过期。
过期消息可以转存到死信队列
消息过期的处理方案
- 过期消息进入到死信队列
- 启动专门的消费者消费死信队列消息,并写入到数据库记录日志
- 查询数据库消息日志,重新发送消息到MQ
小结
- 过期消息产生的原因?
- 消息设置了过期时间
- 消费方消费出现故障,导致消息一直未被处理,消息就会过期
- 如何处理过期消息?
- 设置死信队列,接受过期消息
- 消费死信队列中的过期消息,记录日志
- 此后查询过期消息发送到MQ