推与拉：长轮询、百万连接的消息投递
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 3 · 异步与消息 · 第 20/49 篇 · 🚧 占位待学
上一篇：《消息堆积治理：十亿条积压怎么办》
下一篇：《MQ 选型：RocketMQ、Kafka 与 RabbitMQ 的分野》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 3 · 单元 3.6
一、本文要解决的问题
IM 消息怎么送到手机上？服务端直接推，需要维护海量长连接与在线状态；客户端定时拉，浪费流量且延迟高。工业界的答案是推拉结合 + 长轮询——连 RocketMQ 的 push 消费者本质都是长轮询 pull，这个模式值得单独吃透。
二、知识点清单
- 纯推模型：服务端主动下发，需要在线状态与连接路由；断线消息怎么办
- 纯拉模型：客户端轮询，间隔与实时性 / 浪费的矛盾
- 长轮询：请求挂起直到有数据或超时，兼顾实时与低浪费——HTTP 与 TCP 两种载体
- RocketMQ push 消费者的本质：Pull 模式封装 + 长轮询 + 消费者线程池，为什么不是真推
- 可靠投递协议：服务端为每个接收方维护递增 seq，客户端带 seq 拉增量，ack 确认后清理——推拉结合的地基
- 在线推 + 离线拉的分工：在线走长连接通道，离线落库等拉取（为阶段 7 IM / 推送场景埋线）
三、动手实验（学习时必须真跑）
- 抓包（tcpdump / Wireshark）观察 RocketMQ 客户端消费时的长轮询行为（请求挂起时间）
- 用 Netty 写最小推送 demo：服务端维持连接，新消息推给在线客户端；客户端断线重连后按 seq 补拉离线消息
- 对比实验：轮询间隔 1s 拉模式 vs 长轮询模式的消息延迟与请求次数
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。