fafa阿花做即时通讯后台，第一件事不是写代码，而是想清楚你到底要做一个什么样规模的系统。这个系列我打算从零开始，把一套能支撑百万长连接的服务端架构拆开来讲。第一篇先解决最核心的问题：技术选型、消息模型、连接层设计，以及消息收发的主链路怎么搭。适合刚接触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后台的骨架，后续系列文章再往里填肉，比如群聊扩散、消息漫游、文件传输、多端同步、消息已读回执、推送通道优化等等。
这个顺序是有讲究的。消息模型决定了一切上层逻辑怎么写，连接层决定了系统能承载多少在线用户，主流程决定了消息能不能最终送达。骨架不对，后面再填多少肉都是歪的。所以我建议读者跟着这个节奏来，先把这一篇吃透，再去追后面的文章。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心细节解析与实操要点
2.1 消息模型：单聊、群聊、系统消息的差异
消息模型是IM系统的地基，设计得好不好，直接决定后续业务开发的复杂度。我把消息分成三大类：单聊消息、群聊消息、系统通知。
单聊消息是最简单的模型。消息有一个唯一的from用户和一个唯一的to用户。这里有个坑：很多人在设计表结构时，会想着用一个session_id把双方的会话关联起来，减少查询条件。这个思路对了一半——session_id确实能加速会话列表查询，但注意不要用它作为消息的唯一归属维度，因为同一对用户之间可以有多端设备，消息的可见性需要按设备和时间来决定。
群聊消息比单聊复杂一个量级。一条群消息发出去，理论上有N个接收者，但存储上绝对不应该存N份。我采取的方案是消息存一份，扩散的是扩散表里的条目。也就是说，消息内容表里只有一条记录，但群里每个成员都在message_rela