做后端这几年我面过不少团队也被面过不少次。要论哪种面试题最能考察一个工程师的综合功底IM即时通讯面试题绝对排得上号。一个问题“你怎么设计一个IM系统”表面问的是消息发送实际上把网络编程、并发控制、一致性保障、分布式方案全给覆盖了。这篇文章想把我在多次实战和面试复盘里总结的完整思路整理出来给正在准备面试的开发者做个参考也适合那些想把IM底层设计吃透的人。整个内容不追热点不讲虚的只讲面试场上真正会问到的东西以及每个技术方案背后的取舍逻辑。1. IM面试题的核心考察点与整体设计思路1.1 为什么面试官偏爱IM题目IM系统在面试中出现的频率高不是没有原因的。它几乎能把一名后端工程师所有的核心知识点串在一起网络协议、高并发、分布式、数据一致性、消息队列、缓存、数据库设计以及工程落地中的各种权衡取舍。这些问题远多于一个普通CRUD业务也不是单纯背几个技术点能糊弄过去的。更重要的是IM的考察方式非常灵活。面试官可以只问“WebSocket和HTTP的区别”这种基础题也可以一路追问到“群聊消息怎么保证不丢不重不乱序”这种进阶问题甚至可以深入到“离线消息在用户登录后怎么拉取”这种细节层面。你以为自己准备好了WebSocket结果面试官下一个问题就到了消息存储和分库分表完全是不同的知识维度。所以IM面试题真正考察的不是某几个孤立的知识点而是考察你对一个完整技术系统的理解深度和思考方式。面试官想看到的不是你能背出协议字段而是当业务场景变得复杂时你能不能做合理的架构取舍。1.2 IM题目的考察维度全景图从我的总结来看一个完整的IM系统设计题通常绕不开下面这几个维度。先看网络层。这是最基础也是最先问到的部分。核心问题是客户端和服务端之间用什么样的通信方式建立长连接以及连接建立后怎么维持、怎么检测连接是否真的存活、断线了怎么恢复。再看消息可靠性。网络是不可靠的消息可能在传输过程中丢失也可能被重复投递。这一层需要解决“不丢”和“不重”两个问题。消息内容本身可以靠序列号和ACK机制来对账但ACK本身也可能丢所以真正设计的时候需要配合超时重发和去重逻辑。然后是消息顺序性。用户对聊天体验最敏感的就是消息顺序消息必须按照发送的先后顺序展示。但这个顺序怎么定义本身就值得讨论是按服务端接收到的时间算还是按发送方的本地时间算在多设备、多线程、分布式环境下保持全局顺序是一个非常深的话题。接着是存储设计。消息要存吗存多久离线了能不能拉取群聊这种多写场景怎么设计存储这直接牵扯到消息表怎么建、要不要分库分表、缓存怎么用、冷热数据怎么分离。还有推送和在线状态。用户不开App的时候新消息怎么通知到在线状态怎么维护在线状态的变化要不要广播给其他用户最后是一致性问题特别是群聊。已读回执怎么统计撤回和删除操作怎么在多个设备和多个接收方之间同步这种问题没有标准答案考察的是思路。我把考察维度整理成了一份清单面试前可以对着过一遍网络通信选型轮询、长轮询、SSE、WebSocket的选择和理由连接保活心跳机制、心跳超时、重连策略消息可靠性QoS模型、ACK确认、超时重发、消息去重消息顺序性单调递增序列号、服务端时间、多端同步消息存储离线消息、漫游消息、历史消息的分库分表方案群聊设计扩散读、扩散写、写扩散和增量同步在线状态在线表、心跳上报、状态广播、多端在线推送闭环长连接推送与系统推送通道的互补已读回执与应用已读/未读的实现、多人会话的复杂度控制扩展场景万人群、消息撤回、文件消息等拿着这份清单去复习基本能覆盖九成以上的IM面试题。每一维度都要想清楚背后的“为什么”因为面试官几乎一定会追问。1.3 IM题在不同级别面试中的深度差异同样是IM面试题不同级别的岗位考察的深度天差地别。初级岗位的考察集中在对基础知识的掌握上。比如WebSocket的握手过程是什么样的HTTP协议有哪些方法长连接和短连接有什么区别。面试官通常不会要求你设计整个系统而是看你能不能把一个小环节讲清楚比如客户端断网后怎么判断连接失效服务端又怎么感知。中级岗位需要完整的系统设计能力。这个时候面试官就会抛出“设计一个IM系统”这种开放题看你从需求分析到架构选型再到存储设计能不能形成完整的闭环。同时会结合真实的业务场景追问方案的取舍矛盾比如消息可靠性和实时性冲突的时候你选择保哪一个。高级岗位更看重在极端场景下的方案。比如“如果群里有100万人你的方案还成立吗”是典型的压力测试题。这个时候瞬时消息扇出、热群缓存设计、消息通道分片、读写分离这些都是必须能拿得出手的内容。此外还会考察你对既有系统的演进认知比如从单机架构到分布式架构IM系统哪些部分需要重构哪些部分保持不变。明白了这一点你就知道自己应该复习到什么深度而不至于在面试中被一个追问打乱节奏。我见过不少候选人基础题答得不错但在开放设计和追问环节暴露出知识断层非常可惜。2. 网络层与技术选型为什么最终都选WebSocket2.1 即时通信的可选方案横向对比面试中第一个高频问题就是“客户端和服务端之间用什么协议通信”。很多候选人张口就答WebSocket但面试官接着一问“为什么选它而不是轮询或者其他方案”就卡住了。先把各种方案摊开看。传统的HTTP协议是请求-响应模式一次请求拿一次数据。要想实现服务端主动推送一个直觉的思路是让客户端频繁地发起请求也就是短轮询。但短轮询的瓶颈很明显消息的实时性取决于轮询间隔间隔设短了大量请求打到服务端连接开销和带宽浪费非常严重间隔设长了消息又不够即时。于是有了长轮询。客户端发请求后服务端先按住不返回等有新消息了再返回。看上去解决了“服务端主动推送”的问题但长轮询并不是真正的长连接每次请求结束后连接就释放下一次仍要重新发起HTTP请求还是会带来不小的开销。而且中间代理或网关对连接时长有限制长轮询经常被意外断开。SSE是另一种选择服务端可以实时推送文本事件但它只支持服务端到客户端的单向通信消息上行还得另外走一次请求对于聊天这种双向通信的场景明显不够灵活。WebSocket的优势就非常明显了。它是真正的全双工协议一个连接建立后客户端和服务端可以同时收发数据没有任何一方需要主动等待。握手阶段复用HTTP协议借助80/443端口可以直接走网络通道不需要额外开放端口这在网络环境复杂的移动端尤其重要。连接建立后传输的是轻量级二进制帧头部开销比HTTP每次请求带着一堆头字段划算得多。对照下来结论非常清晰在一个实时的双向通信场景里WebSocket几乎是权衡之后的必然选择。把这一步选型的理由讲清楚就是面试中的第一个加分点。2.2 握手过程与协议细节的追问应对选了WebSocket之后面试官还会接着问“WebSocket的握手过程是怎样的”。这是最容易被轻视的一环。一个标准的WebSocket握手本质上是客户端用HTTP协议发起一次带Upgrade头部的GET请求。请求里必须带上几个关键字段Sec-WebSocket-Key是一个随机的经过Base64编码的字符串Sec-WebSocket-Version指定协议版本。服务端收到后会把Sec-WebSocket-Key加上一个固定的魔数字符串做一次SHA-1摘要再Base64编码作为Sec-WebSocket-Accept返回。这个算法过程不需要你背下来但你要能解释清楚为什么握手要用HTTP而连接建立后却能脱离HTTP。握手的目的是在HTTP层面上完成协议升级让双方协商好后面走WebSocket协议。之后的通信就不再走HTTP那种请求-响应模式数据以帧为单位直接在TCP连接上传输。面试还有一个高频追问是“WebSocket和TCP长连接的区别”。WebSocket本身是基于TCP的但它加了自己的帧协议、掩码规则、关闭握手这些机制相当于在TCP之上做了一层面向消息的封装。TCP是流式协议没有消息边界而聊天天然是消息级的所以WebSocket的帧机制恰好解决了这个边界问题。在这个环节一个非常容易丢分的点是说不清为什么客户端发送的帧要做掩码。每个客户端发往服务端的帧都会用一个32位的掩码键做异或处理主要是为了防止代理缓存把WebSocket数据误当作真实请求处理。这个细节很小但答出来会让面试官觉得你真的看过协议细节而不是只背了面经。2.3 心跳保活与断线重连的工程实践连接建立不是终点连接能不能稳定存在才是真正的考验尤其是移动端网络频繁切换的情况下。TCP连接从表象上看是打开的实际可能已经因为网络切换、中间链路故障而死亡。没有一个机制会主动告诉双方连接断了。所以工程上最常见的手段就是应用层心跳。心跳的玩法有好几种。一种是最常见的时间戳版心跳客户端每隔一段时间发送一个ping包服务端如果在超时时间内没有收到任何包就判定连接死亡主动关闭。另一种是消费侧确认的被动心跳也就是说服务端发下去的数据如果在规定时间内没有被确认收到也会判断连接可能有问题但这种通常要和业务确认机制配合使用单纯靠它不可靠。心跳间隔设置需要权衡。间隔太短比如每5秒一次服务端需要处理的心跳包数量非常大一个百万长连接的接入层每秒要处理的心跳包数量非常可观资源消耗是实打实的。间隔太长比如90秒才发一次那么连接死亡后感知的时间就很长用户会有明显的消息延迟。一条在实际项目中验证过相对均衡的方案是客户端每30秒发送一次应用层心跳服务端在90秒内没有收到任何数据就判定连接超时。这里有个很重要的细节心跳不是单独统计的心跳包而是汇总这个连接上所有流量。只要客户端在持续收发消息心跳就可以顺延不需要额外发送空白包。这个“任意包可作为心跳延期”的设计能显著减少无谓的心跳包数量。断线重连的策略同样讲究。应用被杀、网络切换、代理超时各种原因都会导致连接断开。重连不是简单地重新new一个连接就行通常分为两步先做指数退避的重试比如1秒后重连、2秒后、4秒后设置一个最大上限避免在网络恢复前疯狂重试然后要做增量同步重连成功后客户端要把本地收到的消息序列号告诉服务端双方对账把断开期间漏掉的消息补回来。这里放一个非常实用的心得心跳和重连一定要互相配合。我见过很多方案心跳把连接误判断了重连又快速把新连接建起来结果老连接上的服务端推送没有被完全清理掉导致客户端反复收到重复消息。这个问题排查起来相当痛苦设计阶段就要考虑连接断开后服务端推送任务的幂等清理。3. 消息可靠性、幂等与有序性面试中的深水区3.1 不丢消息从发送到送达的完整链路面试官问到“如何保证消息不丢”你一定要从整个链路去回答而不是只说“客户端重发”一句话。一条消息的生命周期大概是这样的客户端A构造消息先写到本地然后通过网络发送到服务端服务端收到后要确认并把消息转交给接收方接收方收到了要再确认。这个过程中任何一个环节都可能出问题客户端发出去了但服务端没收到服务端收到了但确认包在网络上丢失了服务端把消息转交给接收方但接收方已经离线。解决不丢问题的核心思路是层层确认加超时重发。客户端发送完消息后如果在约定时间内没有收到服务端的确认ACK就会判定发送失败然后重新发送。重发会带来一个新问题后面单独讲。服务端在收到消息后不只是回一个ACK更重要的是要做好持久化。有的设计方案是先写存储再回ACK有的则是在内存做缓冲批量刷盘两种方式各有代价。写入磁盘的那一步绝不能省否则服务端一旦重启那些还没来得及转发的消息就全部丢了。这个细节面试时值得展开能有效展示你对可靠性的理解不止于网络层面。接收方离线的处理逻辑也要讲到。服务端如果发现接收方不在线消息要落到离线存储区域等接收方上线后再拉取。这里的拉取方式又有讲究是全量拉取还是按增量拉取需要配合消息序列号来做增量同步。如果接收方在线的场景下服务端转发消息之后还需要等待接收方的ACK只有这条ACK被处理了整个消息的完整投递闭环才算结束。面试官在这个地方有很高的概率追问“如果接收方的ACK一直不来怎么办”。你可以答重传几次然后转入补偿机制把消息转存到离线存储等接收方恢复了本地会话后再通过同步接口把漏掉的消息补回来。只要消息最终进到了某个持久化存储中并且有可枚举的状态追踪不丢就是可保证的。3.2 不重消息幂等机制的承载与实现重发会带来重复消息。消息去了服务端但ACK丢了客户端会重新发一条一模一样的内容服务端如果傻傻地再转发一遍接收方就会看到两条相同的消息。所以消息的去重机制几乎成了IM系统的标配。一个经典的做法是给每条消息一个唯一ID或其变体客户端在构造消息时生成。服务端收到消息后先根据消息ID查一下自己的去重缓存。如果之前已经处理过直接忽略并返回已有的处理结果如果没有就继续往下处理。去重缓存需要考虑淘汰问题不可能无限存通常只保留最近一段时间或最近几万条的消息ID超出范围的旧消息即便重复到达一般也不影响正确性。很多人会忽略一个关键点消息ID不只用于去重它还要参与排序和补拉取。所以设计消息ID的时候不要用简单的随机数最好是单调递增的或者至少在同一会话内是递增的。很多成熟方案会使用“时间戳递增序号”的组合或者直接用全局唯一的雪花ID。雪花ID这类ID不只是唯一还自带时间有序性对实现“按序分页拉取历史消息”非常有用。这块最容易暴露问题的地方是分布式场景。服务端收到消息后落到哪个存储、哪台机器上是分布式的消息ID不需要全局严格递增但同一个会话里的消息顺序必须可比较。所以业务层必须在会话维度维护一个序号。比如每个会话内序号从1开始递增发送方每次新增消息加1服务端最终以这个序号为准来排列消息顺序。这样即使消息走不同的服务端实例、不同的存储分片同一个会话内的相对顺序也可以正确恢复。面试要答到这一步其实已经超越了大多数候选人。大多数人只会说“消息带ID服务端去重”但如果你能继续说“这个ID还要和会话序号配合使用同一个会话内是单调递增的”面试官会觉得你对消息系统有系统性的理解。3.3 消息有序性全局有序还是会话有序聊到有序性首先要区分目标和代价。全局严格有序也就是全世界所有用户的所有消息都排出唯一顺序在分布式系统里是极其昂贵甚至没有必要的。真正有意义的约束是“同一个会话内的消息有序”比如你和某个朋友对话时他发的消息顺序不能乱你和他在群聊里的消息顺序也要在同一个群内保持一致。要保证这个有序性最自然的方案就是在会话维度引入序号。会话内的每条消息都有一个不断递增的序号客户端展示消息时按这个序号排序序号天然携带顺序信息不依赖消息到达的顺序。但这里有个隐藏的难点消息发送者和服务端看到的时间基准不同。客户端A发了两条消息第一条因为网络慢反而后到达服务端。如果服务端按自己的接收顺序赋予序号那么用户看到的顺序就和实际发送顺序不一致。所以一个成熟的方案通常要约定消息是否经过服务端时间重排允许客户端显示“以本地发送时间为准”的轻提示而服务端持久化的顺序则代表最终事实。另外一个非常常见的坑是“消息乱序”和“投递乱序”要分开处理。服务端最终落库的顺序是事实顺序这只是第一层消息在转发给接收方时如果网络延迟不同两个包到达接收方的先后也可能颠倒。客户端不能只靠到达顺序直接渲染收到消息后要先缓冲一下按序号排好序再渲染到界面上。这种“先排序再渲染”的处理是IM客户端开发中难度较高的话题之一也是很多答题者容易漏掉的重要细节。然后是群聊场景带来的特殊挑战。一个群里几百上千号人每个人的上行链路、转发链路、网络情况都不一样同一个会话内的序号如果只由某一个服务端实例维护那么这个实例就成了单点瓶颈。常见的解法是按会话做一致性哈希分发同一个会话的读写都路由到同一组分片节点上这组节点内部再通过主从复制或者存储层的有序字段把序号维护起来。所有节点顺序一致本质上要求持久化层有全局严格有序的支撑复杂度会上去一个量级。这类问题没有标准答案面试官真正想听的是你对复杂度的预估和拆解。先把“会话有序即可不需要全局有序”这个认知讲清楚再说明同一个会话的序号必须由单一权威节点分配再补充这个节点失败时的选主与故障切换方案一套组合拳基本就能应对一二轮追问了。3.4 多端同步一台手机已读另一台怎么感知多端在线是IM的基础能力手机、电脑、平板同时登录。面试官经常用“多端同步已读状态”来考察你对状态一致性的理解这个场景的细节远比想象中多。假设你在手机上读了群里的消息电脑端马上就应该把未读数清掉。要实现这种同步最简单的做法是把已读回执作为一种特殊消息。当你读取消息时客户端针对这个会话发送一个“已读同步”事件服务端把事件扩散到该会话的所有在线设备每个设备收到后就更新本地的已读水位线。电脑、平板收到这个事件后就把会话的未读角标清零。实现上的细节在于已读水位线要持久化到服务端这样新设备登录或者设备短暂离线后拉取状态时才能保持一致。如果只存在本地换台设备登录后已读状态就丢了。已读状态还有一个语义问题在多端同时在线的情况下已读状态是全局统一的还是每个设备独立的大多数IM的选择是全局统一只要任意一端读了其他端都认为是已读。围绕这个统一状态做同步语义简单用户也容易理解。很多人最后才想到这个问题的另一面消息撤回。撤回本质上就是一条反向的控制消息需要携带被撤回消息的ID服务端找到这条消息后下发一个“消息已撤回”的控制帧给所有在线终端同时也要更新存储。如果撤回动作还要判断“这条消息是否已经被很多人读过”那又要引入额外的复杂度。面试中能主动想起“撤回需要配合已读回执”这个联动关系会让你的回答立刻立体起来。4. 联机场景实战群聊、离线消息与已读回执4.1 群聊的两种经典扩散模型群聊是IM面试题里最常被用来拉高讨论深度的场景。核心问题在于一条群消息要同时送达群里几百上千个人如何高效完成一次扩散并保持所有设备的会话状态一致。有两种最经典的模型。第一种叫扩散读群消息只用写一份存在某个存储位置所有用户读取群消息时都从同一个位置读。这个模型的优点是存储成本极低一份消息服务全群人写不放大缺点是读放大严重。群里有500人一个人发消息不代表其他499个人都在线要立刻读如果所有人都实时轮询同一个位置服务端的压力会非常显著。第二种叫扩散写群消息要复制出多份分别写入每个成员的信箱也就是每个成员的会话存储中。这样每个用户登录后只需要拉取自己消息列表里的增量即可读取路径非常轻快。但写放大非常可怕500人群发一条消息就要写499份副本5000人的群就得写4999份。存储成本膨胀得非常快。实际成熟的IM群聊系统往往并不做纯粹的二分选择而是采用混合策略。小群用扩散写消息量小副本数量可控每个用户有完整的独立会话视图离线消息天然就好处理。大群用扩散读因为大群的消息洪峰汹涌写放大成本不可接受改为消息中心存储成员按需拉取配合上用户会话列表里的“群最后一次活跃时间”做增量提示。这种双模型共存的设计才是面试中的高分回答。面试官还经常会追问一个细节“群成员人数变化时方案要不要切换”这是一个很好的话题。比如一个群从100人涨到1000人你原来用扩散写现在副本量是原来的10倍在线用户比例也变了要不要切换一个优雅的回答是可以在群里引入成员分级针对不同规模的群分开用不用模型比如人数低于一个阈值的群用扩散写超过阈值的群改成扩散读。至于那个阈值怎么定可以通过监控写放大和读放大的实际成本来做动态调整。4.2 离线消息的存储与增量拉取设计离线消息这个话题在面试中被问到的概率很高因为真实场景里永远有大量用户不是实时在线的。消息发送时接收方恰好离线消息去了哪里等接收方上线时怎么把消息拉回来最基础的做法是服务端发现接收方不在线就把消息写入离线存储。这个“离线存储”可以简单理解为每个用户的一个消息信箱。用户上线时客户端调用一个“拉取离线消息”的接口把信箱里所有未读消息拿回来。但这个做法有几个问题。第一信箱会无限增长消息一条一条堆积在库里查询性能越来越差。所以通常还要设计一个“离线消息生命周期”策略比如只保留最近30天的离线消息超过期限就合并为一条摘要提示用户可以从历史记录系统拉全文。第二拉取时要考虑分页和增量否则用户离线一个月回来一次性拉几万条消息客户端直接卡死。增量拉取几乎都依赖前面说的会话序号。客户端在本地保存了自己已经接收到的每个会话的最后一条消息序号上线后带着这个水位线去请求服务端“这个会话把序号大于X的增量消息给我”。服务端只需要做好一次范围查询即可。这个“水位线同步”机制非常通用不仅是离线消息在线消息的补拉、多端同步都能复用同一套逻辑。拉取的时候还有个并发细节客户端上线后一般不要全量拉取所有离线消息而是先拉会话列表和每个会话的最近N条消息等用户点进某个会话时再按需拉更早的消息。这种“列表正文分离”的策略既能保证用户可以快速进入会话列表不至于卡在首页又能避免一次拉取过量消息消耗流量和存储。面试时建议把这个过程讲成一个完整的交互顺序。很多候选人只提到“存离线消息”却没有细化拉取协议这其实是不够的。一个面试官追问下支离破碎的回答远远不如一个“水位线增量拉取分页”的完整闭环更有说服力。4.3 已读回执的语义、并发与存储实现已读回执是IM面试题中非常容易踩坑的题目因为“已读”本身有非常多种语义。先定义语义。最简单的语义是“整个会话已读”只要用户进入会话列表点击某个会话会话内所有消息整体标记为已读。这个语义好实现但不够精准。更精确的做法是记录每条消息的已读状态但这样存储量会爆炸一条消息对每个成员就要存一个状态位。还有一种常见做法是“已读水位线”对某个会话记录用户最后已读的消息序号。凡是序号水位线以下的都视为已读水位线以上的全是未读。这个设计非常优雅存储量很小只要每个会话存一个整数值。会话已读和每条消息已读之间通过水位线就可以转换表达。实现时要注意并发。多端同时标记已读或者用户一边收消息一边点已读水位线更新的时候可能出现低优先级覆盖的写入丢失问题。比如手机上把水位线推进到了100电脑端本地还停在水位线5电脑端这时候如果也提交了一下会把100又覆盖回5未读数就出现了莫名回弹。解决的方案是给水位线更新加上校验比如服务端只接受比当前值更大的更新请求。另外要讲清楚的是“已读同步”的消息本身是有序的。已读回执作为一条系统控制消息也要通过会话的递增序号通道下发而不是乱序直接覆盖。否则用户手机上明明已读了某条消息另一个设备上这条消息还在闪烁“未读”体验会非常奇怪。我在面试复盘时发现能答清楚“已读语义的选择”这件事本身就是分水岭。候选人如果直接说“每条消息存个已读状态”基本就是没想过存储成本如果说“会话水位线就够了”这就是有工程经验的表现如果能继续补充“水位线更新必须防并发覆盖”这就是一个完整的面试好答案。5. 在线状态与推送闭环比想象中更难的部分5.1 在线状态的维护与广播策略在线状态在面试中看起来很简单实现起来却有不少细节。最直觉的方案是客户端登录时在在线表里写入一条在线记录退出时删除。但这套模型在移动端完全不成立因为用户往往不是主动退出的可能是网络断了、App被系统杀了你还留着幽灵在线记录。所以在线状态的判定必须与心跳结合。客户端维护长连接和心跳服务端根据心跳的超时与否更新在线状态。长连接存活的期间定为在线超过心跳阈值未收到任何包就把状态改为离线。这个做法的核心依然是一个超时判断所以在线状态的实时性完全取决于心跳间隔和判定阈值。在线状态还要解决“状态变化要不要广播”的问题。最简单的场景是私聊A上线他的好友B应该感知到吗如果有“好友列表显示在线状态”这类功能就需要把A的上线/下线事件推送给所有相关方。这里就引出了复杂度的核心一个用户可能有很多在线关注者每次状态变化都是一次消息扩散写。为了控制浩大的推送量一般会引入一层观察者订阅机制而不是每次全量扫好友。多端在线的引入让“在线”的语义变得更宽。一个用户可能手机在线、电脑在线同一个人的不同设备状态不一样。常见的实现是维护一个用户维度的连接列表只要这个用户至少有一个活跃连接就认为是“在线”如果所有连接都断了才标记为“离线”。具体每个设备是不是在同一时刻存在可以通过设备级别的某个标识来区分。面试中聊到在线状态我建议主动讲一下“幽灵连接”问题。这是移动端开发中非常典型的坑用户关掉手机屏幕系统在后台可能切断了网络但客户端的TCP连接看起来还活着在线状态就是假的。只有依靠心跳超时才能真正判定在线还是离线。把这个想清楚你的在线状态设计就会务实很多。5.2 服务端推送与系统推送通道的互补设计推送闭环几乎是每个IM面试题最后都会触及的部分。用户在后台或者App被杀长连接断了新消息怎么通知正规的做法是双通道互补。当客户端有长连接时消息直接通过长连接下发体验最好延迟最低。当长连接断开时服务端就需要依赖系统级的推送通道来触发用户重新建立连接或者展示通知栏提醒。移动端的系统推送通道是一个很大的话题。其实都面临同一个问题用户不打开App时服务端无法直接派发消息数据只能发一个“来新消息了”的触发通知。App收到通知后要么让用户点了之后重新建立长连接去拉数据要么在通知中附带简单摘要让用户直观看到消息内容。这里有一个关键的工程细节推送通道可以携带的数据大小是有限制的不能什么都往里塞。所以设计推送消息内容时一般只带会话ID、发送人昵称、消息摘要这几个关键字段完整的消息内容要等客户端重建连接后再通过长连接同步拉取。这样既保证通知足够轻量又不会把消息体全部塞进推送通道造成消息堵塞和功能损失。面试中答到“推送”时我建议额外说一句“推送通道主要负责唤醒完整消息应由长连接或增量拉取补齐”。这句话会立刻让你和那些只会说“用推送通道就行”的候选人区别开来因为它体现出了你对通道能力的理解和对整体消息链路的把控。5.3 万人群的实时性挑战与分片实践最后一个高端话题通常是这样抛出的“如果群里有1万人甚至10万人消息还能秒达吗”这不是想让你直接给出一个完美方案而是考察你在极端压力下能不能拆解问题。万人群的核心矛盾是消息的扇出量和连接管理量都巨大。一条消息要推给一万个用户如果走扩散写就写了一万份副本如果走扩散读就要通知一万个用户“快来看新消息”。无论哪种方式都要管理一万个在线连接推送扇出是不可避免的。工程实践里常见的处理思路是把问题拆到多个层次。第一层是接入层用多个接入节点分散维护海量长连接每个连接归属到节点节点之间通过内部通道交换消息。第二层是逻辑层消息先进入存储再触发推送分发使用消息队列来削峰填谷不要让推送洪峰直接打满数据库。第三层是推送扇出层用扇出缓冲防止瞬时大流量打到每个用户连接的节点上。万人群还要考虑“热群效应”。一个活跃的万人群消息峰值可能每秒钟几十甚至上百条这不仅让存储扛不住也让用户的客户端渲染不过来。为了优化体验很多团队会为热群做消息聚合频繁发言的人在短时间内合并成一条消息或者把群消息按时间段分组比如“你有100条未读消息”这样的群摘要。“群摘要式降噪”是面试中很出彩的加分项因为它已经超出了单纯技术方案的维度进入了产品体验的权衡。但同时必须坦诚说明极限情况下的取舍。万人群聊如果真的追求每条消息所有人都秒达那在工程上几乎不可能在通用的公网环境稳定做到。更实际的方案是按需拉取群里实时在线且高频活跃的用户走长连接实时推送离线或静默的用户靠“群状态条手动进入拉取”来消费消息。这种分级消费策略是目前大型群组场景中比较成熟的通用做法。6. 高频追问与答题避坑面试官真正想听什么6.1 复盘那些最容易翻车的回答方式面试官的追问往往是为了检验候选人对刚才回答的理解深度。我发现最容易翻车的回答有以下几种。第一种是“书背型”回答。能复述WebSocket的定义但问到握手字段就支支吾吾知道要心跳但说不清心跳间隔怎么定、超时怎么判。这类回答说明知识点没有内化一旦追问就露馅。第二种是“单点脑暴型”回答。只盯着消息发送链路讲完全不提存储、离线、多端、推送这些闭环场景。面试官一般会在最后引导“如果接收方不在线怎么办”但很多候选人直到这时才想起来离线消息这回事。这说明你的知识面还缺一个系统的全局视角。第三种是“无量化意识”的回答。谈到心跳间隔、离线消息保留周期、群聊扩散阈值时完全给不出任何数字。虽然面试不一定要求精确值但一个优秀的工程师至少要能根据量级给出合理的粗略估计。比如“一个用户一天大约发20条消息一万日活就是20万条消息存储压力不算大”这类估算能展示出良好的工程数字感。复盘时你会发现问题大多出在缺乏一个组织答案的框架。我的经验是准备一个“会话-设备-消息-状态”四元组模型不管面试官问什么问题都从这个模型出发去组织自己的思路。消息对应可靠性设备对应多端与连接会话对应顺序性状态对应在线和已读。这个模型框架非常有效几乎能套用所有IM追问。6.2 如何在回答中自然展现你的工程判断力很多候选人以为面试题拼的是知识点数量实际上拼的是决策链路。面试官问“为什么选WebSocket”你光是数出三个优点是不够的你最好能呈现出“我看到了哪些可选方案各有约束我选择某个方案并对短板做了补偿”的思考轨迹。比如WebSocket的短板是什么没有自动重连机制需要在应用层实现心跳和重试。这就是一个典型的有短板补偿的属性。你可以说“WebSocket虽然全双工实时性好但也给我带来了心跳和断线重连的额外负担所以我在客户端层做了一套可靠的重连策略”。这样一来你不只是回答选型你连业务代码的形态都已经描述了一部分。在线状态的问题也类似。你如果说“用Redis存在线状态”这只是起点。如果你能继续说“状态必须有心跳联动Redis要设置过期时间客户端重连成功后要主动刷新在线状态”那就体现了你对“服务端状态”和“客户端行为”之间联动关系的思考。面试官很吃这一套因为它表明你不只是会设计API你理解你的设计在整个生命周期里怎么被调用、怎么被维护。这是高级工程师和初级工程师之间最常见的鸿沟之一。6.3 一份可复用的IM系统设计答题框架到了这里我想把一份我自己整理、并且在多次面试复盘中被验证有效的高频答题框架分享出来。它不是背出来的答案而是一个可以让你在遇到任何IM题目时都能迅速组织语言、覆盖完整知识面的思维框架。第一步从需求出发。先问清楚这个IM系统的范围是一对一聊天、群聊还是全都要多少人用、多大的群优先实时性还是优先可靠性消息要存多久、要不要多端漫游这些问题直接决定了后续技术方案的方向。没有人会在一开始就推荐一个通用的IM架构这是所有设计题的第一步。第二步网络接入层。选定传输协议通常用WebSocket设计心跳、重连、多端连接管理。重点回答长连接怎么维护、连接断开后怎么办。第三步消息链路层。定义消息ID、会话序号、幂等去重解决不丢不重、顺序性、多端同步这几个核心约束。这是整场面试中的技术核心也是讨论时长占比最大的一环。第四步消息存储层。设计消息表的存储方案区分在线消息、离线消息和历史消息确定增量拉取和分页策略。如果有能力还可以讲一下消息表的分库分表和冷热分离设计。第五步业务能力层。接入在线状态、已读回执、撤回、推送闭环这些高阶能力说明它们如何与前面的链路协作。第六步扩展和容灾。面对万人群、极致延迟、单点故障时怎么做架构调整简单但关键把权衡讲出来不必追求完美。把这六步走完基本就是一个完整的IM系统设计回答。你在面试中不再会被单个追问打乱节奏因为你始终有下一步可以讲。我自己在掌握这套框架后最大的体会是回答时的思路完全不同了因为你知道不管面试官往哪个方向深挖你都有一条完整的逻辑线可以支撑。7. 面试之后的复盘经验和后续提升方向每次面试结束不管结果如何我都会花时间做一次复盘。IM题的答案往往不是对错二分面试官更在意你的思考过程但复盘时应该给自己较真这个环节我的回答为什么卡顿了是知识盲区还是表达不够熟练知识盲区可以靠不断扩展技术视野补。比如你看过WebSocket协议原文就能轻松回答掩码问题做过长连接稳定性治理就能说出心跳延期的细节写过大群消息系统才会在讲扩散写的时候主动提起存储膨胀问题。只有把面试题当成一个真实系统去理解和验证面试回答才能越过背稿的阶段变得像真的做过。表达层面的问题则需要靠模拟练习来修正。我自己的做法是拿一个计时器自己对着白板讲一遍“设计一个IM系统”重点看能不能在有限时间内流畅走完六个步骤而不跑偏。每次练习都录音回放时你会发现很多口头禅和逻辑断点这些都是正式面试中会丢印象分的地方。多练几轮之后整个结构感会越来越强。延伸来看IM系统这道题背后其实反映的是后端工程师的核心能力理解一个复杂系统的全貌并能在约束条件下做出合理的权衡取舍。今天聊到的所有技术点本质上都在用一种方式训练这种能力。应对IM面试题的过程就是一次系统能力训练的过程。如果你正在准备这种面试我的建议是先别急着背答案把上面几个环节的每一层都按照“为什么要这么做”和“代价是什么”的维度去理解一遍。等你能用自己的话把每条链路都解释清楚再去找朋友做模拟拷问。到那个时候你会发现面试题已经不是需要紧张的考试而是一次真正的技术交流。