播面 RocketMQ 的 Push 模式和 Pull 模式的区别
在 RocketMQ 中，消费者（Consumer）获取消息的方式主要有两种：Push 模式（推模式）和 Pull 模式（拉模式）。
虽然从 API 层面看它们是完全不同的两种开发模式，但在底层实现上，RocketMQ 的 Push 模式实际上也是基于 Pull 模式封装而成的（使用“长轮询”机制）。
以下是两者的核心区别、工作原理以及适用场景的详细对比：
1. Push 模式（DefaultMQPushConsumer）
工作原理：
在 Push 模式下，开发者只需要注册一个消息监听器（MessageListener），当有新消息到达时，RocketMQ 会自动回调这个监听器的 consumeMessage 方法。从开发者的视角来看，就像是 Broker 把消息“主动推”给了消费者。
底层真相（长轮询）：
RocketMQ 的 Push 并不是真正的 Server 主动推送，而是 Consumer 内部有一个后台线程主动发起 Pull 请求。
- 如果没有新消息，Broker 不会立即返回空结果，而是会将这个请求“挂起（Hold）”一段时间（默认最多 15 秒）。
- 在这 15 秒内，如果 Broker 收到了新消息，会立刻将消息返回给 Consumer。
- 这种机制叫长轮询（Long-Polling），它既保证了消息的实时性，又避免了频繁拉取造成的网络和 CPU 浪费。
特点：
- 极简易用： 开发者无需关心拉取逻辑、队列（MessageQueue）遍历、消费进度（Offset）提交等底层细节，RocketMQ 全部代劳。
- 自动流控： Consumer 内部会根据本地缓存的消息数量和内存占用大小自动进行流量控制，防止压垮业务系统。
- 实时性高： 得益于长轮询机制，消息延迟通常在毫秒级。
2. Pull 模式（DefaultLitePullConsumer / 老版本 DefaultMQPullConsumer）
工作原理：
在 Pull 模式下，消费者需要主动调用 API（如 poll()）去 Broker 拉取消息。开发者需要自己决定“什么时候拉取”、“从哪个队列拉取”、“拉取多少条消息”。
特点：
- 高度灵活： 开发者可以完全掌控拉取消息的频率、批次大小，甚至可以指定从特定队列的特定 Offset 开始拉取。
- 管理复杂： 开发者需要自己维护消费进度（Offset）（虽然最新的 LitePullConsumer 提供了自动提交 Offset 的功能，但在复杂的定制场景下仍需手动管理）。
- 需自行流控： 如果拉取过快而消费过慢，会导致本地内存溢出；如果拉取过慢，又会导致消息积压。开发者需要自己写代码来平衡拉取和消费的速度。
3. 核心区别对比表
| 维度 | Push 模式 | Pull 模式 |
|---|---|---|
| API 视角 | 注册监听器，被动接收回调 | 主动调用 poll() 或 pull() 方法 |
| 底层机制 | 长轮询（Long-Polling）封装的 Pull | 纯粹的客户端主动 Pull |
| 开发复杂度 | 极低（框架包揽了所有脏活累活） | 高（需自行处理队列遍历、流控等） |
| 消费进度(Offset)管理 | 框架自动周期性提交，开发者无感知 | 可手动提交，也可自动提交，粒度更细 |
| 负载均衡 | 框架自动处理（Rebalance） | LitePull 支持自动；老 Pull 需纯手动计算 |
| 实时性 | 极高（毫秒级响应） | 取决于开发者编写的拉取间隔 |
| 灵活性 | 较低（按框架规则消费） | 极高（可随意回溯、跳跃、指定队列） |
4. 为什么 RocketMQ 倾向于让大家使用 Push 模式？
如果是纯粹的 Server 端推（Push）模式，最大的缺点是Server 端不知道 Client 端的消费能力。如果无脑推送，很容易把消费者撑爆（导致 OOM 或系统崩溃）。
RocketMQ 巧妙地使用 Pull + 长轮询 实现了 Push 模式，既让开发者享受到了 Push 模式的简便和高实时性，又利用 Pull 模式的本质，让消费者可以根据自己的处理能力去向 Broker 拉取消息，天然实现了完美的流量削峰填谷。
5. 选型建议（什么时候用哪个？）
使用 Push 模式的场景（95% 的业务场景）：
- 微服务之间的异步解耦。
- 常规的订单处理、发送短信/邮件通知。
- 不需要精细控制底层队列和消费位点的绝大部分业务系统。
- 一句话：只要没有特殊需求，无脑选 Push 模式。
使用 Pull 模式的场景（5% 的特殊/底层场景）：
- 大数据流计算框架集成： 例如 Spark Streaming、Flink 消费 RocketMQ 数据时，往往需要精准控制到每个分区（Queue）的 Offset，以保证 Exactly-Once 语义，这时必须用 Pull 模式。
- 严格的批量处理： 需要积攒到一定数量的消息，或者在特定的时间窗口内才进行拉取和处理。
- 特殊的重试与死信逻辑： 业务上需要绕过 RocketMQ 默认的重试机制，进行极其复杂的定制化消费进度管理。