企业官网建设流程全解析

但凡接手过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端的主流方案就是WebSocket，App端一般用自研的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方案选型评估表，这里分享出来供参考：

打分时要注意，权重分配一定要根据自己团队的具体情况来定，别照搬我的表。比如你的团队完全没有网络编程经验，那“技术掌控力”再高的自研方案，也很难拿到高分。我的习惯是让开发、产品和运维负责人一起打分，打完分后把差距最大的几项拿出来单独讨论，这样选型结论才真正站得住脚。

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这种东西，用户嘴上不说，心里对消息及时性和可靠性的要求，比任何功能点都要苛刻。