2025年消息队列笔试真题（网友回忆版）及答案解析

2025年消息队列笔试真题（网友回忆版）及答案解析一、单项选择题（每题2分，共8分）1.下列哪种消息投递语义能够保证消息至少被消费一次，但可能产生重复消费？A.At-most-onceB.At-least-onceC.Exactly-onceD.Fire-and-forget答案B解析At-least-once语义下，消费者处理成功后若ack丢失或超时，消息会被重新投递，因此能保证不丢消息但可能重复。2.在RabbitMQ中，如果所有消费者都不存在，此时向一个不设置TTL的队列发送消息，该消息会处于什么状态？A.立即被丢弃B.在队列中持久化等待消费者C.路由到备份交换机D.返回给生产者答案B解析消息发送到队列后，若没有消费者且未设置消息过期时间，消息会一直保存在队列中，直到消费者上线消费或队列被删除。3.Kafka中，同一个消费者组内两个消费者同时订阅同一个Topic，且该Topic有4个分区，下列说法正确的是？A.两个消费者各自独立消费全部4个分区B.每个消费者各分配2个分区，同一分区不会被组内多个消费者同时消费C.消息会重复投递给两个消费者D.消费者组与分区分配无关答案B解析Kafka保证同一个消费者组内，一个分区只会被组内一个消费者消费。分区数为4、消费者数为2时，通常均衡分配为每人2个分区。4.RocketMQ中，默认的消费模式是？A.Pull模式B.Push模式C.Ping模式D.Poll模式答案B解析RocketMQ的DefaultMQPushConsumer基于长轮询实现Push效果，Broker主动推送消息给消费者，兼顾实时性与服务端压力。二、多项选择题（每题4分，共16分）1.下列哪些机制可以用于提高消息队列的可靠性？（）A.生产者消息确认（ACK）B.Broker端多副本同步C.消息持久化到磁盘D.消费者手动提交位移答案ABCD解析四者均能提升可靠性。生产者确认可避免send阶段丢失；多副本同步可避免Broker宕机丢数据；持久化可防进程崩溃丢数据；手动提交位移可防止消费者消费失败但位移已更新导致的数据丢失。2.关于消息队列的削峰填谷作用，下列描述正确的有？（）A.消息队列可以将突发流量暂存在队列中，避免后端系统瞬间过载B.消费端可以按照自身处理能力拉取消息，起到调峰填谷的效果C.削峰填谷要求严格保证消息的顺序性D.削峰填谷对于对实时性要求极高的支付交易场景同样绝对适用答案AB解析C错误，顺序性与削峰填谷没有必然关系；D错误，引入消息队列会增加链路延迟，对极端实时性场景需要权衡。3.Kafka中完成一次正常的生产发送，消息位移提交需要哪些配合？（）A.Producer端可配置acks参数控制ISR确认条件B.Consumer端自动提交或手动提交offset两种方式C.Consumer端必须将offset提交到ZooKeeperD.Consumeroffset可以提交到Kafka内部topic__consumer_offsets答案ABD解析Kafka新版已将offset存储从ZooKeeper迁移到Kafka内部topic，C错误。4.下列哪些场景适合引入消息队列？（）A.系统解耦——上游系统无需关心下游是否在线B.日志收集与汇聚C.流计算任务的实时输入管道D.跨网络传输一个200GB的大文件答案ABC解析消息队列适合解耦、异步、削峰、日志收集、流计算等场景；大文件传输应使用专用传输通道，消息队列对超大消息的支持能力及应用效率并不合适。三、判断题（每题2分，共10分）1.RabbitMQ中，一个Exchange必须至少绑定一个Queue，否则消息将被直接丢弃。答案错误解析Exchange可以不绑定任何队列，此时消息无法路由会被丢弃，但这并非配置要求。2.Kafka的分区数只能增加，不能减少。答案正确解析Kafka只支持增加分区，不支持减少分区。减少分区会破坏分区内数据有序性及offset对应关系。3.RocketMQ的顺序消息分为局部顺序和全局顺序，全局顺序需要将Topic设置为1个队列（分区）。答案正确解析若Topic有多个队列，并发发送会导致消息分布在多个队列，全局顺序无法保证；全局顺序消费要求Topic单队列。4.消息队列只能实现点对点通信，不能实现发布订阅模型。答案错误解析RabbitMQ的topic/fanout交换机、Kafka的consumergroup、RocketMQ的广播模式均支持发布订阅。5.在开启消费者手动ack时，若消费逻辑抛异常，应直接调用acknowledge()方法确认消息，以便消息不再重复投递。答案错误解析异常时应拒绝消息或重新入队，若直接ack会丢失消息，违背可靠性原则。四、简答题（每题10分，共30分）1.简述Kafka的副本副本同步机制（ISR）及其在可靠性与可用性之间如何取舍。答案Kafka每个分区有多个副本，分布在不同的Broker上。其中Leader负责读写，Follower负责同步。ISR（In-SyncReplicas）是保持与Leader同步的副本集合。原理：1.生产者发送消息到Leader，消息写入Leader的log；2.Follower主动向Leader拉取消息并写入自身本地日志；3.当Follower落后过多或长时间未同步，会被从ISR中剔除；4.生产者可设置acks：•acks=0：不等待确认，性能最高但可能丢消息；•acks=1：Leader写入确认，Leader宕机可能丢失消息；•acks=all（-1）：所有ISR副本都确认，可靠性最高。可靠性优先时使用acks=all并保证min.insync.replicas至少为2；可用性优先时可降低acks或放宽ISR淘汰条件，但会带来丢消息风险。2.消息队列中常见的消息堆积原因有哪些？请列举至少4类并提出解决方案。常见原因：1.消费者能力不足：消费速率低于生产速率；2.消费者阻塞：消费逻辑包含耗时操作，如RPC、慢SQL、死循环；3.消费者实例数过少：分区数固定，消费者数量超过分区数后无法再提高并行度；4.消费失败重试：消息反复处理失败，被不断回队列或进死信队列；5.下游资源瓶颈：数据库、接口等下游系统响应变慢。解决方案：1.水平扩容消费者实例，且使消费者数量不超过分区数（Kafka）或合理设置并发度（RocketMQ/RabbitMQ）；2.优化消费逻辑，将耗时操作异步化或批量处理；3.针对重试策略设置最大重试次数，超限进入死信队列；4.临时紧急迁移：将堆积消息转发至新的临时Topic，启动额外消费者集群处理；5.监控消费者lag，设定告警阈值。3.解释消息队列中“顺序消息”的两种类型，并分别说明实现方式。顺序消息分为局部顺序和全局顺序。局部顺序：同一个分区/队列内的消息有序。实现方式：•生产者：将具有相同业务标识（如订单号）的消息发送到同一个分区/队列，Kafka通过key哈希路由，RocketMQ通过MessageQueueSelector；•消费者：使用单消费者或基于分区的并发模型，保证同一分区的消息被顺序处理；•中途失败：禁止消费失败跳过，需重试或挂起后续消息。全局顺序：整个Topic的所有消息全体有序。实现方式：•该Topic只配置1个分区/队列；•生产者串行发送，消费者串行消费；•对性能约束很大，一般仅在极少数严格全局有序场景使用。五、应用题（每题18分，共36分）1.某电商平台订单系统使用Kafka作为消息中间件。消费者服务负责将订单消息同步到数据库。为了提升性能，开发同学设置消费者自动提交偏移量为enable.automit=true且erval.ms=5000。随后一次发版中，消费者在拉取一批消息后、处理到第3条时报错退出，此时距离开财自动提交只有2秒。请回答：（1）该批次的偏移量是否会在5秒后被自动提交？可能导致什么问题？（2）若要保证“不丢消息、不重复消费”，应该如何配置和处理？答案（1）如果消费者进程在报错后直接退出或再平衡，由于未到达自动提交间隔，偏移量不会被提交。但已消费的前2条消息对应的偏移量由于不会单独提交，重启后消费者仍会从上次已提交位移开始消费，因此前2条消息会被重复消费。若消费者在报错后仍继续运行（未停止消费循环），则可能继续处理后续消息，并在5秒间隔到达时把包含处理成功的消息位移提交，导致第3条之后部分未处理完的消息丢失。（2）建议采用手动提交偏移量：•设置enable.automit=false；•在每批消息全部处理成功后，再提交该批次最后的偏移量；•在消费逻辑中对单条消息处理失败提供重试机制，重试仍失败时将该消息投递至死信队列或进行补偿；•使用commitSync或commitAsync，在确保处理成功后再提交，保证位移与业务处理逻辑一致。此外还要保证消费逻辑具备幂等性，例如以订单ID作为唯一约束或使用版本号标记，防止重复消费带来重复写入。2.某系统选用RocketMQ，由生产端发送订单支付成功事件给积分服务、短信服务等多个下游。请结合RocketMQ的事务消息机制，回答以下问题：（1）发生Broker宕机或网络分区时，如何保证本地业务操作（订单支付状态更新）与消息发送的最终一致性？（2）说明RocketMQ事务消息的完整执行流程（包括HalfMessage、事务状态检查等）。（3）如果下游积分服务消费事件时失败，系统应如何设计以保证积分最终能够增加？答案（1）RocketMQ事务消息可以保证本地事务与消息发送在同一分布式事务内。即使Broker宕机或网络分区，Broker端仍保留HalfMessage，并通过回查生产者事务状态来决定提交或回滚。生产者需要实现LocalTransactionChecker提供状态确认，从而做到系统最终一致。（2）流程如下：1.Producer向Broker发送HalfMessage（半消息），Broker保存该消息并暂不让消费者可见；2.Producer执行本地事务（如更新订单支付状态）；3.Producer根据本地事务结果向Broker提交Commit或Rollback；4.如果Producer未提交事务状态，或者连接中断，Broker定期向Producer发起事务回查；5.Producer根据本地事务的最终结果（如事务表记录）返回Commit或Rollback；6.Broke