面经策

消息队列设计成推消息还是拉消息？推拉模式的优缺点？ ​

  • 标签：消息队列、后端、场景题

🏛 业务架构师 ​

推拉模式的对比本质是**"谁掌握节奏"**：

  • Push（broker 推给消费者）：延迟低（有消息立即投递），实时性好；但消费者能力参差时，快的被拖着、慢的被压垮——broker 无法准确感知消费端容量，过载时雪上加霜；
  • Pull（消费者主动拉）：消费者按自己的处理能力控制拉取速率——天然的背压机制；broker 实现简单（无连接状态推送压力）。代价是延迟受轮询间隔影响（空轮询浪费）。

主流 MQ 的现实选择：Kafka/RocketMQ 本质都是 Pull，用"长轮询"弥补空转——消费者拉不到消息时挂起等待（不空转），消息到达立即唤醒，兼得低延迟与消费者自治。RabbitMQ 的"推"也带 prefetch（QoS）限流——broker 最多推送未 ack 消息数上限，给推模式装上背压阀门。

业务视角的选型映射（按业务的实时性画像）：

  • 交易提醒、风控指令（秒级敏感）：长轮询 Pull 或带 prefetch 的 Push，延迟优先；
  • 报表消费、批处理同步（分钟级可接受）：定时批量 Pull，攒批处理摊薄单条开销，吞吐优先；
  • 消费者能力异构（大客户小客户混跑）：必须消费者控速，Push 会把小客户打死。

架构启示可以推广：一切生产消费速度不匹配的系统，都要回答"节奏由谁定"——上游定（push+限流）延迟低但风险集中，下游定（pull/长轮询）健壮但延迟受控。消息队列选择了下游自治，这个选择保护的是整个链路的存活。

🏗 系统架构师 ​

主流 MQ 实际都是 Pull 为主、Push 为辅（长轮询伪装的 push），我按模型本质分析：

推（Push）：

  • 优点：实时性强（有消息即投）、消费者无需管理拉取节奏；
  • 缺点：消费速率与生产速率解耦不了——broker 按自己的节奏推，消费者处理不过来时要么堆积在客户端内存（OOM），要么背压机制复杂；broker 要维护每个消费者的投递状态，连接压力大。

拉（Pull）：

  • 优点：消费者按自身处理能力控制拉取速率，天然背压；broker 无状态化简单；批量拉取吞吐高；
  • 缺点：空轮询——没消息时反复拉浪费资源；实时性有拉取间隔的延迟。

工程上的收敛方案——长轮询：消费者发起拉取，broker 没消息时挂住请求（如 15~30 秒），期间有消息立刻返回——对外体验接近 push 的实时，对内保持 pull 的速率控制。RocketMQ、Kafka（fetch.min.bytes/max.wait.ms）、RabbitMQ 的 basicConsume（推模式但内置 QoS prefetch 背压） 都是这个思路的变体。

我的设计结论：MQ 消费模型选型的核心变量是背压归属——谁负责匹配生产和消费速率。Pull + 长轮询 + 客户端缓冲（prefetch 限流）是业界验证过的最优组合：实时性损失毫秒级，换来了消费者不被冲垮的稳定性。

💻 全栈开发专家 ​

结论：主流 MQ 都是"拉"为主，RocketMQ 的"push"本质是长轮询拉。

推（Push）模式：

  • 优点：实时性强，broker 有消息立刻送达；
  • 缺点：broker 要维护每个消费者的状态（哪些发过、没 ack 谁）；消费能力不匹配时会压垮消费者（消费者在处理中又被灌入），或 broker 内存堆积；节流/重试逻辑复杂。
  • RabbitMQ 的推（basicDeliver + prefetch）：靠 prefetch（预取计数） 限制在途消息数兜底，本质是带流控的推。

拉（Pull）模式：

  • 优点：消费者按自己的节奏拉，天然流控、天然削峰；broker 无状态（不用记消费进度到每个连接）；批量拉取效率高；
  • 缺点：空轮询浪费（没消息也要定期拉），实时性受轮询间隔影响。

Kafka 纯拉；RocketMQ 的 DefaultMQPushConsumer = 长轮询 Pull：消费者发起拉请求，broker 没消息就 hold 住请求（默认 15s，ConsumerPullResult 挂起），有消息或超时才响应——拿到推的实时性，保住拉的可控性，这是推拉折中的教科书设计，答到这层基本就是加分项。

我的实践：需要应用侧精细控制消费速率（比如下游 DB 能力有限）时直接用 DefaultMQPullConsumer + 自己的限速器；一般场景用长轮询的"push"封装即可。