IM后台核心架构设计：百万长连接与消息收发链路解析

做即时通讯后台，第一件事不是写代码，而是想清楚你到底要做一个什么样规模的系统。这个系列我打算从零开始，把一套能支撑百万长连接的服务端架构拆开来讲。第一篇先解决最核心的问题：技术选型、消息模型、连接层设计，以及消息收发的主链路怎么搭。适合刚接触IM开发的后端工程师，也适合准备自研IM系统、想在选型上少走弯路的团队参考。

1. 内容整体设计与思路拆解

1.1 即时通讯后台到底难在哪

很多人第一次接触IM后台，第一反应是“不就是把消息从A发给B吗”。这个理解没错，但实际做起来，难点全藏在“简单”背后。

先看一组数据。一个用户在线，意味着客户端和服务端之间需要维持一条长连接。假设你有100万在线用户，平均每秒钟产生的消息量可能只有几百条，但服务端需要同时管理的连接数却是100万条。消息量不大，连接管理却极其吃资源。这就是IM系统和其他后端系统的本质区别：它首先是连接密集型系统，然后才是消息处理系统。

再往深一层想。用户A给用户B发消息，这条消息要经过多少环节？客户端A先把消息发到接入层，接入层要做协议解析、鉴权、消息去重，然后路由到消息队列，再由推送层找到用户B当前所在的接入节点，最后通过那条长连接把消息推下去。如果用户B不在线，消息还要落到存储里，等他上线后再拉取。这个链路里任何一个环节出问题，用户体验立刻崩。

所以我在设计整个系统时，第一原则是分层解耦。接入层只管连接和收发，业务层只管道消息逻辑，存储层只负责持久化，层与层之间通过消息队列解耦。这样每一层都能独立扩展，出了故障也容易隔离。

1.2 技术栈选型：为什么是Netty加自研协议

技术选型是第一个要拍板的事。现在市面上可选的路子不少，我理一下自己的选择逻辑。

接入层用Netty，这个基本没有悬念。Java生态里Netty是长连接网络编程的事实标准，性能足够，生态成熟，遇到问题网上一搜一大把解决方案。虽然用Go的gRPC也能做，但Netty在连接管理、内存池、编解码框架上的积累更深，尤其适合IM这类需要大量自定义协议的场景。

消息队列我选了RocketMQ，而不是Kafka。很多人的第一反应是Kafka吞吐量高，但IM场景对吞吐的要求其实没那么极端，反而对消息的可靠性和顺序性更敏感。RocketMQ支持事务消息，可以保证本地事务和消息发送的原子性，这在消息必达的场景下很关键。Kafka更适合日志、埋点这类允许少量丢失的大数据场景。

存储层我采用了分层的方案。在线状态、会话列表这类热数据放Redis，消息内容本身放MySQL，历史消息超过一定时间的冷数据归档到对象存储。这个组合看起来朴素，但每一层都用在刀刃上：Redis扛高并发读，MySQL保证事务和一致性，对象存储解决海量历史消息的成本问题。

连接协议我们没有用现成的WebSocket，而是自研了一套基于TCP的私有协议。原因很简单：WebSocket基于HTTP握手，协议头部开销大，而且对于文件传输、群组信令这类场景扩展起来很别扭。私有协议看起来麻烦，但自由度极高，控制消息和业务消息可以走不同的编解码路径，长连接的二进制压缩也能做得更极致。

提示：如果团队没有足够的网络编程经验，第一步先别自研协议，直接用WebSocket把业务跑通更重要。自研协议是性能优化阶段的动作，不是起步阶段的必需品。

1.3 从标题看这个系列要覆盖的范围

标题里有个“(1)”，说明这是一个系列文章。我规划了整个系列的内容脉络，第一篇聚焦最基础也最容易被忽视的部分：整体架构设计和核心链路搭建。

具体来说，第一篇重点覆盖四块：消息模型的设计、连接层与在线状态管理、消息收发主流程、常见问题排查。这四块是一套IM后台的骨架，后续系列文章再往里填肉，比如群聊扩散、消息漫游、文件传输、多端同步、消息已读回执、推送通道优化等等。

这个顺序是有讲究的。消息模型决定了一切上层逻辑怎么写，连接层决定了系统能承载多少在线用户，主流程决定了消息能不能最终送达。骨架不对，后面再填多少肉都是歪的。所以我建议读者跟着这个节奏来，先把这一篇吃透，再去追后面的文章。

2. 核心细节解析与实操要点

2.1 消息模型：单聊、群聊、系统消息的差异

消息模型是IM系统的地基，设计得好不好，直接决定后续业务开发的复杂度。我把消息分成三大类：单聊消息、群聊消息、系统通知。

单聊消息是最简单的模型。消息有一个唯一的from用户和一个唯一的to用户。这里有个坑：很多人在设计表结构时，会想着用一个session_id把双方的会话关联起来，减少查询条件。这个思路对了一半——session_id确实能加速会话列表查询，但注意不要用它作为消息的唯一归属维度，因为同一对用户之间可以有多端设备，消息的可见性需要按设备和时间来决定。

群聊消息比单聊复杂一个量级。一条群消息发出去，理论上有N个接收者，但存储上绝对不应该存N份。我采取的方案是消息存一份，扩散的是扩散表里的条目。也就是说，消息内容表里只有一条记录，但群里每个成员都在message_relate_user表里有一条记录，指向这条消息。这样可以方便地做“某人是否已读”“某人是否删除了这条消息”这类逻辑。

系统消息则要绕过会话模型，直接走独立的通知通道。我单独建了一张notice表，同时用一个独立的Redis队列做实时推送。因为系统消息往往是平台级触达，量级可能很大，和普通聊天消息混在一起存储，会影响主消息表的查询性能。

2.2 消息ID生成：不要用数据库自增

消息ID这事，看着不起眼，踩坑的人却最多。如果用MySQL自增ID，在分布式环境下基本没法用：多个接入节点同时落库，生成的ID全局不唯一，而且无法保证时间有序。

我用的方案是雪花算法（Snowflake）生成64位长整型ID。ID的构成是：1位符号位 + 41位毫秒时间戳 + 10位机器ID + 12位序列号。这样单机每毫秒可以生成4096个唯一ID，在垂直层面按机器ID区分，保证全局唯一。更重要的是，这个ID自带时间信息，可以按ID排序直接对应消息的时间顺序，做分页查询时非常方便。

有一个细节值得注意：雪花算法强依赖机器时钟，如果服务器时间发生回拨，就可能生成重复ID。一定要在代码里加时间回拨检测，如果检测到当前时间小于最后一次生成ID的时间，可以选择等待时钟追上，或者直接在当前毫秒内借用序列号补偿。测试环境可能永远触发不了，但生产环境偶尔会有NTP同步导致的时间跳动，不处理就是线上事故。

2.3 连接层设计：一条长连接的生命周期

连接层是IM系统最容易被低估的部分。设计得好，可以轻松扛住百万连接；设计不好，几千连接就能把服务器拖垮。

一条长连接的完整生命周期包括：TCP建连、协议握手、鉴权、心跳保活、消息收发、断线重连。这里面每一个环节都有讲究。

TCP建连后，客户端会发送一个握手包，包含协议版本号和客户端设备信息。服务端解析后返回握手响应，并下发一个全局唯一的connectionId。这个connectionId非常关键，它是后续所有操作中，服务端定位一条连接的唯一凭据。

鉴权放在握手之后。客户端携带token来换取登录态，服务端会把这个连接绑定到具体的userId上。这里我有个习惯：连接和用户做完全解耦。也就是说，握手成功后你先拿到的是connectionId，再通过登录命令建立userId和connectionId的映射关系。这样设计的优点在于，可以支持一个用户多端登录，每一端映射到不同的connectionId，上下行互不干扰。

心跳保活用的方案是：客户端每30秒发一个心跳包，服务端如果在90秒内没有收到任何数据包，就判定连接已死，主动断开并清理在线状态。这个“90秒内没收到任何数据包”而不是“90秒内没收到心跳包”，是一个很细节的差别。移动网络下，用户切后台、电梯里断网，TCP层根本感知不到，只有靠心跳超时来兜底。时间窗口放宽一点，能避免大量误判。

3. 实操过程与核心环节实现

3.1 接入层Netty服务的搭建与参数调优

接入层服务我拆成了独立的服务模块，部署时单独扩容，不影响业务层。Netty服务端的核心搭建逻辑，我用代码说明。

java复制EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup(0);

ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.group(bossGroup, workerGroup)
    .channel(NioServerSocketChannel.class)
    .option(ChannelOption.SO_BACKLOG, 1024)
    .option(ChannelOption.TCP_NODELAY, true)
    .childOption(ChannelOption.SO_KEEPALIVE, true)
    .childOption(ChannelOption.WRITE_BUFFER_WATER_MARK, new WriteBufferWaterMark(32 * 1024, 64 * 1024))
    .childHandler(new ChannelInitializer<SocketChannel>() {
        @Override
        protected void initChannel(SocketChannel ch) {
            ch.pipeline()
                .addLast("decoder", new ImMessageDecoder())
                .addLast("encoder", new ImMessageEncoder())
                .addLast("idleHandler", new IdleStateHandler(0, 0, 90, TimeUnit.SECONDS))
                .addLast("loginHandler", new LoginAuthHandler())
                .addLast("heartbeatHandler", new HeartbeatHandler())
                .addLast("dispatchHandler", new MessageDispatchHandler());
        }
    });

这里有几个参数我单独说下。

WRITE_BUFFER_WATER_MARK，很多教程根本不提，但IM场景必须配置。长连接场景下，如果某个客户端消费能力弱，服务端往这个连接写数据时，数据会积压在Netty的写缓冲区里。不设水位线，内存迟早被写满。设了低水位和高水位，Netty可以在缓冲区积压到高水位时通知上层，触发背压逻辑，保护服务端内存。

IdleStateHandler设置的90秒，就是前面说的超时判定窗口。它不区分是心跳包还是业务包，只要在90秒内有任何数据经过，就认为连接是健康的。这比单纯依赖客户端心跳更稳健。

解码器是整个连接层最重要的组件。业务消息必须自己做编解码，避免半包、粘包问题。

java复制public class ImMessageDecoder extends ByteToMessageDecoder {
    @Override
    protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) {
        if (in.readableBytes() < 4) {
            return;
        }
        in.markReaderIndex();
        int length = in.readInt();
        if (length < 0 || length > 1024 * 1024) {
            ctx.close();
            return;
        }
        if (in.readableBytes() < length) {
            in.resetReaderIndex();
            return;
        }
        byte[] data = new byte[length];
        in.readBytes(data);
        try {
            ImMessage message = JsonUtils.parseObject(data, ImMessage.class);
            out.add(message);
        } catch (Exception e) {
            // 解析失败直接断开连接，防止脏数据持续占用资源
            ctx.close();
        }
    }
}

核心逻辑就两点：先读4字节的长度字段，判断当前缓冲区里的数据是否够一个完整包；不够就重置读指针，等更多数据到达。这个“先mark再reset”的方式是处理半包的标准手法。同时长度校验非常重要，一定要校验最大值，防止有人传一个巨大的长度值把内存撑爆。

3.2 在线状态管理：Redis怎么存储和更新

在线状态这个模块，几个方案我都试过。存在内存里的ConcurrentHashMap，集群环境下每台机器数据不一致，废弃。存MySQL，扛不住高频更新，废弃。最后稳定在Redis上。

我的存储结构是这样的：

• key为 im:online:{userId}，value为当前用户所有在线设备的connectionId列表，用Set存储。
• key为 im:conn:{connectionId}，value为连接对应的userId和设备信息，用String存储，TTL设为90秒。
• 每次收到心跳或业务消息，通过 expire 命令刷新 im:online:{userId} 和 im:conn:{connectionId} 的TTL。

这个双向映射的设计非常关键。通过userId能查到所有在线连接，用于推送定位；通过connectionId能反向查到userId，用于处理断线重连和连接清理。

连接建立时，按顺序执行以下操作：

text复制1. 解析握手包，生成connectionId
2. 客户端发起登录请求，携带token
3. 校验token，获取userId
4. 执行 SADD im:online:{userId} connectionId（设置TTL 90秒）
5. 执行 SET im:conn:{connectionId} userId EX 90（设置TTL 90秒）
6. 绑定Channel和userId，注册到本地ChannelGroup

连接断开或心跳超时时，执行反向清理：

text复制1. 从本地ChannelGroup中移除该连接
2. 执行 SREM im:online:{userId} connectionId
3. 删除 im:conn:{connectionId}
4. 如果 im:online:{userId} 的Set已经为空，删除该key

第4步这个判断很多人会遗漏。如果不删空key，那么Redis里会残留大量空Set，当用户量上来之后，内存浪费非常明显。我见过有团队因为这个问题在Redis里存了几千万个空key，排查时一脸懵。

3.3 消息收发主流程：从客户端A到客户端B的完整路径

一条普通单聊消息的完整路径，我拆成9个步骤，每一步都有对应的职责。

1. 客户端A发送消息，消息经过接入层的解码器解析，被路由到MessageDispatchHandler。
2. DispatchHandler根据消息类型判断，如果是单聊消息，走单聊处理流程；如果是群聊，走群聊流程。
3. 消息先做基本校验，包括发送者身份是否和连接绑定的一致、消息格式是否正确。
4. 为消息分配全局唯一的msgId（雪花算法生成）。
5. 消息写入MySQL的message表。这里先落库，再发消息队列，保证消息不丢。
6. 将消息投递到RocketMQ的im-message-topic，投递时带上接收者userId和connectionId列表。
7. 推送消费者从消息队列拉取消息，根据userId查询当前在线的connectionId列表。
8. 通过本地ChannelGroup找到目标连接通道，执行channel.writeAndFlush(message)。
9. 如果目标不在线，跳过实时推送，等用户上线后走消息拉取流程。

这个流程看起来简单，但有一个细节特别容易出错：消息落库和推MQ的顺序。如果不落库直接推MQ，MQ消费失败消息就没影了。如果先推MQ再落库，消费端可能先拿到消息但库里查不到，等用户换设备拉历史消息时就会漏消息。所以顺序一定不能颠倒。

这里还要处理一个去重逻辑。客户端在弱网环境下可能重试发送同一条消息，服务端需要根据客户端的clientMsgId做去重。我在Redis里设置一个短期的去重标记，key为 im:dedup:{clientMsgId}，存在则丢弃，不存在则处理，TTL设置5分钟。这一步如果不做，重试机制会导致用户看到重复消息。

4. 常见问题与排查技巧实录

4.1 半包粘包导致的消息解析问题

半包和粘包是TCP长连接开发里最经典的问题。我刚开始做IM时，在这上面栽过跟头。客户端发来一条消息，解码器收到的字节流可能是前半条消息，也可能是好几条消息粘在一起。

半包问题我的处理方式是上面代码里展示的ByteToMessageDecoder方案：先读长度字段，长度不够就等待更多数据。粘包问题则依靠循环解码，Netty的ByteToMessageDecoder每次decode时可以解析出多个消息对象全部放进out列表。这两个问题本质上都是TCP流式传输的特性导致的，不存在“解决掉”的说法，只有“处理得好不好”的区别。

遇到解析问题，最直接有效的排查手段是抓包。我习惯用Wireshark抓TCP流量，然后对照十六进制报文逐一核对长度字段和数据内容。之前有一次线上出现偶发的消息乱码，抓包后才发现是客户端在字符集编码上统一用了UTF-8，但服务端老接口用GBK解析二进制数据，两边编码不一致导致的。

4.2 心跳超时误判与断线重连的平衡

心跳超时时间设置得过短，会造成大量误判；设置得过长，又会导致“僵尸连接”清理不及时。这个参数需要根据实际网络环境来调。

我在生产环境遇到过一个很有意思的现象：某地运营商网络有很严格的NAT超时控制，如果TCP连接空闲超过60秒，NAT映射就会被回收。理想情况下心跳30秒一次，不会有问题。但有些低端安卓机在后台运行时的实际发送间隔远超设定值，导致连接被服务端判定超时，用户再切换回App时发现消息收不到。

解决方案是双管齐下：服务端把空闲超时放宽到90秒兜底，客户端在上一次心跳发送后开始倒计时，如果35秒没有收到服务端的响应，主动重连。同时在App从后台切换到前台时，客户端立刻先发一个心跳包再刷新UI，避免展示过期的在线状态。

注意：心跳包的发送时机要放在业务消息之后判断，不能写死“每30秒发一次”。如果刚发过一条业务消息，立刻又发一个心跳包，纯粹浪费流量。

4.3 消息推送丢失与重复推送问题

消息推送丢失，绝大多数原因都出在消息队列消费逻辑上。RocketMQ默认的消费模式是集群消费，如果多个消费者实例都监听同一个topic，还没做负载均衡就可能出现同一个消息被多个实例重复消费。

我的解法是：消费者启动时指定实例名称和消费组，生产环境消费组有且只有一个，实例数量动态扩容。同时消费端逻辑保持幂等——在推送前检查Redis里的 im:push:done:{msgId}:{userId} 标记，如果已经推送过就不再推。即使消息队列重复投递，最终效果也只会有一个推送动作。

重复推送的情况则是因为消息队列在消费超时后会重试投递。我把消费端改为先查重再推送，同时要求每个消息处理必须在30秒内完成，超时就记录报警日志。如果是因为外部依赖变慢导致消费超时，需要先看Redis和RocketMQ的响应时间，而不是盲目调大消费超时时间。

4.4 连接数异常上涨与内存泄漏排查

有一次线上告警，某个接入节点的连接数突然从2万涨到6万，内存也跟着飙升。刚开始怀疑是业务活动带来的正常增长，但观察半小时后发现连接数还在涨，明显不正常。

排查过程三步走。先看连接建立日志，发现大量来源IP相同的连接，而且这些连接只握手不登录，状态一直停在LoginAuthHandler阶段。再看网络层，通过 netstat -anp | grep 服务端口 | wc -l 确认连接来源。最后定位到问题：某个版本的SDK在token失效后会进入一个死循环重连，握手成功后登录失败立即断开，然后立刻重新建连。

这个问题的根治在客户端，服务端能做的是增加防御机制：做一个IP维度的连接频率限制，比如单IP每分钟最多建立30条连接，超过就拒绝并在Redis里记一个临时黑名单。另外，连接建立后如果在30秒内没有完成登录，服务端直接主动断开，避免一堆未认证连接占住内存和文件句柄。

还有一个内存泄漏的经典场景：Netty的ChannelHandler里持有用户上下文对象，连接断开时没有及时清理。如果你用了ThreadLocal存登录态，一定记得在channelInactive里调用remove，否则 Netty 的线程池会一直持有着这些值，时间一长就是严重的泄漏。

4.5 常见问题速查表

5. 上线前的稳定性检查清单

最后整理一份我在项目上线前一定会逐项检查的清单，这些都是实际踩过的坑换来的经验。

第一，全链路超时设置。接入层、业务层、Redis、MySQL、RocketMQ，每一层的连接超时、读超时、写超时都要有明确值。我见过太多系统只配了连接超时，没配读超时，结果下游服务卡住时上游线程全部挂起，最终拖垮整个服务。

第二，消息积压监控。RocketMQ的消费积压必须接入监控和告警。大促场景下消息量暴增，如果消费端扩容不及时，用户的消息延迟会从秒级变成分钟级。要设置积压量超过阈值就自动扩容消费者实例。

第三，连接数趋势监控。单台接入节点的连接数要设置告警阈值。连接增长趋势比当前值更重要，瞬时飙高的连接数往往意味着SDK异常或网络抖动导致的重连风暴。我自己习惯按分钟维度监控连接数变化率，变化率超过50%就触发告警。

第四，内存和GC监控。Netty使用堆外内存，经常出现堆内存正常但堆外内存飙升的情况。启动参数里要设置 -XX:MaxDirectMemorySize 限制堆外内存大小，同时监控Direct Memory的使用情况。堆外内存泄漏比堆内更难排查，真等到OutOfMemory再处理就晚了。

第五，压测验证长连接稳定性。上线前至少做一次72小时的稳定性压测，模拟真实用户的上下线、断线重连、消息收发混合流量。头24小时往往测不出问题，很多内存缓慢增长的问题要到48小时以后才暴露。压测期间重点观察堆内存、堆外内存、连接数、GC频率四项指标的趋势线。

第六，预案文档就位。线上出故障时最怕的就是临时想方案。把“接入节点宕机”“MQ集群故障”“Redis不可用”这三个最核心的故障场景写成预案，明确谁负责执行、执行哪些操作、判断恢复的标准是什么。不要嫌麻烦，真出事时一份好预案能救整个团队。

做个简单的经验总结：IM系统没有太多玄学，核心就是把连接管理好、消息不丢不重、延迟可控。这一篇讲到的内容，是支撑这三个目标的地基。后续系列里我会继续深入消息可靠性保障、群聊扩散策略、多端消息同步这些更靠后的环节。如果有什么想让我优先写的方向，欢迎交流。