当前位置：首页 > news >正文

Netty+SpringBoot的分布式宠友IM即时通讯系统，单机百万在线架构实践

news 2026/5/13 22:46:50

一、连接层设计：如何管理百万长连接

IM系统的第一道坎是连接管理。每个客户端维持一个TCP长连接，百万连接意味着百万个Socket。常规BIO模型每个线程处理一个连接，百万线程直接撑爆服务器。

Netty的Reactor模型解决了这个问题。主线程负责Accept，一组Worker线程负责IO读写，业务逻辑交给异步线程池处理。Linux内核参数需要相应调整，ulimit -n开到100万，net.ipv4.ip_local_port_range扩大端口范围，开启tcp_tw_reuse快速回收TIME_WAIT连接。

二、协议设计：JSON就够了

有人迷信Protobuf，说JSON慢。实测下来，在IM场景下JSON序列化开销完全可以接受。JSON便于调试、跨语言友好、开发效率高。这套系统采用纯JSON格式，一条消息的核心结构如下：

{ "cmd": 101, "seq": 12345678, "from": "10001", "to": "10002", "type": 1, "body": {"text": "你好", "at": ["10003"]} }

协议层的一个核心设计是一端口多协议。Netty同一个端口同时解析自定义Socket协议、WebSocket协议和HTTP协议。通过判断前几个字节区分：自定义协议以特定魔数开头，GET/POST走HTTP，特定握手请求走WebSocket升级。

三、消息路由：用户在哪台机器上

分布式部署下，用户A连接网关节点1，用户B连接网关节点2。A发给B的消息需要从节点1路由到节点2。路由表存储在Redis中，key为用户ID，value为节点ID和连接ID。

用户登录时注册路由，心跳时更新最后活跃时间，断开时清理。节点收到消息后查询目标路由：若目标在本机则直接通过Channel写入，若在其他节点则通过内部RPC转发。内部RPC复用Netty长连接池，避免每次调用新建连接。

四、消息同步：读扩散与写扩散的选择

群聊消息的存储有两种策略。写扩散是发一条群消息给每个群成员存一份，读扩散是群消息只存一份，成员拉取时计算自己该看到哪些。

这套系统群消息采用读扩散，朋友圈采用写扩散。群聊消息量大，千人群发一条消息写扩散需要写入一千条记录，磁盘扛不住。读扩散只需要写一条，客户端本地维护已读位置，拉取增量时用时间戳查询即可。

已读回执单独记录到Redis，格式为read_status:{group_id}:{user_id}:{last_msg_id}。发送方可查询哪些成员已读，群聊场景下展示已读人数。

五、离线消息与漫游：三层保障不丢消息

消息可靠性做了三层保障。第一层同步确认，每条消息下发后客户端回复ACK，服务端超时未收到则重推。第二层离线队列，用户离线时消息存入Redis ZSET按时间戳排序，上线后批量拉取。

redis.opsForZSet().add("offline:" + userId, msgStr, msgTime); Set<String> msgs = redis.opsForZSet().rangeByScore("offline:" + userId, 0, now);

第三层漫游存储，所有消息全量写入MySQL分表存储。用户换设备时可拉取最近7天或最近500条历史消息。漫游拉取接口支持分页和时间范围过滤，千万级消息量的查询延迟控制在50毫秒以内。

六、群聊互动：@成员与消息撤回

@成员功能在消息体中用at_uids字段记录被@的用户列表。服务端收到后为每个被@用户单独推送一条系统通知，离线用户通过厂商推送收到@提醒。

消息撤回限制在2分钟内。撤回操作发送一条撤回指令，服务端将原消息标记为revoked=1，所有在线客户端收到指令后替换本地显示。已离线的用户上线时拉取到已标记撤回的消息，直接显示“对方撤回了一条消息”，不展示原始内容。

七、红包功能：Lua脚本保证原子性

红包涉及金额扣减和领取记录两个操作，必须原子执行。用Redis Lua脚本实现，服务端一次性将脚本传给Redis执行，中间不会被其他命令打断。

local remain = redis.call('hget', KEYS[1], 'remainCount') if tonumber(remain) <= 0 then return -1 end if redis.call('sismember', KEYS[1]..':takers', ARGV[1]) == 1 then return -2 end redis.call('hincrby', KEYS[1], 'remainCount', -1) redis.call('sadd', KEYS[1]..':takers', ARGV[1]) return 1

红包金额采用二倍均值法随机分配，每个红包的金额在剩余金额的0.01倍到剩余平均金额的2倍之间浮动。红包状态缓存在Redis，异步写入MySQL做对账，过期未领完的金额原路退回。

八、语音会议：信令与媒体分离

多人语音会议不走IM的消息通道。单独部署SFU服务器负责媒体流转发，IM系统只处理会议信令：发起会议、邀请成员、成员入会离会、静音控制。

信令通过原有WebSocket通道传输，格式如{"cmd":301,"meetingId":"mtg_123","action":"invite","targetUid":"10008"}。接收方收到信令后直接连接SFU服务器建立WebRTC通道。IM服务器不承担任何媒体流量，只处理信令转发，单机负载极低。