IM系统设计#

┌──────────┐    WebSocket    ┌──────────────┐     MQ      ┌──────────────┐    WebSocket    ┌──────────┐
│ 发送方 A  │ ──────────────→│ 接入网关层    │ ──────────→ │ 接入网关层    │──────────────→ │ 接收方 B  │
└──────────┘                 └──────┬───────┘             └──────────────┘                 └──────────┘
                                    │
                              ┌─────┴─────┐
                              │  消息服务   │
                              │ (存储+路由) │
                              └─────┬─────┘
                                    │
                    ┌───────────────┼───────────────┐
                    │               │               │
              ┌─────┴─────┐  ┌─────┴─────┐  ┌─────┴─────┐
              │  消息 DB   │  │  Redis    │  │  MQ       │
              │(历史消息)   │  │(在线状态)  │  │(异步投递)  │
              └───────────┘  └───────────┘  └───────────┘

在线投递（推模式）：
  A → 网关 → 消息服务（存DB + 写MQ）→ 路由查 B 在哪个网关 → 推送给 B

离线投递（拉模式）：
  B 上线 → 拉取离线消息（按 lastSeq 增量拉取）

单聊：写扩散（每个人一份收件箱）
  - 优点：读简单，按 userId 分库
  - 缺点：写放大

群聊：读扩散（群消息存一份，成员各自记录已读位点）
  - 优点：写不放大
  - 缺点：读时需合并
  - 大群（>500人）一般用读扩散 + 推送离线通知

方案1：Redis INCR per conversation（简单，但 Redis 单点）
方案2：Snowflake 全局 ID（天然有序，但跨 conversation 不连续）
方案3：号段分配（发号器批量分配 seq 段，本地递增）

推荐：conversation 粒度的 Redis INCR + 本地缓存号段

已读回执：B 读到 seq=100 → 发 ACK(conversation, seq=100) → A 端更新"已读"
消息撤回：2分钟内可撤回 → 发撤回消息 → 服务端标记 + 推送撤回通知给对方