聊天系统 / 即时通讯（IM）技术文档

聊天系统 / 即时通讯（IM）技术文档

参考产品：微信、Telegram、WhatsApp、Signal、Slack

0. 定位声明

前置知识： - 理解 TCP/IP、HTTP/WebSocket 基础协议 - 了解分布式系统基础（CAP 理论、一致性模型） - 熟悉消息队列基本概念（Producer/Consumer 模型） - 了解关系型数据库与 NoSQL 基础 不适用范围： - 不覆盖音视频实时通话（RTC）的编解码与传输优化 - 不覆盖端到端加密（E2EE）的密码学实现细节 - 不覆盖 IM SDK 的移动端集成（iOS/Android）

1. 一句话本质

聊天系统解决的问题：让 A 发出的一条消息，能快速、可靠、有序地送达 B——无论 B 此刻是在线、离线、还是在地球另一端。

用更白话说：

• 是什么：一套让人与人（或人与机器）实时交换文字/图片/文件的基础设施。
• 解决什么问题：网络不可靠、接收方可能不在线、消息量巨大（微信日消息量超 450 亿条）时，如何保证"消息不丢、不重、不乱序"。
• 怎么用：客户端通过长连接把消息推给服务器，服务器负责路由、存储、推送给目标接收方。

2. 背景与根本矛盾

2.1 历史背景

核心驱动力：移动互联网让"随时随地在线"成为默认预期，系统必须同时处理数亿条长连接。

2.2 根本矛盾（Trade-off 全景）

实时性（低延迟 < 100ms） vs 可靠性（消息不丢失） ↓ ↓ 牺牲部分一致性 牺牲部分实时性 用 UDP/QUIC 优化 用 ACK + 重传保证

3. 核心概念与领域模型

3.1 关键术语表

3.2 领域模型

┌─────────────────────────────────────────────────┐ │ 核心实体关系 │ │ │ │ User ──── 1:N ──── Session（会话） │ │ │ │ │ ┌─────────┴──────────┐ │ │ 单聊(P2P) 群聊(Group) │ │ │ │ │ │ Message Message │ │ ├── msg_id (全局唯一) │ │ ├── seq (会话内有序) │ │ ├── from_uid │ │ ├── to_id (uid or group_id) │ │ ├── content_type (text/image/file) │ │ ├── content │ │ ├── server_time (服务端时间戳) │ │ └── client_time (客户端时间戳) │ └─────────────────────────────────────────────────┘

消息流模型（时序视角）：

Client A Server Client B │ │ │ │──── 发送消息 ─────────>│ │ │ │── 写入 MQ/DB │ │ │── 生成全局 msg_id │ │<──── Server ACK ───────│ │ │ │─── Push/投递 ──────────>│ │ │<── Client ACK ──────────│

3.3 读扩散 vs 写扩散（关键设计选择）

写扩散（Fan-out on Write）：

• 消息写入时，立即复制到每个接收方的收件箱
• 优点：读取极快，直接查自己的收件箱
• 缺点：群成员 10,000 人时，一条消息写 10,000 次（写放大）
• 适用：单聊、小群（< 200 人）

读扩散（Fan-out on Read）：

• 消息只存一份，读取时动态聚合
• 优点：写入成本低，适合超大群
• 缺点：读取时聚合计算量大
• 适用：大群、超级群（> 500 人）、朋友圈/Feed 流

微信实际策略：单聊用写扩散，群聊采用混合策略（小群写扩散，大群读扩散）。

4. 对比与选型决策

4.1 通信协议横向对比

4.2 消息存储方案对比

⚠️ 存疑：以上 QPS 数据为业界典型参考值，受硬件配置、集群规模影响较大，需根据实际压测结果调整。

4.3 选型决策树

需要 IM 系统？ │ ├── DAU < 100 万？ │ ├── 是 → WebSocket + MySQL/Redis，单体或小集群够用 │ └── 否 ↓ │ ├── 需要 E2EE（端到端加密）？ │ ├── 是 → Signal Protocol + 不存服务器明文 │ └── 否 ↓ │ ├── 需要超大群（> 5000 人）？ │ ├── 是 → 读扩散 + 消息总线（Kafka）+ HBase │ └── 否 → 写扩散 + Redis 收件箱 + MySQL 存储 │ └── 需要多数据中心？ ├── 是 → Cassandra（最终一致）或 CockroachDB（强一致但延迟高） └── 否 → HBase 或分库分表 MySQL

4.4 与上下游技术的配合关系

┌──────────┐ ┌──────────┐ ┌────────────┐ ┌──────────┐ │ 客户端 │───>│ 接入层 │───>│ 业务逻辑层 │───>│ 存储层 │ │(iOS/Web) │ │(Gateway) │ │(IM Server) │ │(DB/Cache)│ └──────────┘ └──────────┘ └────────────┘ └──────────┘ ↑ │ │ │ 负载均衡 消息队列 │ (Nginx/LVS) (Kafka/RMQ) │ │ └────── APNs/FCM ←── Push Server ┘ （离线推送）

5. 工作原理与实现机制

5.1 整体架构分层

┌─────────────────────────────────────────────────────────┐ │ 客户端层 │ │ iOS App / Android App / Web / Desktop │ └─────────────────────┬───────────────────────────────────┘ │ WebSocket / TCP 长连接 ┌─────────────────────▼───────────────────────────────────┐ │ 接入层 (Gateway) │ │ • 维护长连接（单机 10万~100万连接） │ │ • 连接鉴权、心跳管理、连接路由 │ │ • 无状态化（连接信息存 Redis） │ └─────────────────────┬───────────────────────────────────┘ │ RPC / 消息队列 ┌─────────────────────▼───────────────────────────────────┐ │ 业务逻辑层 (IM Core) │ │ • 消息路由（找到目标用户在哪个 Gateway） │ │ • 消息 ID 生成（全局唯一 Seq） │ │ • 读/写扩散逻辑 │ │ • 群组管理、关系链管理 │ └──────┬──────────────┬──────────────┬────────────────────┘ │ │ │ ┌──────▼──┐ ┌──────▼──┐ ┌──────▼──────┐ │ 消息存储 │ │ 缓存层 │ │ 推送服务 │ │ HBase/ │ │ Redis │ │ APNs / FCM │ │ MySQL │ │ │ │ (离线推送) │ └─────────┘ └─────────┘ └─────────────┘

5.2 关键流程：单聊消息发送全链路

步骤 1：客户端 A 发送消息 A → Gateway_A：{from: uid_A, to: uid_B, content: "hello", client_msg_id: "uuid_xxx"} 步骤 2：Gateway 转发至 IM Core Gateway_A → IM_Core：消息路由请求 步骤 3：IM Core 处理 3.1 生成全局唯一 msg_id（Snowflake 或数据库序列） 3.2 写入消息存储（HBase/MySQL） 3.3 判断 uid_B 是否在线： - 查询 Redis：{key: "presence:{uid_B}", value: "gateway_id:3"} 3.4 写入 uid_B 的离线消息队列（若离线） 步骤 4：投递 在线路径：IM_Core → Gateway_B（通过内部 RPC）→ 推送至 B 的连接 离线路径：存入离线队列 → B 上线时拉取 → 同时触发 APNs/FCM 推送 步骤 5：ACK 链路 B 收到消息 → B 向 Gateway_B 发 ACK → Gateway_B 通知 IM_Core IM_Core 更新消息投递状态 → （可选）通知 A "已送达"

5.3 消息 ID 设计：Snowflake 算法

64 位 ID 结构： ┌──────────────────────────────┬──────────┬──────────────┐ │ 41 位：毫秒时间戳 │ 10 位机器ID│ 12 位序列号 │ │ (可用约 69 年) │ │(每毫秒4096个) │ └──────────────────────────────┴──────────┴──────────────┘ 特点： - 单机每秒可生成 4096 × 1000 = 4,096,000 个 ID - 趋势递增，利于 B+Tree 索引 - 包含时间信息，可还原生成时间 ⚠️ 风险：依赖服务器时钟，时钟回拨会导致 ID 重复 解决方案：检测到时钟回拨时，等待时钟追上或使用备用序列号段

5.4 在线状态（Presence）机制

# Redis 实现示例（Redis 7.x）# 用户上线：redis.setex(f"presence:{uid}",30,gateway_id)# 30 秒 TTL# 心跳续期（客户端每 15 秒发一次心跳）：redis.expire(f"presence:{uid}",30)# 查询在线状态：gateway_id=redis.get(f"presence:{uid}")is_online=gateway_idisnotNone# 批量查询（群消息投递）：pipe=redis.pipeline()foruidingroup_members:pipe.get(f"presence:{uid}")results=pipe.execute()# 运行环境：Python 3.11, redis-py 4.6.x, Redis 7.x

Trade-off：TTL 设为 30 秒意味着用户断线后最多 30 秒内系统认为其"在线"，期间消息走推送路径而非离线队列，可能导致轻微延迟。更短的 TTL（如 10 秒）更精确但心跳频率更高，增加服务端压力。

5.5 关键设计决策

决策 1：为什么接入层与逻辑层分离？

长连接是有状态的，用户 A 连接在 Gateway_1 上，消息就必须从 Gateway_1 推送。若将路由逻辑也耦合在 Gateway，则 Gateway 扩容时所有连接需重新分配。分离后，Gateway 只管连接，IM Core 无状态可随意扩容。

决策 2：为什么用消息队列（Kafka）解耦？

直接 RPC 调用时，IM Core 写存储层，高峰期若存储层响应慢，消息堆积导致 IM Core 超时。引入 Kafka 后，IM Core 写入 Kafka 即返回（< 5ms），消费者异步写存储。代价是引入最终一致性，消息可能短暂不可查，通常延迟 < 100ms，业务层需接受。

决策 3：为什么用逻辑时钟而非物理时钟排序消息？

多设备同时发消息时，物理时钟在分布式系统中无法保证全序（NTP 误差可达数十毫秒）。解决方案是服务端统一分配 seq（每个会话单调递增），以服务端 seq 为准定义"顺序"。代价是客户端不能自行决定消息顺序，所有顺序决策权在服务端。

6. 高可靠性保障

6.1 消息可靠投递：QoS 三个等级

主流 IM 的选择：QoS 1 + 客户端去重（用 client_msg_id 做幂等校验）。

6.2 高可用架构

接入层高可用： - 多 Gateway 实例，LVS/Nginx 四层负载均衡 - 单 Gateway 宕机：客户端自动重连（指数退避：1s, 2s, 4s, max 60s） - 连接数据存 Redis Cluster，Gateway 重启不丢连接元数据 IM Core 高可用： - 无状态服务，K8s 自动重启，Rolling Update - 依赖的 Kafka 设置 replication.factor=3，min.insync.replicas=2 存储层高可用： - HBase：RegionServer 宕机，HMaster 60-120 秒内完成 Region 迁移 - Redis：Sentinel 模式（3 节点）或 Cluster 模式，主从切换 < 30 秒 - MySQL：MGR 或 MHA，RTO < 30 秒，RPO = 0（半同步复制）

6.3 可观测性指标

6.4 SLA 保障手段

目标：消息投递成功率 ≥ 99.99%，端到端延迟 P99 < 500ms

7. 使用实践与故障手册

7.1 典型配置示例

Gateway 服务（基于 Netty 4.1.x + Java 17）

// Netty 服务端关键配置（生产级参数说明）ServerBootstrapbootstrap=newServerBootstrap();bootstrap.group(bossGroup,workerGroup).channel(NioServerSocketChannel.class)// SO_BACKLOG：等待连接队列大小，默认128，生产建议1024.option(ChannelOption.SO_BACKLOG,1024)// SO_REUSEADDR：端口复用，服务重启时不需要等待TIME_WAIT.option(ChannelOption.SO_REUSEADDR,true)// TCP_NODELAY：禁用Nagle算法，降低小包延迟（对IM消息重要）.childOption(ChannelOption.TCP_NODELAY,true)// SO_KEEPALIVE：OS层TCP保活（注意：不能替代应用层心跳）.childOption(ChannelOption.SO_KEEPALIVE,true)// 接收/发送缓冲区，根据消息平均大小调整.childOption(ChannelOption.SO_RCVBUF,32*1024).childOption(ChannelOption.SO_SNDBUF,32*1024)// 使用池化内存分配器，降低 GC 压力（生产必配）.childOption(ChannelOption.ALLOCATOR,PooledByteBufAllocator.DEFAULT);// 运行环境：Java 17, Netty 4.1.94.Final

心跳与重连（客户端 Python 示例）

importasyncioimportwebsocketsimportjsonasyncdefim_client(uri:str,uid:str):retry_delay=1# 初始重连延迟 1 秒whileTrue:try:asyncwithwebsockets.connect(uri,ping_interval=15,# 每15秒发一次心跳ping_timeout=10# 10秒内未收到 pong 则断开)asws:retry_delay=1# 连接成功，重置退避# 鉴权握手awaitws.send(json.dumps({"type":"auth","token":get_token(uid)}))asyncformessageinws:data=json.loads(message)ifdata["type"]=="msg":# 立即回 ACK，保证 QoS1 可靠性awaitws.send(json.dumps({"type":"ack","msg_id":data["msg_id"]}))process_message(data)except(websockets.ConnectionClosed,OSError)ase:print(f"连接断开:{e},{retry_delay}秒后重连")awaitasyncio.sleep(retry_delay)retry_delay=min(retry_delay*2,60)# 指数退避，上限60秒# 运行环境：Python 3.11, websockets 11.0

消息去重（Redis 实现）

importredis r=redis.Redis(host='localhost',port=6379,db=0)defis_duplicate_message(client_msg_id:str,uid:str)->bool:""" 消息去重：利用 Redis SET NX 原子操作 key 格式：msg_dedup:{uid}:{client_msg_id} TTL：24小时（覆盖客户端重试窗口） """key=f"msg_dedup:{uid}:{client_msg_id}"# SET key 1 NX EX 86400 → 成功(True)=首次，失败(None)=重复result=r.set(key,1,nx=True,ex=86400)returnresultisNone# None 表示 key 已存在，即重复消息# 运行环境：Python 3.11, redis-py 4.6.x, Redis 7.x

7.2 故障模式手册

【故障一：消息发送成功但接收方未收到】 - 现象：发送方看到"已发送"，接收方无消息，也无离线推送 - 根本原因： 1. 在线状态缓存过期但用户实际仍在线（Presence 脏数据） 2. Gateway 路由表未更新（服务节点扩容后 Redis 映射未同步） 3. 离线队列消费者故障，积压未处理 - 预防措施： 监控 offline_queue_depth，> 10万条触发告警 在线状态 TTL 缩短至 15 秒（需评估心跳负载影响） - 应急处理： 1. 检查 Redis 在线状态一致性：presence:{uid} 是否指向存活 Gateway 2. 重启消费者服务，清理积压 3. 发送方超时后触发"消息重发"（客户端 ACK 超时 5 秒触发）

【故障二：消息乱序】 - 现象：接收方收到的消息顺序与发送方发送顺序不一致 - 根本原因： 1. 多 IM Core 节点并发写入，seq 分配出现竞争 2. 客户端多线程发送，不同消息路由到不同 Gateway - 预防措施： Seq 分配使用 Redis Lua 脚本原子操作或单点序列服务 客户端同一会话消息串行发送（等上条 ACK 后再发下条） - 应急处理： 客户端按 seq 排序展示，seq 空洞时（如收到 seq=5 缺少 seq=4）， 等待 200ms 再补拉缺失消息，超时后展示已有消息

【故障三：连接数暴增导致 Gateway OOM】 - 现象：Gateway 内存使用率超过 90%，频繁 GC，延迟飙升 - 根本原因： 1. 节假日流量突增，连接数超出预估上限（单机超过 100 万） 2. 每连接内存分配过多（读写 Buffer 过大，未池化） - 预防措施： Netty Buffer 使用 PooledByteBufAllocator（节省 30-50% 内存） 单 Gateway 连接上限设 80 万，超限引导新连接到其他节点 提前压测节假日流量，Auto Scaling 提前扩容 - 应急处理： 快速扩容新 Gateway 节点，LB 摘除过载节点流量 JVM 参数：-Xmx 设为物理内存 60%，避免触及 OOM Killer

【故障四：群消息风暴（万人大群）】 - 现象：向万人群发消息后，服务器 CPU 飙升，其他用户消息延迟增大 - 根本原因： 写扩散模式下，1 条消息需写 1 万次收件箱，I/O 压力巨大 - 预防措施： 大群（> 500 人）强制使用读扩散模式 消息投递使用 Kafka 削峰：生产者写 1 次，消费者批量处理 群成员列表缓存（Redis），避免每次投递查数据库 - 应急处理： 临时对大群消息降级：只写消息存储，暂停实时推送， 用户主动拉取（Pull 模式）代替服务器主动 Push

【故障五：离线消息暴增导致用户上线延迟】 - 现象：用户长时间离线后上线，消息加载超过 10 秒 - 根本原因： 离线期间大量群消息积压，上线时批量拉取导致 DB 压力大 - 预防措施： 离线消息最多存储 3-7 天（超期标记为"N条未读"而非全量拉取） 按会话分页拉取，首屏只拉最近 20 条，其余懒加载 - 应急处理： 限制单次拉取离线消息上限：500 条/会话，超出只展示未读数

7.3 边界条件与局限性

• 超大群（> 10 万人）：实时 Push 几乎不可行，需退化为"公告板"模式（用户主动刷新）
• 弱网环境（丢包率 > 5%）：WebSocket over TCP 因重传堆积导致延迟急剧增加，需考虑 QUIC 或应用层 FEC
• 跨国消息：中美之间 RTT 约 200-300ms，用户感知明显；需在目标地区部署 PoP 节点
• 消息撤回的局限：服务端删除只能删除服务器副本，无法保证对方设备已缓存内容被删除
• 时钟问题：客户端时钟可被篡改，所有"发送时间"显示应以服务端时间为准

8. 性能调优指南

8.1 性能瓶颈识别路径

问题：消息延迟高 / 吞吐量低 │ ├── 网关层瓶颈？ │ 指标：Gateway CPU > 70%，线程池队列深度 > 1000 │ 定位：Netty EventLoop 线程 CPU 使用率（async-profiler） │ → 解决：增加 WorkerGroup 线程数，或水平扩容 Gateway │ ├── 消息路由层瓶颈？ │ 指标：IM Core 处理延迟 P99 > 50ms │ 定位：Jaeger 链路追踪，找耗时 Span │ → 常见原因：Redis 查询慢（热 Key）、DB 查询慢（缺索引） │ ├── 存储层瓶颈？ │ 指标：DB 写 QPS 接近上限，磁盘 IO util > 80% │ 定位：slow query log，HBase RegionServer 热点 │ → 解决：消息写入批量化（batch write），异步写入 │ └── 推送层瓶颈？ 指标：APNs/FCM 队列积压 > 10 万 → 解决：增加推送 Worker 数量，优化批量合并推送

8.2 调优步骤（按优先级）

1. 连接层优化（优先级：高，风险：低）

• 开启 TCP_NODELAY，消除 Nagle 算法引入的最大 40ms 延迟
• Netty 使用 PooledByteBufAllocator，减少内存碎片
• 验证方法：对比开启前后 P99 延迟，目标降低 20-40ms

2. 序列化优化（优先级：高，风险：低）

• 将 JSON 协议替换为 Protobuf，消息体积减少 30-60%，序列化速度提升 3-5x
• 验证方法：对比相同消息的序列化耗时和传输大小

3. Redis 热 Key 优化（优先级：高，风险：中）

• 在线状态查询是典型热 Key（超大群的 group_members 列表）
• 方案：本地缓存（Caffeine，TTL 1-3 秒）+ Redis，降低 Redis QPS 50-80%
• 风险：本地缓存导致在线状态短暂不一致（最大偏差 = 本地缓存 TTL）

4. 消息写入批量化（优先级：中，风险：中）

• 单条写入改为批量写入（每 5ms 或积累 100 条触发一次 flush）
• HBase 批量写入吞吐提升 3-5x
• 风险：服务宕机时可能丢失缓冲区内未写入的消息（需 WAL 保护）

5. 操作系统级连接数调整（优先级：中，风险：高）

• Linux 系统级：ulimit -n 1000000（修改 /etc/security/limits.conf）
• 内核参数：net.core.somaxconn=65535，net.ipv4.tcp_max_syn_backlog=8192

8.3 调优参数速查表

9. 演进方向与未来趋势

9.1 QUIC / HTTP3 替代 TCP 长连接

微信、阿里等已在部分弱网场景引入 QUIC，核心优势是：0-RTT 握手（相比 TLS 1.3 + TCP 的 1-RTT）、多路复用无队头阻塞（TCP 丢包时所有流被阻塞，QUIC 只阻塞对应流）、连接迁移（手机切换 WiFi/4G 时连接不中断）。

对使用者的影响：弱网下消息延迟可降低 30-50%（⚠️ 存疑：取决于具体网络环境，需 A/B 测试验证），但 UDP 可能被企业防火墙封锁，需保留 TCP 降级路径。

9.2 去中心化 / 联邦化 IM（Matrix 协议）

Matrix 协议（Element 的基础）允许不同服务器互通，类似 Email——用户可自建 Home Server，不同服务器的用户可互发消息。

对使用者的影响：企业 IM 可自建服务器，数据不出域（合规优势）；跨组织协作无需同一 App。代价是运维复杂度大幅增加，多服务器间消息同步开销导致性能比中心化方案差。

9.3 AI-Native IM

消息内容理解（反垃圾、反诈骗）、智能回复建议、多模态消息（语音实时转文字）已成为主流 IM 的标配能力，架构正在向 AI 处理能力与消息管道深度集成演进，而非旁路处理——即每条消息在路由过程中即完成 AI 处理，而不是处理后再送入分析系统。

10. 面试高频题

【基础理解层】（考察概念掌握） Q：IM 系统如何保证消息不丢失？ A：三层保障： ① 传输层：TCP 保证数据到达服务器 ② 应用层：服务器收到后回 Server ACK，客户端超时（5秒）未收到则重传 ③ 投递层：服务器投递给接收方后，接收方回 Client ACK， 未收到则服务器定时重推（3次，间隔 5s/30s/5min） 客户端用 client_msg_id 做幂等去重，避免重传导致重复展示。 考察意图：考察对 QoS1 (At Least Once) 机制的理解和端到端可靠性设计。 Q：什么是读扩散和写扩散？各有什么优缺点？ A：写扩散：消息写入时立即复制到每个接收方收件箱，读快但群成员多时写放大严重。 读扩散：消息只存一份，读取时动态聚合，写入成本低但读取时计算量大。 生产环境通常混合使用：单聊/小群写扩散，大群读扩散。 考察意图：考察对 IM 核心存储模型的理解，以及权衡思维。

【原理深挖层】（考察内部机制理解） Q：如何设计一个全局唯一且有序的消息 ID？ A：主流方案：Snowflake 算法（41位时间戳 + 10位机器ID + 12位序列号） 优点：趋势递增，单机每秒 400 万个，无需中心化协调 缺点：依赖机器时钟，时钟回拨会导致 ID 重复 应对方案： ① 检测到回拨时等待（适合回拨 < 5ms） ② 使用 UidGenerator（百度开源，解决时钟回拨） ③ 数据库递增 Seq + 号段模式（严格顺序，但需承受 DB 压力） 考察意图：考察分布式 ID 生成方案及时钟问题的深度理解。 Q：亿级用户的 IM 系统，如何设计在线状态（Presence）服务？ A：核心挑战：10亿用户全在线，Redis 存 10亿个 Key。 解决方案： ① 分片：按 uid % N 分配到不同 Redis 集群 ② TTL 机制：心跳续期，过期自动删除（无需显式下线通知） ③ 精度权衡：实时精度（TTL=10s）vs 心跳频率（10s一次 = 每秒1亿次请求） 大规模系统（> 1亿 DAU）通常降低精度：TTL=60s，心跳30s一次 ④ 本地缓存：Gateway 层缓存本机连接状态，1秒内无需查 Redis 考察意图：考察大规模分布式系统的容量规划和精度-成本权衡思维。

【生产实战层】（考察工程经验） Q：线上发生了消息积压（离线队列深度超过100万），如何排查和处理？ A：排查步骤： 1. 确认范围：全量积压还是特定用户/群？ → 全量：消费者服务故障；特定用户：死信消息阻塞 2. 查看 Kafka consumer group lag 指标 3. 查消费者日志：DB 超时？消息格式错误？ 4. 定位热点：是否有某个超大群（10万人）占用大量队列 处理方案： - 消费者故障：重启服务，增加消费者实例并行消费 - 死信阻塞：将死信消息转移到死信队列，跳过继续消费 - 超大群积压：降级为"未读数"提示，暂停实时推送 - 根本解决：消息分级（大群/小群分不同 Topic） 考察意图：考察生产问题排查能力，包括监控、日志、应急处理的系统思维。 Q：如何设计"消息撤回"功能？ A：实现步骤： 1. 发送方触发撤回：发送一条撤回指令消息（msg_type=recall, recall_msg_id=xxx） 2. 服务端： - 校验权限（只能撤回自己的消息，且2分钟内） - 更新原消息状态为 recalled（软删除） - 将撤回指令推送给所有在线接收方 - 清除离线队列中的原消息，替换为撤回通知 3. 客户端：收到撤回指令，本地替换为"xx撤回了一条消息" 局限性：接收方已读且截图，服务端无法控制； 多端需全部同步撤回；已推送到设备的消息需配合本地存储删除。 考察意图：考察功能设计的完整性，包括边界条件和局限性的认知。

11. 文档元信息

验证声明

本文档内容经过以下验证： ✅ 核心架构模式与官方/业界文档一致性核查： - 微信技术博客（IM架构演进相关文章） - Telegram MTProto 协议官方文档 - Discord 消息存储架构工程博客 - 美团、字节等技术博客公开实践 ⚠️ 以下内容未经本地环境验证，仅基于文档和行业资料推断： - 第8节 调优参数推荐值（依赖具体硬件和业务流量特征，须实测） - 第6.3节 监控阈值（行业经验值，需根据实际业务校准） - QUIC 延迟降低 30-50% 的性能数据（第9.1节，需 A/B 测试） - 第4.2节 存储方案 QPS 数据（受集群规模和硬件影响显著）

知识边界声明

本文档适用范围： - 面向 DAU 百万级及以上的 IM 系统架构设计参考 - 技术选型：Netty、Kafka、Redis、HBase/MySQL 主流开源栈 - 部署环境：Linux x86_64，云原生（K8s）或传统机房 不适用场景： - 小型 IM（DAU < 10万）：过度设计，直接用 WebSocket + 单体服务即可 - 端到端加密的密码学实现（需参考 Signal Protocol 专项文档） - 音视频 RTC（实时通话）架构（完全不同技术栈：WebRTC/SFU/MCU）

参考资料

官方文档 / 权威来源： 1. Telegram MTProto 协议文档 https://core.telegram.org/mtproto 2. MQTT 协议规范（IoT IM 场景参考） https://mqtt.org/mqtt-specification/ 3. Matrix 联邦 IM 协议规范 https://spec.matrix.org/ 4. Netty 官方文档 https://netty.io/wiki/user-guide-for-4.x.html 工程实践 / 技术博客： 5. 美团 IM 技术实践 https://tech.meituan.com/2020/08/20/meituan-im.html 6. Discord 如何存储数十亿条消息（Cassandra → ScyllaDB 迁移案例） https://discord.com/blog/how-discord-stores-billions-of-messages 7. Signal Protocol 文档（E2EE 参考） https://signal.org/docs/ 延伸阅读： 8. 《Designing Data-Intensive Applications》 Martin Kleppmann 第5章（复制）、第7章（事务）对 IM 存储设计有直接指导意义 9. Facebook Messenger 架构演进（2016 Engineering Blog） 10. Apache Kafka 官方文档（消息管道设计参考） https://kafka.apache.org/documentation/