微信多端IM聊天架构笔记

微信多端IM聊天架构笔记（含名词解释、分步推演+实战案例）

一、基础名词通俗解读

1. IM即时通讯：实时聊天类应用，典型产品微信、QQ，核心要求消息秒达、在线状态实时同步。
2. TCP长连接：客户端与服务端建立持久通信通道，连接建立后长期保持，服务端可主动推送消息，无需像HTTP短连接那样每次通信都重新建立连接，是IM的核心通信基础。
3. 心跳包：客户端定时向服务端发送的轻量探测数据包，用于检测长连接是否存活；长时间未收到心跳，服务判定客户端掉线，清理在线记录。
4. 接入层（Gate）：IM最外层节点，专门负责维护所有客户端的TCP长连接，是客户端和后端服务的唯一入口。
5. 逻辑/路由层：处理聊天业务逻辑，同时根据用户在线位置，完成消息转发、路由分发。
6. 缓存层：存储用户-接入节点映射关系、在线状态，实现快速路由查询。
7. 离线消息：接收方不在线时，服务器暂存消息，待用户上线后补发。

二、基础架构：单端一对一聊天（最简模型）

整套IM分为四层架构，也是多端改造的基础，结合用户A给用户B发消息案例讲解完整流程。

1. 四层整体架构

• 接入层（Gate）：维护客户端长连接；
• 逻辑&路由层：业务处理+消息转发；
• 缓存层：存储用户在线路由信息；
• 数据库层：持久化消息、好友关系、聊天记录。

2. 三大核心流程（案例演示）

（1）用户登录流程

用户A打开手机微信，与Gate1节点建立TCP长连接；
Gate1上报至路由层，路由层在缓存中写入数据：key=用户A ID，value=Gate1（记录用户当前连接的节点）。

（2）心跳保活流程

客户端每隔30~60秒发送心跳包；服务端收到后，刷新缓存中该用户的最后在线时间。
若超时未收到心跳，判定连接断开，删除缓存中的在线记录，释放资源。

（3）消息收发流程

1. 用户A发送消息，通过长连接传到Gate1；
2. Gate1转交路由层，路由查询缓存，查到用户B在线，连接在Gate2；
3. 路由将消息转发给Gate2，Gate2通过长连接推送给用户B；
4. 若缓存无用户B记录 → 判断为离线，消息存入数据库，等待上线补发。

三、第一次改造：支持接收方多端登录

1. 业务规则（参考微信）

同一个账号可同时登录手机、PC等多个终端；同类型终端互踢（比如两台电脑登录同一微信，后登录会挤掉前一台）。

2. 核心改造点：缓存数据结构升级

单端缓存：仅 用户ID → 接入节点
多端缓存：改为 用户ID-终端类型 → 接入节点（终端区分手机、PC、平板）

3. 实战案例

用户B同时登录手机（连接Gate2）、电脑（连接Gate3），缓存生成两条记录：
B-手机 → Gate2、B-PC → Gate3。
用户A向B发消息：路由层查询到B有两个在线终端，向两个Gate节点同时推送消息，B的手机、电脑同步收到消息。

4. 现阶段缺陷

仅解决接收方多端收消息，未考虑发送方多端同步，存在聊天上下文缺失问题。

四、第二次改造：支持发送方多端同步（最终完整版）

1. 现存问题（真实场景举例）

场景：用户A（手机、PC同时在线）、用户B（手机、PC同时在线）

1. A用手机发消息：“今晚吃火锅吗？”，B两端正常接收；
2. B回复：“好，去哪家？”，A两端正常接收；
3. 问题：A的电脑端只能看到B的回复，看不到自己手机发出的消息，聊天记录断裂，体验极差。

2. 核心改造：路由逻辑双向同步

消息路由不再只发给接收方，而是做双向群发：

1. 推送至接收方所有在线终端（保证对方多端收消息）；
2. 同步推送至发送方自身其他在线终端（保证自己所有设备聊天记录完整）。

3. 完整流程（结合案例）

A通过手机（Gate1）发送消息 → 路由层执行两步操作：

1. 查询接收方B：手机(Gate2)、PC(Gate3) → 推送消息至两个节点；
2. 查询发送方A：除当前手机外，还有PC(Gate4)在线 → 同步推送消息至Gate4；
   结果：A手机、A电脑、B手机、B电脑，四端全部收到同一条消息，聊天上下文完全一致。

五、最终多端IM架构总结

1. 两大核心改造（重点）

1. 缓存层：Key由单一用户ID，升级为 用户ID+终端类型，适配多设备在线路由；
2. 路由层：消息由单向转发，升级为双向同步（接收方全终端 + 发送方全终端）。

2. 微信多端登录配套细节

1. 同终端互踢：同一账号不允许两台手机/两台电脑同时在线，新连接建立时，强制断开同类型旧连接；
2. 离线同步：多端全部下线后，消息存入数据库，任意一端上线自动拉取离线消息；
3. 断线重连：移动端网络波动断开后，客户端自动重连，重连后同步离线消息与最新聊天记录。

六、拓展同类落地案例

1. 企业微信/QQ：完全复用该架构，支持手机、电脑、平板多端消息同步，逻辑与微信一致；
2. 直播互动IM：主播、观众多端登录，弹幕、私信依靠双向消息同步保证全设备消息统一；
3. 客服聊天系统：客服电脑、移动端同时接单，消息多端同步，避免漏看客户消息。

七、架构设计思路（面试&实战思维提炼）

1. 由简到繁推演：先实现基础单端架构，逐个叠加“接收方多端”“发送方多端”等需求，逐步迭代，不一步设计复杂架构；
2. 抓核心痛点：多端场景核心不是长连接，而是路由缓存设计 + 消息同步逻辑；
3. 用户体验优先：技术方案必须贴合业务体验，聊天上下文同步是多端IM的硬性要求。

八、常见面试问答

1. 问：为什么不用一个用户ID对应多个节点？
   答：无法区分终端类型，会出现同设备重复登录、无法互踢的问题，用户ID+终端是最优设计。
2. 问：长连接断开如何感知？
   答：依靠心跳机制，超时未收到心跳包，服务端判定掉线，清理缓存路由数据。
3. 问：多端同步会增加服务器压力吗？
   答：会，架构会根据终端数量做消息复制与分发，高并发场景需对路由层做集群扩容。