消息队列到底该用推（Push）还是拉（Pull）？一文吃透两种模式！
大约 4 分钟
消息队列到底该用推（Push）还是拉（Pull）？一文吃透两种模式！
为什么这个问题很重要？
面试官问这个问题，其实是想考我们两个核心能力：
- 对消息消费流程是否熟悉？
- 能否根据业务需求选择合适的方式？
但很多人回答都是一句话：“Kafka 用拉，RabbitMQ 用推”，没有深入细节、没有类比解释、没有系统思考。
本篇我们从 0 到 1，搞清楚以下问题：
- 推模式 vs 拉模式到底差在哪？
- 各有什么优缺点？
- 哪些场景适合推？哪些适合拉？
- Kafka、RabbitMQ 等主流 MQ 怎么选的？
- 实战中如何设计出一个可控的消费流程？
类比理解：吃饭模式帮我们快速理解
- 推模式（Push）：餐厅服务员把菜端到我们桌子上
- 拉模式（Pull）：我们自己去自助餐取菜
| 模式 | 谁主动？ | 控制节奏 | 容易超载？ | 实时性 |
|---|---|---|---|---|
| 推（Push） | Broker | 消费者无法控制 | 是 | 高 |
| 拉（Pull） | Consumer | 自己控制 | 否 | 低（可调） |
什么是推模式（Push Model）？
推模式中：
- Producer 把消息发给 Broker
- Broker 立即主动将消息投递给 Consumer
- Consumer 必须实现一个“接收回调接口”
优点：
- 实时性强：消息一到即发，适合秒级通知
- 代码简单：消费者只需要订阅一次，不需要轮询
缺点：
- 容易压垮消费者：Broker 不知道消费能力，一股脑推送
- 难以限流：无法很好做 backpressure（回压）
- 网络拥堵时会有丢失风险
实际案例：
- RabbitMQ 默认使用推模式，通过回调函数
handleMessage()处理推过来的消息
什么是拉模式（Pull Model）？
拉模式中：
- Consumer 定期向 Broker 发起“拉取请求”
- 可以指定“拉多少条”“多久拉一次”
优点：
- 可控节奏：消费者主动控制拉取频率，不会被压爆
- 适合批量消费：每次拉 N 条统一处理，性能好
- 更容易实现限流、失败重试
缺点：
- 可能有延迟：比如我们 1s 拉一次，那最多可能延迟 1 秒才收到消息
- 实现复杂度稍高：需要维护拉取状态、偏移量等信息
实际案例：
- Kafka、RocketMQ 都使用拉模式
哪些场景选哪种模式？
| 场景 | 推荐模式 | 理由 |
|---|---|---|
| 秒级通知（发短信、推送） | 推 | 实时性强 |
| 流量控制 / 复杂业务逻辑处理 | 拉 | 可控、稳定、易限流 |
| 批量处理 / 日志分析 | 拉 | 一次拉一批，高吞吐 |
| 用户事件监听（RabbitMQ） | 推 | 回调机制简单，易上手 |
| 容灾处理 / 死信队列 | 拉 | 可自己管理消费偏移，更灵活 |
主流 MQ 的实际做法
| MQ产品 | 消费方式 | 说明 |
|---|---|---|
| Kafka | 拉 | consumer.poll() 主动拉取 |
| RocketMQ | 拉 | 客户端模拟 push，实为 poll 拉 |
| RabbitMQ | 推 | 消息直接推送到 Consumer 端回调 |
| Redis Stream | 拉 + 阻塞 | XREAD BLOCK 模拟监听效果 |
实战设计：如何选型 + 如何限流？
如果我们要写一个“支付成功后发短信”模块：
推模式更合适：
- 用户点击支付，立即需要短信提醒
- 用推模式回调接口处理即可，简洁高效
如果我们要写一个“退款批量审核”模块：
拉模式更合适：
- 每小时审核一次退款订单
- 拉取 1000 条消息，批量入库
推模式有哪些隐患？怎么优化？
| 问题 | 解决方案 |
|---|---|
| 消费太慢，消息堆积 | 加入消费速率监控 + 死信队列 |
| 消息投递失败 | 增加 ACK & 重试机制 |
| 消息堆积 OOM | 增加临时缓冲区 + 分区处理 + 限流模块 |
面试时怎么答更稳
消息队列可以使用推（Push）或拉（Pull）两种模式。 推适合实时性强的场景，比如支付通知，但对消费者压力大。拉适合批处理和控制节奏，比如日志处理。Kafka、RocketMQ 用拉模式方便控制节奏和偏移，RabbitMQ 推模式实现简单、适合监听型消费。 如果我们设计一个系统，我们更倾向使用“拉 + 限流 + ACK”这种更稳定的方式。
总结一句话
推模式更快，但难控；拉模式更稳，但复杂。
选择哪种模式不是绝对，要看我们业务“更在意实时性”还是“更在意稳定性”。
工程里的关键补充点
推模式的防护手段
- 消费者要支持限流与并发度控制
- Broker 需要有重试与死信队列
- 回调处理要可重入，避免重复投递造成副作用
拉模式的调度策略
- 拉取批次大小与频率要根据业务耗时动态调整
- 允许阻塞拉取，降低空轮询消耗
- 拉不到消息时的退避策略要有上限
一致性与幂等
- 业务侧要有幂等键，避免重复消费带来的重复写
- offset 提交要与业务处理成功绑定
监控与容量
- 监控堆积、消费延迟、失败率
- 峰值到来前要评估消费者扩容速度