但凡接手过IM系统的同学都绕不开“消息收发流程方案选型”这道坎。选型选得好后面开发顺风顺水选型选错了改起来就是伤筋动骨。市面上聊IM的文章很多但大多停留在“高并发IM”“消息推送”这种概念层面真正把一条消息从发送端走到接收端这个过程掰开了讲清楚并且告诉你怎么在不同场景下做取舍的内容其实并不多。这篇文章我想从我自己实际带团队做IM项目的经验出发把消息收发流程里最关键的几个决策点、技术细节和踩坑记录完整讲一遍。无论你是在调研自研IM、准备集成第三方SDK还是纯粹想弄清楚网页版IM这种成熟产品背后的设计逻辑这篇内容都能给你一个相对清晰的选型参考。我尽量不堆术语遇到绕不开的概念会用生活里的类比去解释也会把一些参数和配置直接列出来方便你照着评估。1. 消息收发流程的整体设计与方案选型思路1.1 为什么先要捋清楚消息收发流程再做选型我见过不少团队上来就纠结用哪个框架、哪个中间件、哪个云厂商结果聊了半天发现连自己要做的是“单聊为主”还是“群聊为主”都没定下来。说实话IM系统最核心的复杂度根本不在于某个具体组件而在于消息从A端发出最终如何可靠、有序、低延迟地到达B端这条链路上的每个环节。消息收发流程往大了说无非就是发送端→接入层→消息处理服务→存储层→推送通道→接收端。但这条链路里的任何一环出了问题表现到用户侧就是“消息发了没收到”“消息重复了”“消息乱序了”“离线消息丢了”这些非常伤体验的问题。方案选型本质上是在为这条链路里每个环节选择最合适的处理方式而不是单纯挑一个“听起来很厉害”的技术栈。所以我建议所有刚启动IM项目的团队第一件事不是写代码而是把下面这份问题清单逐项过一遍用户规模预期是多少是几百人的内部工具还是百万日活的公网产品消息是单聊为主还是群聊为主群规模上限是多少人在线率和离线率大概什么比例有多少消息需要走离线存储对消息丢失的容忍度有多高哪些消息绝对不能丢对消息顺序的约束是全局严格有序还是只需要会话内有序团队有多少人可以投入开发有充裕的时间做底层自研吗是否需要多端同步Web、App、桌面端这些问题的答案会直接决定你在“自研IM”和“接入第三方”之间的倾向也会决定你在长连接方案、消息存储方案、离线消息处理方案上的具体取舍。1.2 一条消息从发出到被看到的完整链路把IM的消息收发流程简化以后几乎所有方案都逃不开下面这条链路发送端→接入网关→消息处理服务→消息存储→推送/拉取模块→接收端发送端用户敲完消息点击发送客户端先把消息写入本地数据库同时生成一个本地的临时消息ID通常叫clientMsgId然后通过长连接WebSocket或自研TCP协议把消息上行到服务端。接入网关负责维持海量客户端的连接处理连接鉴权、心跳、断线重连、流量控制。网关一般不处理业务逻辑只做协议解析和转发这样才能做到无状态水平扩展。消息处理服务拿到上行消息后先校验发送者权限、做内容安全过滤然后生成服务端消息ID写入存储再决定走“实时推送”还是“离线存储”的分支。消息存储一般分两部分一份是发送者和接收者的会话消息记录用于历史消息拉取一份是在线/离线状态索引用于判断消息要不要走推送。推送/拉取模块接收端在线时通过长连接实时下行推送消息接收端离线时把消息存入离线消息表等接收端下次上线时通过增量拉取同步下来。看到这里你应该能理解为什么“方案选型”会被单独拿出来当成一个话题来聊。因为这条链路上每一个环节都有多种技术实现路径不同路径组合起来就是一套完全不同的系统形态。比如接入网关用Netty手写长连接还是直接用WebSocket网关组件消息存储用MySQL还是NoSQL离线消息用推拉结合还是纯拉取群聊用写扩散还是读扩散——这些都是选型点。1.3 方案选型的三个关键分流点在线/离线、单聊/群聊、可靠性等级在我做过的IM项目里有三个分流点决定了80%的技术选型走向建议你在选型前先把这三个问题定下来。第一个分流点收到消息时接收方在线还是离线。在线和离线的处理逻辑完全不同。在线用户适合“推送优先”服务端直接把消息通过长连接怼给客户端客户端收到后回ACK链路短、时效性好。离线用户则必须把消息落库等用户上线时再拉取。如果你的产品是典型的“在线协同工具”在线率高那你可以把重心放在长连接推送的稳定性和可靠性上如果你的产品像邮件一样“离线为主”那消息存储和拉取策略反而更重要。第二个分流点消息是单聊还是群聊群聊规模上限是多少。单聊消息的处理很简单一条消息只涉及两个用户写一份存储、推送一次就够了。但群聊尤其是人数在几百上千的千人大群处理逻辑会完全不一样。这里面有一个经典的“写扩散”和“读扩散”之争后面我会单独展开。选型时一定要明确群的上限规模因为它直接决定了你消息表的存储模型和推送扇出量。第三个分流点对可靠性和时序的要求等级。IM和日志系统不太一样它对消息的可靠性要求很高。我不能接受“这条消息丢了算了”这种设计思路因为用户聊天记录丢了产品口碑直接崩塌。但可靠性也有分级私聊消息必须零丢失、强顺序群聊的普通消息可以允许轻微的延迟抖动但也不能丢像系统通知这类消息偶尔重发一次用户也不会太在意。不同可靠性等级会直接影响消息确认ACK、重试、幂等机制的设计复杂度所以这也是选型前必须想清楚的事。2. 消息收发流程中的核心细节与关键技术点2.1 消息模型设计消息ID、时序与去重消息模型是整个IM的“地基”地基没打牢后面整个流程都会受影响。我在项目里踩过最典型的坑就是把消息ID设计和业务需求割裂开导致排障时非常痛苦。一套合理的消息模型通常要包含几个关键字段msg_id服务端生成的全局限一消息ID用于消息在整个系统中的唯一标识。client_msg_id客户端生成的消息ID一般用UUID用于客户端幂等去重。session_id会话ID标识这条消息属于哪个单聊或群聊会话。sender_id/receiver_id发送者与接收者标识。msg_type文本、图片、语音、文件、系统消息等。content消息体内容。status消息状态如正常、撤回、被删除。send_time/server_time客户端发送时间和服务端接收时间。消息ID的生成方案我建议用Snowflake算法或者改造版的分段发号器。Snowflake的核心思想是用“时间戳机器ID序列号”拼出一个64位的整数ID全局趋势递增且不依赖中心化数据库非常适合IM这种需要高并发生成分布式ID的场景。在我实际项目里消息ID生成还承担了一个非常重要的职责作为消息排序的依据。所以服务端生成消息ID时必须保证同一个会话内的消息ID顺序与用户发送顺序一致。如果我们用Snowflake就要注意一个细节在同一毫秒内序列号是递增的能满足同一发送端的顺序但不同发送者在同一毫秒发到不同接入网关时后到达的消息可能拿到更小的ID导致群聊消息乱序。这个问题可以通过在消息处理服务里引入会话级串行化来解决后面我会讲到。2.2 在线通道长连接推送与消息确认在线消息的核心通道是长连接。现在Web端的主流方案就是WebSocketApp端一般用自研的TCP私有协议或者直接在TCP之上跑WebSocket协议。选型时不用过度纠结协议本身的优劣更重要的是想清楚长连接上要承载哪些机制。长连接上必须承载的几件事心跳机制客户端和服务端需要定时互发心跳包保证连接不被中间网络设备断开同时让服务端能感知客户端是否还在线。心跳间隔一般建议15秒到30秒之间太频繁耗电耗流量太稀疏又会导致服务端释放连接不及时。上行消息客户端发送消息时沿长连接发一个上行包服务端处理后返回一个“收到确认”。下行推送服务端往接收端下行推送消息时需要携带服务端消息ID接收端成功落库后返回ACK。推送回执接收端对下行的每一条消息都需要回ACK服务端收到ACK后这条消息才算真正投递成功。这就有意思了。很多人以为“服务端把消息发出去了”就是投递成功实际上服务端必须等接收端回ACK后才能确认。在我带项目时我会明确告诉团队成员ACK是消息可靠性的基石没有ACK机制的消息推送本质上就是发完不管的UDP。这也是为什么在线消息的流程总是比想象中要复杂一点——一条消息要先经过“上行确认”再经过“下行确认”两次确认缺一不可。2.3 离线消息如何“不丢不重不乱”离线消息的处理逻辑核心就一句话把该存的消息存下来等用户上线时再拉给TA。但这句话落地没那么简单。离线消息通常按“用户维度”存储。比如A给B发了一条消息B离线了服务端会往B的离线消息表里插入一条记录。B上线时客户端会带着自己本地最新的消息ID增量拉取服务端把B离线期间积累的所有消息按时间顺序吐给B。这就是“离线拉取”模型。实现“不丢不重不乱”需要三块配合不丢离线消息必须持久化到可靠存储不能只放内存。可以使用MySQL或者Redis落库双写但关键点是消息一旦确认写入离线存储就要考虑是否需要补偿机制防止写入失败。不重客户端拉取离线消息时如果网络超时重试了一次可能同一批消息被拉了两遍。解决方法是客户端本地维护一个last_pulled_msg_id用幂等方式处理重复消息——本地收到了重复的msg_id直接跳过。不乱离线消息拉取必须按消息ID严格排序这里又回到消息ID设计的问题上。如果消息ID不是趋势递增的离线拉取排序就会很头疼。离线消息还有一个细节容易被忽略离线消息的保留期。有些IM产品只保留最近30天的离线消息超过30天直接丢弃让用户登录后从云端历史消息里拉取。这种策略可以在不牺牲体验的前提下控制离线表的膨胀我觉得非常实用。2.4 群聊消息的写扩散与读扩散之争群聊是IM里最能体现技术深度的地方尤其当群人数上千以后消息收发的流程设计会直接决定系统能不能撑得住。群聊有两种经典的消息分发模型写扩散发送时扩散一条群消息发到服务端后服务端把这条消息复制N份分别写入群里每个成员的收件箱。好处是接收端拉取时逻辑简单查询效率高坏处是群越大写入放大越恐怖。一个1000人的群一条消息要写1000份如果一个群很活跃存储量和写入压力会直线上升。读扩散接收时扩散群消息只存储一份挂在群会话下。群成员上线拉消息时再去群会话里同步属于自己那条时间线之后的消息。好处是写入量小群里几千人大几百人缓存无压力坏处是接收端逻辑复杂需要知道“上次同步到哪了”而且全量拉取场景比如新用户进群可能出现性能瓶颈。在实际选型时我一般建议这样权衡群人数 ≤ 200可以直接考虑写扩散因为实现和排查最简单用户体验好。群人数 200 ~ 2000写扩散容易放大写压力但也不是不能用关键看群的活跃度。可以在写扩散基础上做“活跃成员才写收件箱非活跃成员读扩散”的混合模式。群人数 2000建议认真考虑读扩散且配合Redis缓存群时间线尽量让拉取命中缓存而不是打存储。这里我想到一个生活化的类比。写扩散相当于你发一条微信到群里群主把消息挨个私发给每个人确保大家都能收到读扩散相当于你发一条公告到公告栏谁想看谁就走到公告栏前自己看。前者的体验好但跑腿多后者的跑腿少但对看公告的人有要求。2.5 消息可靠性ACK、重试与幂等的组合拳聊透了在线推送和离线存储可以进入消息可靠性这个话题了。我在给团队做方案评审时经常挂在嘴边的一句话是消息不可靠的根源往往不是某一个环节挂了而是各个环节之间缺少配合。一条消息从发送端到接收端可能在任何一环丢失。客户端上行时网络断了服务端处理时宕机了推送时连接断了接收端回ACK时原连接断了。每一环都可能出问题所以可靠性不是靠某一个“保险”就能保证的必须靠ACK、重试、幂等的组合拳上行阶段客户端发消息后如果一段时间内没收到服务端的确认就自动重发但重发时要带上相同的client_msg_id这样服务端能识别出“这条消息我处理过了”直接返回上一次的确认避免重复入库。下行阶段服务端推送消息给接收端后接收端要回ACK。如果服务端没收到ACK会走一个定时重推逻辑但重推不能无休止地进行下去一般有最大次数和衰减策略。幂等客户端本地要有按msg_id去重的机制保证同样的消息即便被推送多次界面上也只显示一条。服务端写入时也要做幂等比如通过唯一索引约束client_msg_id防止重试导致的重复写入。这里我想额外提醒一个容易忽略的点ACK本身的丢失也是一种正常现象不要把它当成异常去报警。我在初期做可靠性模块时一度把“推送了消息但没收回ACK”全部列为异常结果每天晚上被误报警淹没。实际上客户端可能只是切换到后台被系统冻结了等下次打开App才会补ACK。正确的做法是ACK超时重推容忍延迟而不是立刻认定为故障。3. 不同场景下的方案选型对比3.1 自研IM vs 集成第三方SDK成本、周期与掌控力每次聊到IM方案选型团队里都绕不开“到底要不要自研”这个问题。说实话这个决策没有标准答案取决于你的团队规模、业务属性和产品定位。自研IM的优势非常明显完全可控。消息收发流程的每一个细节都掌握在自己手里想做消息双删、自定义表情、特殊消息类型、深度性能优化都没有障碍。长期来看自研IM不会产生按量计费的成本规模大了以后边际成本更低。但自研IM的代价也很真实开发周期长技术栈要求高。一个能稳定运行的消息收发系统至少需要长连接服务、消息存储、离线同步、多端一致性、消息可靠投递这些模块团队里如果没有几个精通网络编程和分布式系统的同学很容易在上线后被各种偶发问题搞得焦头烂额。集成第三方IM SDK或直接使用成熟的IM产品比如海狸IM这类专门做IM服务的产品或者类似CSDN盒子提供的网页版IM能力最大的好处就是开箱即用。登录、消息收发、群组、离线消息、多端同步这些能力直接调接口就行团队可以把精力全部放在自己的业务逻辑上。我的建议是画一条线来判断如果你的IM只是业务里的一个辅助模块不是核心竞争壁垒直接接成熟方案不要再自己重复造轮子。如果IM本身就是你的核心产品且你对数据隐私、定制化体验有极高的要求那就要认认真真考虑自研否则业务发展到后期第三方方案的限制会成为天花板。3.2 高并发IM场景下的选型要点“高并发im”这个词几乎快被聊烂了但很多人聊的是“怎么堆机器”而不是“怎么设计消息收发流程以支撑高并发”。实际上高并发对消息收发流程的影响主要在三个环节。第一环是接入层。高并发意味着海量长连接同时挂载。方案选型时要重点考虑网关服务能不能横向扩展客户端重连时能不能负载均衡到不同网关节点同时保证消息不错乱分布式网关的会话信息怎么同步我一般建议把网关设计成无状态服务会话数据放在Redis或者内存网格里这样网关扩缩容都很容易。第二环是消息处理服务。高并发下消息处理服务必须支持多实例部署但这里有一个冲突点同一会话内的消息必须有序处理。我在项目里的做法是按session_id对消息做一致性哈希把同一个会话的消息路由到固定的处理实例上这样既实现了并行处理又能保住会话内的顺序。第三环是存储层。高并发场景下MySQL单表存消息必然扛不住。方案选型时要预先设计好分库分表策略比如按session_id做哈希分表或者按月分表。Redis用来做热点消息缓存和在线状态存储但注意Redis不是可靠存储关键消息还是要落库。我的经验是高并发不是靠某一个“神器”解决的而是靠每一层的横向扩展和合理的路由策略叠加出来的。3.3 网页版IM的选型观察从海狸IM、CSDN盒子这类产品说起网页版IM是很多业务团队会优先考虑的形态因为不需要用户下载App打开浏览器就能聊。做网页版IM方案选型上有两类路径一类是用开源WebSocket框架自己搭服务端另一类是直接集成第三方IM产品像海狸IM这类面向业务场景的IM服务以及CSDN盒子提供的网页版IM组件。自建Web端IM的优势是灵活整个收发流程能被你完全掌控。Web端用WebSocket做长连接自然能复用我之前讲的在线推送、ACK确认、离线拉取那套流程。劣势是Web端的使用环境比App复杂得多浏览器兼容性、移动端网络切换、页面刷新后的连接重建、同账号多标签页互踢这些都是在做方案评估时要充分考虑的。集成第三方网页版IM产品最大价值是把消息收发流程整体外包出去。你不需要关心长连接怎么保活、离线消息怎么存储、多端怎么同步SDK内部已经把这些做完了。如果你对IM不是强依赖深度定制这种方案会用很小的成本达到不错的效果。我在评估这类方案时通常不会只看宣传语而是重点追问几件事消息可靠性怎么样是否支持ACK确认和离线消息补偿历史消息能拉多远数据是否属于我方可以导出吗高并发时有没有限流策略超卖或者扩容怎么收费消息内容是否有合规审查和内容安全能力无论是自建还是集成网页版IM的选型关键都在于拉齐你的业务诉求和方案的真实能力别只看“能收发消息”这个表面。3.4 开源方案与SaaS服务的取舍开源是很多技术团队在IM选型时会考虑的中间路线。用开源的IM框架可以省掉从零开始的巨大工作量同时又能基于源码做二次开发保留一定程度的可掌控性。这里我推荐两个选型方向大家可以根据团队背景来判断如果团队Java技术栈可以关注基于Netty生态的长连接框架自己搭建接入网关和消息处理服务配合MySQL、Redis和MQ完成整套收发流程。这种方式本质上是“半自研”把最复杂的长连接层交给框架业务层自己实现。如果团队希望更快速地落地可以直接选用成熟的IM服务端软件部署后通过API接入自己的业务系统。这种方案省事但要注意开源软件的许可证规范以及社区活跃度和后续维护风险。开源方案的隐含成本很容易被低估导入代码只是第一步后续的部署、监控、bug修复、性能优化全部得自己来。我见过不少团队导入了一套开源IM服务端后连跑通都费了很大的劲因为缺少配套的运维文档和排障经验。所以我的一个经验准则是选择开源方案时尽量选择社区活跃、文档完善、且有一定知名度的项目别用那种只发布过一版就再也没人维护的“死码”。4. 实操一套可落地的选型决策与部署过程4.1 选型决策的评估维度与打分表与其拍脑袋选型不如把选型变成一套可复盘的打分过程。我在实际项目里整理过一张IM方案选型评估表这里分享出来供参考评估维度权重占比自研方案评分第三方产品评分说明业务匹配度25%高中核心业务与IM的耦合程度交付周期15%低高上线速度是否关键长期成本15%中低按量收费 vs 内部投入技术掌控力20%高低深度定制与排障能力可靠性保证15%取决于团队取决于产品必须验证不能盲信生态与维护10%需评估需评估社区/厂商的生命力打分时要注意权重分配一定要根据自己团队的具体情况来定别照搬我的表。比如你的团队完全没有网络编程经验那“技术掌控力”再高的自研方案也很难拿到高分。我的习惯是让开发、产品和运维负责人一起打分打完分后把差距最大的几项拿出来单独讨论这样选型结论才真正站得住脚。4.2 典型消息收发架构部署再往后就是架构部署层面的实操了。我以一个中等规模的Web IM项目为例说一下核心组件的部署组合。接入网关部署2个以上实例对外通过负载均衡暴露WebSocket端口。网关内实现连接管理、心跳超时检测、消息编码解码。建议把网关做成无状态节点节点宕机后客户端能自动重连到其他节点。消息处理服务一组无状态业务服务通过一致性哈希把同一会话的消息分发到同一实例处理。服务内完成消息ID生成、内容过滤、存储写入、推送路由。消息存储MySQL按会话分库分表存历史消息Redis缓存活跃会话的近期消息和在线状态。为了让离线拉取更高效可以加上一层消息索引表用组合索引user_id msg_id去查。消息推送模块作为独立的推送服务订阅消息队列里的下行消息根据在线状态决定是走长连接实时推送还是写离线表。与网关之间通过内部RPC或消息队列通信。消息队列解耦消息处理和消息推送。消息处理服务写入存储成功后把下行推送任务投递到消息队列推送模块消费队列执行推送。这样即使推送模块瞬时吞吐不够消息也不会立刻丢失。这套架构的好处是每一层都能独立扩容故障域隔离清晰。消息处理服务再怎么慢也不会把网关的连接管理拖垮推送模块再怎么重试也不会阻塞消息写入。4.3 核心参数与配置要点部署只是第一步真正能让系统转得稳的是那些很少被写在文档里的参数调优。我挑几个核心配置说下我的落地经验。心跳超时时间建议设置为30秒发送一次心跳如果服务端90秒内没收到任何心跳或业务包就判定连接已死触发资源回收。设置太短会导致移动网络下的频繁重连设置太长又会占用大量无效连接。我之前调试桌面端IM时把超时从90秒提到120秒网络切换场景下的断线率明显下降了。连接最大空闲数单机长连接数是有上限的因为每个连接都要占用文件描述符和内存。一个普通的8核16G节点跑纯WebSocket网关保守估计可以支撑5万到8万并发连接具体要看每连接的消息量和内存占用。你要在选型时对峰值连接数有预估否则到了扩容节点上限时消息收发的体验会断崖式下降。离线消息拉取分页大小用户上线时如果离线期间积累了几百条消息一次性全量拉取会超时。建议默认分页每页50条到100条客户端边拉边展示。另外要配合增量游标msg_id做断点续传避免反复拉取重复数据。重试策略消息推送失败后的重试间隔我习惯采用指数退避第一次1秒、第二次4秒、第三次16秒最多重试5次后转入“待人工介入”状态。不要用固定间隔高频重试否则一个客户端批量离线时服务端重试风暴会把推送通道打爆。5. 常见问题与排查技巧实录5.1 消息丢失从会话连接池到ACK机制的排查消息丢失是IM项目里最让人头疼的问题也是最常被报告的问题。我在带项目时总结了一套排查路径遇到“消息丢了”先别急着怀疑存储按顺序查这几层查发送端客户端发送后有没有收到服务端上行确认如果一直没收到就是上行链路问题优先查接入网关的连接状态。查消息处理服务服务端有没有接到上行消息接到后有没有把消息写入存储这里的日志很容易断层所以消息处理服务每一步都要打日志包括“收到上行”“写入成功”“推送已投递”。查推送模块接收端在线时走推送离线时走拉取。如果消息写入存储成功但接收端一直没收到很大概率是推送模块消费消息队列失败或者重试队列发生了阻塞。查接收端接收端是否把消息成功落库并回ACK有些时候消息其实已经到了客户端但客户端的状态展示有bug用户就误以为“没收到”。排查消息丢失最关键的是全程日志链路要完整。我在项目里会在每条消息上带一个trace_id从上行到下行全程携带这样出现问题时能按trace_id一键串联所有环节的日志。5.2 消息乱序时序约束与分段锁消息乱序在群聊场景里尤其常见。我之前遇到过一个案例群里两人几乎同时发消息结果是后发送的那条先出现在接收端界面上用户立刻就不满意了。乱序的根源在于不同发送端的消息到了服务端后可能被不同的处理实例并发处理导致大号消息ID先被推送。要解决这个问题必须对同一个会话内的消息处理做“串行化”。我在项目里的落地方式是给每个会话维护一把分布式分段锁比如Redis锁或者一致性哈希到单实例处理同一会话的消息必须串行分配消息ID和写入存储。但这里有个性能陷阱如果把“串行化”的范围做得太大高并发场景下某些热门群的吞吐会被卡住。我的优化实践是按session_id拆分成多个分段比如群聊按成员哈希分桶每个桶内有自己的串行序列这样既保证同一个发送者的消息有序又让群消息整体的处理并行度不会太低。5.3 消息重复幂等表与唯一索引消息重复和消息丢失刚好相反但一样伤体验。重复消息最容易出现在网络超时重试的场景下客户端发送时超时了于是重发了一次但其实第一次的消息已经写入了服务端。解决消息重复的核心就是幂等。服务端在写入消息之前先查一下client_msg_id是否已经存在。为了性能我会在Redis里存一个“最近已处理的消息ID集合”同时给数据库加唯一索引兜底。这样即使Redis数据被清了数据库的唯一索引也能拦住重复写入。接收端的重复展示问题则要靠客户端的msg_id去重。客户端收到一条消息后把msg_id放进本地去重集合界面上已经展示过相同的msg_id就直接跳过。这里注意去重集合不能无限膨胀我一般建议只保留最近1000条消息的去重记录更早的由业务逻辑保证。5.4 连接不稳定心跳、重连与增量同步网页版IM和移动端IM都逃不过连接不稳定的问题。网络切换、浏览器休眠、路由器NAT超时都会导致长连接意外断开。很多用户反馈“消息要等一会才能收到”根因往往就是连接已经断了但客户端没感知到服务端也没及时重推。针对这个问题我的落地经验是三件事完善心跳的启停策略页面可见时保持正常心跳页面切后台时停止心跳但保留连接页面恢复可见时立即发一个特殊的Ping包探测连接是否可用不可用就直接重连。重连后做增量补偿客户端重连成功后不能只依赖服务端后续推送而是要主动拉取“断线期间可能漏掉的消息”。具体做法是客户端带上本地最新一条消息的msg_id服务端返回从该ID以后的所有消息这样即使连接断掉期间推送全丢了也能通过增量拉取补回来。多端消息同步依赖增量游标多端登录时每端都要维护独立的同步游标。这个游标不能只存内存必须落本地数据库否则App一杀进程上次同步到哪了就忘了。结尾做了几年IM项目我最大的感受是消息收发流程方案选型这件事最后选的不是某一个“牛”组件而是选一套“适合自己团队和业务”的完整链路。你可能不需要一开始就把离线表分好、把分布式锁做好但你必须在动手前把每一个关键分叉点都过一遍脑子。哪怕今天先用最简单的方案把功能跑通也要为明天的演进留好接口和余地。最后分享一个我自己的实操心得无论是选型调研还是架构落地我都建议先把“消息产线”上每个环节的日志和监控指标搭好再动代码。你多花在这一步上的时间在后面每次排障时会十倍百倍地还给你。毕竟IM这种东西用户嘴上不说心里对消息及时性和可靠性的要求比任何功能点都要苛刻。 IM消息收发流程方案选型：从长连接到离线消息的完整指南
但凡接手过IM系统的同学都绕不开“消息收发流程方案选型”这道坎。选型选得好后面开发顺风顺水选型选错了改起来就是伤筋动骨。市面上聊IM的文章很多但大多停留在“高并发IM”“消息推送”这种概念层面真正把一条消息从发送端走到接收端这个过程掰开了讲清楚并且告诉你怎么在不同场景下做取舍的内容其实并不多。这篇文章我想从我自己实际带团队做IM项目的经验出发把消息收发流程里最关键的几个决策点、技术细节和踩坑记录完整讲一遍。无论你是在调研自研IM、准备集成第三方SDK还是纯粹想弄清楚网页版IM这种成熟产品背后的设计逻辑这篇内容都能给你一个相对清晰的选型参考。我尽量不堆术语遇到绕不开的概念会用生活里的类比去解释也会把一些参数和配置直接列出来方便你照着评估。1. 消息收发流程的整体设计与方案选型思路1.1 为什么先要捋清楚消息收发流程再做选型我见过不少团队上来就纠结用哪个框架、哪个中间件、哪个云厂商结果聊了半天发现连自己要做的是“单聊为主”还是“群聊为主”都没定下来。说实话IM系统最核心的复杂度根本不在于某个具体组件而在于消息从A端发出最终如何可靠、有序、低延迟地到达B端这条链路上的每个环节。消息收发流程往大了说无非就是发送端→接入层→消息处理服务→存储层→推送通道→接收端。但这条链路里的任何一环出了问题表现到用户侧就是“消息发了没收到”“消息重复了”“消息乱序了”“离线消息丢了”这些非常伤体验的问题。方案选型本质上是在为这条链路里每个环节选择最合适的处理方式而不是单纯挑一个“听起来很厉害”的技术栈。所以我建议所有刚启动IM项目的团队第一件事不是写代码而是把下面这份问题清单逐项过一遍用户规模预期是多少是几百人的内部工具还是百万日活的公网产品消息是单聊为主还是群聊为主群规模上限是多少人在线率和离线率大概什么比例有多少消息需要走离线存储对消息丢失的容忍度有多高哪些消息绝对不能丢对消息顺序的约束是全局严格有序还是只需要会话内有序团队有多少人可以投入开发有充裕的时间做底层自研吗是否需要多端同步Web、App、桌面端这些问题的答案会直接决定你在“自研IM”和“接入第三方”之间的倾向也会决定你在长连接方案、消息存储方案、离线消息处理方案上的具体取舍。1.2 一条消息从发出到被看到的完整链路把IM的消息收发流程简化以后几乎所有方案都逃不开下面这条链路发送端→接入网关→消息处理服务→消息存储→推送/拉取模块→接收端发送端用户敲完消息点击发送客户端先把消息写入本地数据库同时生成一个本地的临时消息ID通常叫clientMsgId然后通过长连接WebSocket或自研TCP协议把消息上行到服务端。接入网关负责维持海量客户端的连接处理连接鉴权、心跳、断线重连、流量控制。网关一般不处理业务逻辑只做协议解析和转发这样才能做到无状态水平扩展。消息处理服务拿到上行消息后先校验发送者权限、做内容安全过滤然后生成服务端消息ID写入存储再决定走“实时推送”还是“离线存储”的分支。消息存储一般分两部分一份是发送者和接收者的会话消息记录用于历史消息拉取一份是在线/离线状态索引用于判断消息要不要走推送。推送/拉取模块接收端在线时通过长连接实时下行推送消息接收端离线时把消息存入离线消息表等接收端下次上线时通过增量拉取同步下来。看到这里你应该能理解为什么“方案选型”会被单独拿出来当成一个话题来聊。因为这条链路上每一个环节都有多种技术实现路径不同路径组合起来就是一套完全不同的系统形态。比如接入网关用Netty手写长连接还是直接用WebSocket网关组件消息存储用MySQL还是NoSQL离线消息用推拉结合还是纯拉取群聊用写扩散还是读扩散——这些都是选型点。1.3 方案选型的三个关键分流点在线/离线、单聊/群聊、可靠性等级在我做过的IM项目里有三个分流点决定了80%的技术选型走向建议你在选型前先把这三个问题定下来。第一个分流点收到消息时接收方在线还是离线。在线和离线的处理逻辑完全不同。在线用户适合“推送优先”服务端直接把消息通过长连接怼给客户端客户端收到后回ACK链路短、时效性好。离线用户则必须把消息落库等用户上线时再拉取。如果你的产品是典型的“在线协同工具”在线率高那你可以把重心放在长连接推送的稳定性和可靠性上如果你的产品像邮件一样“离线为主”那消息存储和拉取策略反而更重要。第二个分流点消息是单聊还是群聊群聊规模上限是多少。单聊消息的处理很简单一条消息只涉及两个用户写一份存储、推送一次就够了。但群聊尤其是人数在几百上千的千人大群处理逻辑会完全不一样。这里面有一个经典的“写扩散”和“读扩散”之争后面我会单独展开。选型时一定要明确群的上限规模因为它直接决定了你消息表的存储模型和推送扇出量。第三个分流点对可靠性和时序的要求等级。IM和日志系统不太一样它对消息的可靠性要求很高。我不能接受“这条消息丢了算了”这种设计思路因为用户聊天记录丢了产品口碑直接崩塌。但可靠性也有分级私聊消息必须零丢失、强顺序群聊的普通消息可以允许轻微的延迟抖动但也不能丢像系统通知这类消息偶尔重发一次用户也不会太在意。不同可靠性等级会直接影响消息确认ACK、重试、幂等机制的设计复杂度所以这也是选型前必须想清楚的事。2. 消息收发流程中的核心细节与关键技术点2.1 消息模型设计消息ID、时序与去重消息模型是整个IM的“地基”地基没打牢后面整个流程都会受影响。我在项目里踩过最典型的坑就是把消息ID设计和业务需求割裂开导致排障时非常痛苦。一套合理的消息模型通常要包含几个关键字段msg_id服务端生成的全局限一消息ID用于消息在整个系统中的唯一标识。client_msg_id客户端生成的消息ID一般用UUID用于客户端幂等去重。session_id会话ID标识这条消息属于哪个单聊或群聊会话。sender_id/receiver_id发送者与接收者标识。msg_type文本、图片、语音、文件、系统消息等。content消息体内容。status消息状态如正常、撤回、被删除。send_time/server_time客户端发送时间和服务端接收时间。消息ID的生成方案我建议用Snowflake算法或者改造版的分段发号器。Snowflake的核心思想是用“时间戳机器ID序列号”拼出一个64位的整数ID全局趋势递增且不依赖中心化数据库非常适合IM这种需要高并发生成分布式ID的场景。在我实际项目里消息ID生成还承担了一个非常重要的职责作为消息排序的依据。所以服务端生成消息ID时必须保证同一个会话内的消息ID顺序与用户发送顺序一致。如果我们用Snowflake就要注意一个细节在同一毫秒内序列号是递增的能满足同一发送端的顺序但不同发送者在同一毫秒发到不同接入网关时后到达的消息可能拿到更小的ID导致群聊消息乱序。这个问题可以通过在消息处理服务里引入会话级串行化来解决后面我会讲到。2.2 在线通道长连接推送与消息确认在线消息的核心通道是长连接。现在Web端的主流方案就是WebSocketApp端一般用自研的TCP私有协议或者直接在TCP之上跑WebSocket协议。选型时不用过度纠结协议本身的优劣更重要的是想清楚长连接上要承载哪些机制。长连接上必须承载的几件事心跳机制客户端和服务端需要定时互发心跳包保证连接不被中间网络设备断开同时让服务端能感知客户端是否还在线。心跳间隔一般建议15秒到30秒之间太频繁耗电耗流量太稀疏又会导致服务端释放连接不及时。上行消息客户端发送消息时沿长连接发一个上行包服务端处理后返回一个“收到确认”。下行推送服务端往接收端下行推送消息时需要携带服务端消息ID接收端成功落库后返回ACK。推送回执接收端对下行的每一条消息都需要回ACK服务端收到ACK后这条消息才算真正投递成功。这就有意思了。很多人以为“服务端把消息发出去了”就是投递成功实际上服务端必须等接收端回ACK后才能确认。在我带项目时我会明确告诉团队成员ACK是消息可靠性的基石没有ACK机制的消息推送本质上就是发完不管的UDP。这也是为什么在线消息的流程总是比想象中要复杂一点——一条消息要先经过“上行确认”再经过“下行确认”两次确认缺一不可。2.3 离线消息如何“不丢不重不乱”离线消息的处理逻辑核心就一句话把该存的消息存下来等用户上线时再拉给TA。但这句话落地没那么简单。离线消息通常按“用户维度”存储。比如A给B发了一条消息B离线了服务端会往B的离线消息表里插入一条记录。B上线时客户端会带着自己本地最新的消息ID增量拉取服务端把B离线期间积累的所有消息按时间顺序吐给B。这就是“离线拉取”模型。实现“不丢不重不乱”需要三块配合不丢离线消息必须持久化到可靠存储不能只放内存。可以使用MySQL或者Redis落库双写但关键点是消息一旦确认写入离线存储就要考虑是否需要补偿机制防止写入失败。不重客户端拉取离线消息时如果网络超时重试了一次可能同一批消息被拉了两遍。解决方法是客户端本地维护一个last_pulled_msg_id用幂等方式处理重复消息——本地收到了重复的msg_id直接跳过。不乱离线消息拉取必须按消息ID严格排序这里又回到消息ID设计的问题上。如果消息ID不是趋势递增的离线拉取排序就会很头疼。离线消息还有一个细节容易被忽略离线消息的保留期。有些IM产品只保留最近30天的离线消息超过30天直接丢弃让用户登录后从云端历史消息里拉取。这种策略可以在不牺牲体验的前提下控制离线表的膨胀我觉得非常实用。2.4 群聊消息的写扩散与读扩散之争群聊是IM里最能体现技术深度的地方尤其当群人数上千以后消息收发的流程设计会直接决定系统能不能撑得住。群聊有两种经典的消息分发模型写扩散发送时扩散一条群消息发到服务端后服务端把这条消息复制N份分别写入群里每个成员的收件箱。好处是接收端拉取时逻辑简单查询效率高坏处是群越大写入放大越恐怖。一个1000人的群一条消息要写1000份如果一个群很活跃存储量和写入压力会直线上升。读扩散接收时扩散群消息只存储一份挂在群会话下。群成员上线拉消息时再去群会话里同步属于自己那条时间线之后的消息。好处是写入量小群里几千人大几百人缓存无压力坏处是接收端逻辑复杂需要知道“上次同步到哪了”而且全量拉取场景比如新用户进群可能出现性能瓶颈。在实际选型时我一般建议这样权衡群人数 ≤ 200可以直接考虑写扩散因为实现和排查最简单用户体验好。群人数 200 ~ 2000写扩散容易放大写压力但也不是不能用关键看群的活跃度。可以在写扩散基础上做“活跃成员才写收件箱非活跃成员读扩散”的混合模式。群人数 2000建议认真考虑读扩散且配合Redis缓存群时间线尽量让拉取命中缓存而不是打存储。这里我想到一个生活化的类比。写扩散相当于你发一条微信到群里群主把消息挨个私发给每个人确保大家都能收到读扩散相当于你发一条公告到公告栏谁想看谁就走到公告栏前自己看。前者的体验好但跑腿多后者的跑腿少但对看公告的人有要求。2.5 消息可靠性ACK、重试与幂等的组合拳聊透了在线推送和离线存储可以进入消息可靠性这个话题了。我在给团队做方案评审时经常挂在嘴边的一句话是消息不可靠的根源往往不是某一个环节挂了而是各个环节之间缺少配合。一条消息从发送端到接收端可能在任何一环丢失。客户端上行时网络断了服务端处理时宕机了推送时连接断了接收端回ACK时原连接断了。每一环都可能出问题所以可靠性不是靠某一个“保险”就能保证的必须靠ACK、重试、幂等的组合拳上行阶段客户端发消息后如果一段时间内没收到服务端的确认就自动重发但重发时要带上相同的client_msg_id这样服务端能识别出“这条消息我处理过了”直接返回上一次的确认避免重复入库。下行阶段服务端推送消息给接收端后接收端要回ACK。如果服务端没收到ACK会走一个定时重推逻辑但重推不能无休止地进行下去一般有最大次数和衰减策略。幂等客户端本地要有按msg_id去重的机制保证同样的消息即便被推送多次界面上也只显示一条。服务端写入时也要做幂等比如通过唯一索引约束client_msg_id防止重试导致的重复写入。这里我想额外提醒一个容易忽略的点ACK本身的丢失也是一种正常现象不要把它当成异常去报警。我在初期做可靠性模块时一度把“推送了消息但没收回ACK”全部列为异常结果每天晚上被误报警淹没。实际上客户端可能只是切换到后台被系统冻结了等下次打开App才会补ACK。正确的做法是ACK超时重推容忍延迟而不是立刻认定为故障。3. 不同场景下的方案选型对比3.1 自研IM vs 集成第三方SDK成本、周期与掌控力每次聊到IM方案选型团队里都绕不开“到底要不要自研”这个问题。说实话这个决策没有标准答案取决于你的团队规模、业务属性和产品定位。自研IM的优势非常明显完全可控。消息收发流程的每一个细节都掌握在自己手里想做消息双删、自定义表情、特殊消息类型、深度性能优化都没有障碍。长期来看自研IM不会产生按量计费的成本规模大了以后边际成本更低。但自研IM的代价也很真实开发周期长技术栈要求高。一个能稳定运行的消息收发系统至少需要长连接服务、消息存储、离线同步、多端一致性、消息可靠投递这些模块团队里如果没有几个精通网络编程和分布式系统的同学很容易在上线后被各种偶发问题搞得焦头烂额。集成第三方IM SDK或直接使用成熟的IM产品比如海狸IM这类专门做IM服务的产品或者类似CSDN盒子提供的网页版IM能力最大的好处就是开箱即用。登录、消息收发、群组、离线消息、多端同步这些能力直接调接口就行团队可以把精力全部放在自己的业务逻辑上。我的建议是画一条线来判断如果你的IM只是业务里的一个辅助模块不是核心竞争壁垒直接接成熟方案不要再自己重复造轮子。如果IM本身就是你的核心产品且你对数据隐私、定制化体验有极高的要求那就要认认真真考虑自研否则业务发展到后期第三方方案的限制会成为天花板。3.2 高并发IM场景下的选型要点“高并发im”这个词几乎快被聊烂了但很多人聊的是“怎么堆机器”而不是“怎么设计消息收发流程以支撑高并发”。实际上高并发对消息收发流程的影响主要在三个环节。第一环是接入层。高并发意味着海量长连接同时挂载。方案选型时要重点考虑网关服务能不能横向扩展客户端重连时能不能负载均衡到不同网关节点同时保证消息不错乱分布式网关的会话信息怎么同步我一般建议把网关设计成无状态服务会话数据放在Redis或者内存网格里这样网关扩缩容都很容易。第二环是消息处理服务。高并发下消息处理服务必须支持多实例部署但这里有一个冲突点同一会话内的消息必须有序处理。我在项目里的做法是按session_id对消息做一致性哈希把同一个会话的消息路由到固定的处理实例上这样既实现了并行处理又能保住会话内的顺序。第三环是存储层。高并发场景下MySQL单表存消息必然扛不住。方案选型时要预先设计好分库分表策略比如按session_id做哈希分表或者按月分表。Redis用来做热点消息缓存和在线状态存储但注意Redis不是可靠存储关键消息还是要落库。我的经验是高并发不是靠某一个“神器”解决的而是靠每一层的横向扩展和合理的路由策略叠加出来的。3.3 网页版IM的选型观察从海狸IM、CSDN盒子这类产品说起网页版IM是很多业务团队会优先考虑的形态因为不需要用户下载App打开浏览器就能聊。做网页版IM方案选型上有两类路径一类是用开源WebSocket框架自己搭服务端另一类是直接集成第三方IM产品像海狸IM这类面向业务场景的IM服务以及CSDN盒子提供的网页版IM组件。自建Web端IM的优势是灵活整个收发流程能被你完全掌控。Web端用WebSocket做长连接自然能复用我之前讲的在线推送、ACK确认、离线拉取那套流程。劣势是Web端的使用环境比App复杂得多浏览器兼容性、移动端网络切换、页面刷新后的连接重建、同账号多标签页互踢这些都是在做方案评估时要充分考虑的。集成第三方网页版IM产品最大价值是把消息收发流程整体外包出去。你不需要关心长连接怎么保活、离线消息怎么存储、多端怎么同步SDK内部已经把这些做完了。如果你对IM不是强依赖深度定制这种方案会用很小的成本达到不错的效果。我在评估这类方案时通常不会只看宣传语而是重点追问几件事消息可靠性怎么样是否支持ACK确认和离线消息补偿历史消息能拉多远数据是否属于我方可以导出吗高并发时有没有限流策略超卖或者扩容怎么收费消息内容是否有合规审查和内容安全能力无论是自建还是集成网页版IM的选型关键都在于拉齐你的业务诉求和方案的真实能力别只看“能收发消息”这个表面。3.4 开源方案与SaaS服务的取舍开源是很多技术团队在IM选型时会考虑的中间路线。用开源的IM框架可以省掉从零开始的巨大工作量同时又能基于源码做二次开发保留一定程度的可掌控性。这里我推荐两个选型方向大家可以根据团队背景来判断如果团队Java技术栈可以关注基于Netty生态的长连接框架自己搭建接入网关和消息处理服务配合MySQL、Redis和MQ完成整套收发流程。这种方式本质上是“半自研”把最复杂的长连接层交给框架业务层自己实现。如果团队希望更快速地落地可以直接选用成熟的IM服务端软件部署后通过API接入自己的业务系统。这种方案省事但要注意开源软件的许可证规范以及社区活跃度和后续维护风险。开源方案的隐含成本很容易被低估导入代码只是第一步后续的部署、监控、bug修复、性能优化全部得自己来。我见过不少团队导入了一套开源IM服务端后连跑通都费了很大的劲因为缺少配套的运维文档和排障经验。所以我的一个经验准则是选择开源方案时尽量选择社区活跃、文档完善、且有一定知名度的项目别用那种只发布过一版就再也没人维护的“死码”。4. 实操一套可落地的选型决策与部署过程4.1 选型决策的评估维度与打分表与其拍脑袋选型不如把选型变成一套可复盘的打分过程。我在实际项目里整理过一张IM方案选型评估表这里分享出来供参考评估维度权重占比自研方案评分第三方产品评分说明业务匹配度25%高中核心业务与IM的耦合程度交付周期15%低高上线速度是否关键长期成本15%中低按量收费 vs 内部投入技术掌控力20%高低深度定制与排障能力可靠性保证15%取决于团队取决于产品必须验证不能盲信生态与维护10%需评估需评估社区/厂商的生命力打分时要注意权重分配一定要根据自己团队的具体情况来定别照搬我的表。比如你的团队完全没有网络编程经验那“技术掌控力”再高的自研方案也很难拿到高分。我的习惯是让开发、产品和运维负责人一起打分打完分后把差距最大的几项拿出来单独讨论这样选型结论才真正站得住脚。4.2 典型消息收发架构部署再往后就是架构部署层面的实操了。我以一个中等规模的Web IM项目为例说一下核心组件的部署组合。接入网关部署2个以上实例对外通过负载均衡暴露WebSocket端口。网关内实现连接管理、心跳超时检测、消息编码解码。建议把网关做成无状态节点节点宕机后客户端能自动重连到其他节点。消息处理服务一组无状态业务服务通过一致性哈希把同一会话的消息分发到同一实例处理。服务内完成消息ID生成、内容过滤、存储写入、推送路由。消息存储MySQL按会话分库分表存历史消息Redis缓存活跃会话的近期消息和在线状态。为了让离线拉取更高效可以加上一层消息索引表用组合索引user_id msg_id去查。消息推送模块作为独立的推送服务订阅消息队列里的下行消息根据在线状态决定是走长连接实时推送还是写离线表。与网关之间通过内部RPC或消息队列通信。消息队列解耦消息处理和消息推送。消息处理服务写入存储成功后把下行推送任务投递到消息队列推送模块消费队列执行推送。这样即使推送模块瞬时吞吐不够消息也不会立刻丢失。这套架构的好处是每一层都能独立扩容故障域隔离清晰。消息处理服务再怎么慢也不会把网关的连接管理拖垮推送模块再怎么重试也不会阻塞消息写入。4.3 核心参数与配置要点部署只是第一步真正能让系统转得稳的是那些很少被写在文档里的参数调优。我挑几个核心配置说下我的落地经验。心跳超时时间建议设置为30秒发送一次心跳如果服务端90秒内没收到任何心跳或业务包就判定连接已死触发资源回收。设置太短会导致移动网络下的频繁重连设置太长又会占用大量无效连接。我之前调试桌面端IM时把超时从90秒提到120秒网络切换场景下的断线率明显下降了。连接最大空闲数单机长连接数是有上限的因为每个连接都要占用文件描述符和内存。一个普通的8核16G节点跑纯WebSocket网关保守估计可以支撑5万到8万并发连接具体要看每连接的消息量和内存占用。你要在选型时对峰值连接数有预估否则到了扩容节点上限时消息收发的体验会断崖式下降。离线消息拉取分页大小用户上线时如果离线期间积累了几百条消息一次性全量拉取会超时。建议默认分页每页50条到100条客户端边拉边展示。另外要配合增量游标msg_id做断点续传避免反复拉取重复数据。重试策略消息推送失败后的重试间隔我习惯采用指数退避第一次1秒、第二次4秒、第三次16秒最多重试5次后转入“待人工介入”状态。不要用固定间隔高频重试否则一个客户端批量离线时服务端重试风暴会把推送通道打爆。5. 常见问题与排查技巧实录5.1 消息丢失从会话连接池到ACK机制的排查消息丢失是IM项目里最让人头疼的问题也是最常被报告的问题。我在带项目时总结了一套排查路径遇到“消息丢了”先别急着怀疑存储按顺序查这几层查发送端客户端发送后有没有收到服务端上行确认如果一直没收到就是上行链路问题优先查接入网关的连接状态。查消息处理服务服务端有没有接到上行消息接到后有没有把消息写入存储这里的日志很容易断层所以消息处理服务每一步都要打日志包括“收到上行”“写入成功”“推送已投递”。查推送模块接收端在线时走推送离线时走拉取。如果消息写入存储成功但接收端一直没收到很大概率是推送模块消费消息队列失败或者重试队列发生了阻塞。查接收端接收端是否把消息成功落库并回ACK有些时候消息其实已经到了客户端但客户端的状态展示有bug用户就误以为“没收到”。排查消息丢失最关键的是全程日志链路要完整。我在项目里会在每条消息上带一个trace_id从上行到下行全程携带这样出现问题时能按trace_id一键串联所有环节的日志。5.2 消息乱序时序约束与分段锁消息乱序在群聊场景里尤其常见。我之前遇到过一个案例群里两人几乎同时发消息结果是后发送的那条先出现在接收端界面上用户立刻就不满意了。乱序的根源在于不同发送端的消息到了服务端后可能被不同的处理实例并发处理导致大号消息ID先被推送。要解决这个问题必须对同一个会话内的消息处理做“串行化”。我在项目里的落地方式是给每个会话维护一把分布式分段锁比如Redis锁或者一致性哈希到单实例处理同一会话的消息必须串行分配消息ID和写入存储。但这里有个性能陷阱如果把“串行化”的范围做得太大高并发场景下某些热门群的吞吐会被卡住。我的优化实践是按session_id拆分成多个分段比如群聊按成员哈希分桶每个桶内有自己的串行序列这样既保证同一个发送者的消息有序又让群消息整体的处理并行度不会太低。5.3 消息重复幂等表与唯一索引消息重复和消息丢失刚好相反但一样伤体验。重复消息最容易出现在网络超时重试的场景下客户端发送时超时了于是重发了一次但其实第一次的消息已经写入了服务端。解决消息重复的核心就是幂等。服务端在写入消息之前先查一下client_msg_id是否已经存在。为了性能我会在Redis里存一个“最近已处理的消息ID集合”同时给数据库加唯一索引兜底。这样即使Redis数据被清了数据库的唯一索引也能拦住重复写入。接收端的重复展示问题则要靠客户端的msg_id去重。客户端收到一条消息后把msg_id放进本地去重集合界面上已经展示过相同的msg_id就直接跳过。这里注意去重集合不能无限膨胀我一般建议只保留最近1000条消息的去重记录更早的由业务逻辑保证。5.4 连接不稳定心跳、重连与增量同步网页版IM和移动端IM都逃不过连接不稳定的问题。网络切换、浏览器休眠、路由器NAT超时都会导致长连接意外断开。很多用户反馈“消息要等一会才能收到”根因往往就是连接已经断了但客户端没感知到服务端也没及时重推。针对这个问题我的落地经验是三件事完善心跳的启停策略页面可见时保持正常心跳页面切后台时停止心跳但保留连接页面恢复可见时立即发一个特殊的Ping包探测连接是否可用不可用就直接重连。重连后做增量补偿客户端重连成功后不能只依赖服务端后续推送而是要主动拉取“断线期间可能漏掉的消息”。具体做法是客户端带上本地最新一条消息的msg_id服务端返回从该ID以后的所有消息这样即使连接断掉期间推送全丢了也能通过增量拉取补回来。多端消息同步依赖增量游标多端登录时每端都要维护独立的同步游标。这个游标不能只存内存必须落本地数据库否则App一杀进程上次同步到哪了就忘了。结尾做了几年IM项目我最大的感受是消息收发流程方案选型这件事最后选的不是某一个“牛”组件而是选一套“适合自己团队和业务”的完整链路。你可能不需要一开始就把离线表分好、把分布式锁做好但你必须在动手前把每一个关键分叉点都过一遍脑子。哪怕今天先用最简单的方案把功能跑通也要为明天的演进留好接口和余地。最后分享一个我自己的实操心得无论是选型调研还是架构落地我都建议先把“消息产线”上每个环节的日志和监控指标搭好再动代码。你多花在这一步上的时间在后面每次排障时会十倍百倍地还给你。毕竟IM这种东西用户嘴上不说心里对消息及时性和可靠性的要求比任何功能点都要苛刻。