项目实战-微信亿级IM后台系统

打开招聘页面搜「IM 后台」，你会发现要求写得都很客气：熟悉 Netty、了解消息队列、有高并发经验。真进到面试间，问题会变成：一千万人同时在线，你的长连接集群怎么扛？消息发出去对方没收到，你怎么知道丢在哪一环？万人群聊一条消息要写一万次库吗？

这门课针对的正是这个缺口。它不是教你写一个能跑通的聊天 demo——那种东西网上到处都是，单机、几百人在线、消息丢了就当没发生。它要处理的是量级上来之后暴露的问题：连接数、消息可靠性、存储成本、读写扩散、限流熔断。如果你做过 CRUD 业务，想往中间件或基础服务方向转，或者已经在做 IM 相关模块但只会改改业务代码，这门课值得按顺序看一遍。

先搞清楚长连接集群这道坎

IM 和普通 Web 服务的根本差别在于：服务端和客户端之间要保持一条长期活着的连接。单机 Netty 写个 echo 服务不难，难的是几百万条连接分散在几十台机器上时，怎么知道某个用户当前挂在哪台机器上，怎么把消息精准推过去。

课程从 IM 的基础分层讲起，然后落到 Netty 服务集群的架构实战。你需要重点关注的是连接路由、会话保持和网关层的设计取舍。配套练习建议：自己先画一版「用户 A 发消息给用户 B」的完整链路图，标出每一跳的状态存放位置，再对照课程里的方案看差在哪。

消息不丢，是设计出来的，不是测出来的

可靠投递这一块，是 IM 系统里最容易在线上翻车的地方。客户端发了、服务端收了、对方没收到——消息到底丢在哪？是连接断了、ACK 没回、还是写库失败了？

课程里把心跳机制、断线重连、可靠投递放在一起讲，这个组合是对的。心跳决定了你能不能及时发现连接已经死了，重连决定了恢复后能不能补上断档期间的消息，可靠投递则要求链路上每个环节都有确认和重试。看完这一部分，你应该能回答：客户端重连后，怎么保证不重复收到已经收过的消息？服务端在什么情况下可以认为一条消息「已送达」？

离线消息、历史消息：存储方案决定成本

在线消息走内存和长连接，离线消息和历史消息就得落到存储上。这里有两个绕不开的问题：存哪里，存多久，怎么取。

课程专门讲了离线消息服务怎么保证高性能，以及海量历史消息的存储方案，还涉及用 Redis 的哪种数据结构存离线消息更合适。这些选择没有标准答案，但有明确的权衡：用 List 还是用 Hash，直接影响你能不能在用户上线时快速拉取、能不能控制单用户的内存占用。

建议的练法：拿一个真实场景估算——假设日活一千万，平均每人每天 50 条消息，历史消息保留 30 天，算一下需要的存储量和读取 QPS，再想你的方案能不能撑住。

群聊的读扩散与写扩散，是道分水岭

单聊和群聊在架构上完全是两回事。单聊是一对一投递，群聊则要面对「一条消息发给多少人、以什么代价发」的问题。读扩散写扩散的取舍、未读数一致性、万人群聊的设计难点，基本是 IM 面试的高频区。

课程里提到用 Lua 脚本保证未读数一致性，这个点很具体：未读数这种高频读写、又要保证准确的数据，放在哪、怎么加，直接决定了系统会不会在高峰期被自己的计数逻辑拖垮。看完这部分，你应该能说清楚：一个十万人的群，发一条消息，服务端实际做了多少次写操作？

看完之后，拿这几个问题自查

• 用户上线时，服务端怎么找到他的离线消息并推送？推完之后怎么清理？
• 万人群聊里，某个人不在线，消息要不要给他单独存一份？
• 熔断限流加在消息收发的哪一段？限流阈值按什么维度定？
• 朋友圈和大 V 消息收发的架构差异，本质原因是什么？

如果这几个问题你能给出有取舍、有数字支撑的回答，说明这门课的核心内容你吃透了。如果只能说出名词，建议回去把对应的实战章节再过一遍。缺什么补什么，别假装什么都会——面试官和线上故障都不会配合你演。