MQ面试高频题及实战答案.docxVIP

MQ面试高频题及实战答案

一、基础概念题（考察核心认知）

问题：为什么要用MQ？不用MQ直接调用不行吗？

答案：核心是解耦、削峰、异步通信。比如订单系统下单后，要调用库存、支付、物流、通知四个服务，同步调用的话响应时间是4个服务耗时总和，而且一个服务挂了会导致整个下单失败。用MQ的话，订单系统只需要把消息发出去就完事，后续服务异步消费，响应时间大幅缩短，还能避免级联故障。另外高并发场景（比如秒杀），瞬间请求会压垮下游，MQ能缓冲请求，让下游按自己的能力消费，这就是削峰。不用MQ的话，小流量场景没问题，但高并发、高可用要求高的系统会很脆弱。

问题：RabbitMQ和Kafka的核心区别是什么？怎么选？

答案：从几个关键维度区分：

架构：RabbitMQ是AMQP协议，基于交换机（Exchange）+队列（Queue），路由灵活（支持direct/fanout/topic等）；Kafka是基于主题（Topic）+分区（Partition），是日志型存储，路由简单。

性能：Kafka吞吐量更高（十万级/秒），适合大数据量场景；RabbitMQ吞吐量中等（万级/秒），但延迟更低（毫秒级）。

可靠性：RabbitMQ支持消息确认（ack）、持久化、死信队列，可靠性更强；Kafka通过副本机制保证可靠性，但消息确认机制相对简单。

适用场景：RabbitMQ适合业务解耦、异步通知（比如订单通知、支付回调），需要复杂路由和高可靠性的场景；Kafka适合日志收集、大数据分析、流处理（比如用户行为追踪），需要高吞吐量的场景。

问题：MQ的消息可靠性怎么保证？怕消息丢了、重复消费、顺序错乱？

答案：分三步解决，覆盖全链路：

避免丢失：①生产者端：开启消息确认（RabbitMQ的publisherconfirm，Kafka的acks=all），确保消息发往MQ；②MQ端：开启持久化（RabbitMQ的队列+消息持久化，Kafka的分区副本持久化），防止MQ宕机丢消息；③消费者端：先处理业务，再发送消费确认（RabbitMQ的ack，Kafka的offset提交），避免业务没处理完就确认导致消息丢失。

避免重复消费：本质是让消费逻辑幂等。比如用消息ID作为唯一键，数据库插入前先查是否存在；或者用分布式锁，处理消息前先抢锁，确保同一消息只被处理一次。

避免顺序错乱：①生产者端：同一业务（比如同一订单）的消息发往同一个分区/队列；②消费者端：单线程消费该分区/队列，或者用局部锁保证同一消息的处理顺序。比如Kafka的一个分区只能被一个消费者组的一个消费者消费，天然保证顺序，只要消费者不并发处理该分区消息即可。

二、架构与原理题（考察底层理解）

问题：RabbitMQ的交换机（Exchange）有哪些类型？分别用在什么场景？

答案：四种核心类型，路由规则不同：

Direct（直接交换机）：最常用，消息的RoutingKey必须和交换机绑定队列的BindingKey完全匹配，才会路由到该队列。场景：一对一通信，比如订单支付成功后，只通知物流系统处理。

Topic（主题交换机）：支持通配符匹配（匹配一个单词，#匹配多个单词），RoutingKey和BindingKey按规则匹配即可路由。场景：一对多通信，比如用户下单后，通知物流、仓储、财务三个系统，BindingKey可以设为“order.”，RoutingKey设为“order.logistics”“order.storage”等。

Fanout（扇出交换机）：不看RoutingKey，只要绑定该交换机的队列，都会收到消息，广播模式。场景：需要给所有相关系统发消息，比如系统公告、活动通知。

Headers（头交换机）：不用RoutingKey，而是根据消息的Headers属性匹配（比如消息头里的“type”=“payment”），匹配成功则路由。场景：RoutingKey复杂的场景，但实际用得少，不如Topic灵活。

问题：Kafka的分区（Partition）和副本（Replica）有什么作用？ISR机制是什么？

答案：

分区（Partition）：①提高吞吐量：Kafka的读写是按分区并行的，多个分区可以同时被读写，突破单节点性能瓶颈；②数据分片：海量消息按分区存储，每个分区对应磁盘上的一个日志文件，方便管理和扩展；③保证顺序：同一分区内的消息是有序的，按发送顺序存储和消费。

副本（Replica）：每个分区有多个副本（1个Leader+N个Follower），Leader负责处理读写请求，Follower同步