场景解剖一：IM 消息系统
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 7 · 亿级场景实战 · 第 39/49 篇 · 🚧 占位待学
上一篇：《故障演练：把事故提前到演练室发生》
下一篇：《场景解剖二：Feed 流》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 7 · 单元 7.1
一、本文要解决的问题
万人群一条消息变 1 万次投递，怎么扛？IM 是亿级消息的「完全体」场景：它同时考扇出（一条变万条）、可靠性（一条都不能少）、顺序（先发先到）与海量连接——前面六个阶段的零件在这里第一次总装。
二、知识点清单
- 消息投递协议：服务端为每个会话维护递增 seq；客户端上报 max seq 拉增量；推（新消息通知）拉（seq 补齐）结合
- 在线状态：连接层维护 uid → 连接映射（路由层），跨接入节点的消息投递经路由转发
- 扇出模型：单聊写扩散一次；群聊写扩散（给每个成员收件箱写一条）vs 读扩散（群消息存一份，成员拉取）的取舍——大群必须读扩散
- 已读回执的量级控制：万人群的已读风暴（万条回执）怎么降级（抽样 / 聚合 / 关闭）
- 消息存储：收件箱（delivered inbox）与发件箱（timeline）的模型；漫游消息的多端同步
- 可靠性链条：服务端落库 → 推送 → 客户端 ack → 离线拉取补齐——每一环的丢失兜底
三、动手实验（学习时必须真跑）
- 实现最小 IM：Netty 接入层 + 消息落库（会话表带 seq）+ 单聊与 100 人群聊
- 实现推拉结合：在线推送 + 断线重连后按 seq 补拉，验证消息不丢不重（幂等）
- 压测千级扇出：一个消息发到 1000 个成员（模拟群聊），测投递延迟分布
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。