#IM 即时通讯系统设计

IM系统的四座大山：

1. 消息可靠送达
   - 消息发送后，对方必须收到
   - 不能丢失，不能重复
   - 离线消息怎么办？

2. 在线状态管理
   - 用户上线/下线怎么感知
   - 多端登录怎么同步
   - 状态变化怎么实时推送

3. 海量长连接
   - 单机支持多少连接？
   - 连接怎么分布到多台网关？
   - 断线重连怎么处理？

4. 消息有序性
   - 消息怎么保证顺序？
   - 乱序消息怎么处理？
   - 多端同步怎么保证一致性？

IM系统的关键数字：

长连接：
- 单机最大连接数：约50万（受限于文件描述符和内存）
- 单机消息吞吐量：约10万/秒
- 2亿在线用户需要：400台网关

消息延迟：
- 同城：<100ms
- 跨城：<500ms
- 跨国：<2s

消息存储：
- 单条消息大小：平均200字节
- 日均消息量：100亿条
- 存储量：100亿 × 200字节 = 200GB/天

Step 1: 消息入库
INSERT INTO message (msg_id, from_uid, to_uid, content, create_time, status)
VALUES (?, ?, ?, ?, ?, 'sending')

Step 2: 推送消息
- 如果用户在线：通过WebSocket推送到网关
- 网关收到后：更新消息状态为 'sent'
- 发送ACK给发送方

Step 3: 等待确认
- 接收方收到消息后：发送ACK（msg_id）给网关
- 网关收到ACK：更新消息状态为 'delivered'

Step 4: 超时重试
- ACK超时（5秒未收到）：重试推送
- 最多重试3次
- 3次后标记为 'failed'，通知发送方

ACK机制设计：

接收方收到消息后，需要回复ACK：
{
    "type": "ack",
    "msg_id": 12345678,
    "timestamp": 1734067200000
}

服务端收到ACK后，更新消息状态为 'delivered'

超时重试：
- 重试间隔：1s, 2s, 4s（指数退避）
- 最大重试次数：3次
- 超过3次：标记为发送失败，通知发送方

消息去重：
- 接收方本地缓存最近1分钟的msg_id
- 如果收到重复msg_id，直接回复ACK，不重复处理

用户上线流程：
1. 客户端连接网关（WebSocket）
2. 网关将用户状态写入Redis：user:online:{uid} = {server_id, fd, timestamp}
3. 网关通过Redis Pub/Sub通知其他网关
4. 其他网关更新本地路由表

用户下线流程：
1. 客户端主动关闭连接 / 心跳超时
2. 网关删除Redis中的用户状态
3. Redis Pub/Sub通知其他网关
4. 其他网关更新路由表

在线状态Key设计：
user:online:{uid} → {gateway_id, fd, last_heartbeat, client_version}

TTL设置：
- 每次心跳续期TTL为60秒
- 如果TTL过期，说明用户离线
- Redis会自动清理过期key（结合主动检测）

多端登录：
- 一个uid可以有多条在线记录（user:online:{uid}:{device_id}）
- 查询时用 SCAN 或 KEYSPACE 遍历

架构设计：

客户端
  ↓
负载均衡（Nginx / LVS）
  ↓
网关集群（WebSocket）
  ↓
消息路由层（Redis Pub/Sub）
  ↓
消息服务集群
  ↓
消息存储（MySQL分库分表 + Redis）

问题：用户A连接网关1，用户B连接网关2，消息怎么路由？

解决方案：Redis存储网关映射
user:gateway:{uid} → {gateway_id, fd}

消息路由流程：
1. 用户A发消息给用户B
2. 消息服务查询 Redis user:gateway:{B的uid}
3. 获取B连接的网关地址
4. 通过Redis Pub/Sub推送到对应网关
5. 网关找到B的fd，发送消息

断线原因：
1. 网络不稳定（移动网络常见）
2. 切换网络（4G切WiFi）
3. 服务器维护

重连策略：
1. 指数退避：1s, 2s, 4s, 8s... 最大30s
2. 重连上限：最多重试10次
3. 重连时携带上一次的最大msg_id
4. 服务端推送这期间未收到的消息

消息同步：
- 客户端连接时带上 last_msg_id = 12345678
- 服务端查询消息表，找出 last_msg_id 之后的消息
- 批量推送给客户端

消息量估算：
- 日均消息量：100亿条
- 单表容量：3000万条
- 需要表数：100亿 / 3000万 ≈ 334张表

按 msg_id 取模分表：
- msg_id = 雪花ID（递增）
- 表数：256张表
- table_index = msg_id % 256

分库策略：
- 8个库，每库32张表
- db_index = table_index / 32
- table_index = table_index % 32

热数据（近7天）：MySQL + Redis
- 最近7天的消息频繁被访问
- 存在MySQL做持久化
- 热点数据缓存在Redis

冷数据（7天前）：归档到HBase / ES
- 历史消息访问频率低
- 归档到成本更低的存储
- 按月分区，查询时指定时间范围

问题：重试机制导致消息重复
场景：接收方收到消息后ACK丢失，服务端重试推送
影响：接收方看到两条相同的消息
解决方案：
- 接收方本地去重：维护一个最近消息ID集合
- 消息ID为64位整数，内存占用可接受（1000个ID ≈ 8KB）

问题：消息顺序和发送顺序不一致
场景：网络抖动，消息1比消息2晚到
影响：聊天界面显示顺序错乱
解决方案：
- 消息ID递增，接收方按ID排序显示
- 消息携带 sequence 序号，接收方按序号重组
- 乱序超过阈值（如10条），触发全量同步

问题：Redis和网关内存不一致
场景：网关内存显示用户在线，但Redis显示离线
影响：消息路由到错误的网关
解决方案：
- 定期同步：网关每30秒上报本地状态到Redis
- 消息推送时先查Redis，再查网关
- 兜底：推送失败后降级为查询Redis

问题：大群发消息导致消息风暴
场景：1000人群里有人发消息，推送给999人
影响：单条消息变成999条消息，系统压力倍增
解决方案：
- 消息聚合：只推送到在线用户，离线用户拉取
- 分批推送：避免瞬间流量过大
- 限流：单用户每秒最多推送1000条消息

问题：用户频繁断线重连，占用大量连接资源
场景：用户在地铁里，信号不稳定
影响：网关连接数激增，性能下降
解决方案：
- 连接限流：单IP每秒最多N个新建连接
- 心跳自适应：根据客户端网络质量调整心跳间隔
- 连接复用：支持HTTP/2 Multiplexing，一个连接承载多个会话