聊天系统设计-面试

------------------ | 客户端 | | (App / Web) | ----------------- | -----------v----------- | API Gateway LB | ← 负载均衡、限流、鉴权 ---------------------- | ----------------v------------------ | IM Core Service Cluster | ← 无状态服务处理消息收发 ----------------------------------- ↙ ↘ --------------------- -------------------------- | Redis Cluster | | Kafka / RocketMQ | | (在线状态、会话管理) | | (消息异步解耦、削峰填谷) | -------------------- ------------------------- | | v v ---------------------- ------------------------- | MySQL Cluster | | Elasticsearch | | (用户、好友、消息存档)| | (搜索聊天记录) | ---------------------- ------------------------- | v ------------------------- | Push Service | ← 对接 APNs / FCM / 小米推送 | (离线用户通知) | -------------------------详细设计1️⃣ 客户端WebSocket 还是 HTTP Long Polling选项是否采用原因✅WebSocket✔️ 是支持双向通信低延迟适合实时消息❌ HTTP 轮询✖️ 否浪费资源延迟高 什么是WebSocketWebSocket 是一种让「客户端比如浏览器」和「服务器」之间建立长期连接、实现双向实时通信的技术。建立连接三步走握手阶段通过一次特殊的 HTTP 请求来“升级”成 WebSocket 连接。建立持久连接握手成功后这条 TCP 连接就不会断开了客户端和服务端可以互相随时发送数据帧双向通信任意一方都可以发消息为什么用 WebSocket双向通道服务端可以主动推消息给客户端连接复用一次建立长期使用性能好相比轮询节省 90% 以上流量 类比打电话 vs 不停打电话问“有事吗”—— 显然前者更高效。2️⃣ API GatewayNginx 自定义模块负责TLS 终止HTTPS → WSIP 黑名单、限流Sentinel路由到具体的 IM 服务实例使用 Nginx 的ngx_stream模块支持 WebSocket 代理✅ 优势轻量、高性能、成熟稳定3️⃣ IM 核心服务IM Core Service架构特点无状态设计 → 可水平扩展每个实例维护一部分用户的 WebSocket 连接使用Redis ZooKeeper/Nacos实现路由表userId → serverInstanceId示例流程A 发消息给 BA 发送: {to: B, msg: Hello}↓A 所在的服务查找B 当前连在哪个服务器上查 Redis↓如果在同一台 → 直接内存转发 否则 → 通过 Kafka 发送到 B 所在的服务↓B 的服务通过 WebSocket 推送消息这里的关键技术点分布式消息路由4️⃣ 消息中间件Kafka 或 RocketMQ全屏复制用途说明跨节点消息投递A 和 B 在不同服务器时通过 MQ 传递削峰填谷高峰期消息涌入MQ 缓冲防止雪崩异步处理消息持久化、通知生成等走后台消费✅ 选 Kafka 还是 RocketMQ国内大厂多用RocketMQ阿里开源事务消息强国际公司偏好 Kafka生态丰富解决痛点避免“只能同机房通信”的局限性5️⃣ Redis缓存在线状态 会话管理存储内容online:{userId}→ 存储用户是否在线、连接的 serverIdsession:{userId}→ 当前会话 token、心跳时间unacked:{msgId}→ 待确认的消息用于重试机制✅优势快速查询某人是否在线毫秒级支持发布订阅模式可用于广播系统公告6️⃣ 数据库MySQL 分库分表表设计-- 用户表 CREATE TABLE user ( id BIGINT PRIMARY KEY, nickname VARCHAR(50), avatar_url TEXT ); -- 好友关系表 CREATE TABLE friend ( user_id BIGINT, friend_id BIGINT, create_time DATETIME, PRIMARY KEY(user_id, friend_id) ); -- 消息表按 receiver_id 分片 CREATE TABLE message ( id BIGINT AUTO_INCREMENT PRIMARY KEY, msg_id CHAR(32) UNIQUE, -- 全局唯一 UUID sender_id BIGINT, receiver_id BIGINT, content TEXT, msg_type TINYINT, -- 0文本, 1图片... status TINYINT DEFAULT 0, -- 0发送中, 1已送达, 2已读 create_time DATETIME DEFAULT NOW(), INDEX idx_receiver_create (receiver_id, create_time) );分库分表策略按receiver_id哈希分 1024 片 → 查询某人的消息快使用 ShardingSphere-JDBC 自动路由7️⃣ 消息可靠性保障三大机制这是面试必考题✅ 1消息去重防止重复消费客户端发送消息带唯一 ID如 UUID 或 Snowflake服务端用SETNX msg_id_incoming:{msgId} 1 EX 3600防重避免网络超时导致客户端重发造成“一条消息发两次”✅ 2消息确认机制ACKA 发送消息 → B 收到 → 回复 ACK → A 收到 ACK → 更新为“已送达”↑如果没收到 ACK↓本地重试 3 次 → 进入离线队列类似 TCP 的 ACK 机制确保“至少送达一次”✅ 3消息补发Sync on Reconnect当用户重新上线客户端请求“请给我过去 1 小时未接收的消息”服务端从数据库或 Kafka 回放消息可结合增量拉取last_msg_id8️⃣ 已读未读功能实现方案一简单标记法适用于单设备每条消息增加字段read_status客户端显示消息时发送mark_as_read请求服务端更新数据库并通知对方“对方已读”方案二多设备同步挑战问题手机看了算不算“已读”iPad 看了呢✅ 解决方案维护每台设备的最后已读位置last_read_seq:{userId}:{deviceId}只有所有设备都读过才上报“已读”事件 技术难点最终一致性 防冲突更新9️⃣ 离线推送服务Push Service当 B 不在线时消息写入 DB Kafka触发 Push Service 向 B 的手机发通知APNs / FCM内容如“张三你好啊~”摘要式提醒 注意隐私保护不应在通知栏显示完整敏感内容可配置“免打扰”或“仅提示” 搜索聊天记录Elasticsearch将消息异步同步到 ES支持关键词搜索“找上周提到‘合同’的对话”字段建议content, sender_id, create_time, chat_with✅ 优势全文检索快支持高亮、模糊匹配沟通“好的我来逐步为您设计一个支持千万级用户的即时聊天系统。我会从需求分析、核心架构、关键技术点三个方面展开。第一需求澄清我们假设这是一个类似微信基础功能的单聊系统支持文本消息、离线推送、已读回执日活 1000 万峰值 QPS 约 5w。第二整体架构我们采用分层设计客户端通过 WebSocket 连接接入层API Gateway由 IM 核心服务处理消息路由。使用 Redis 管理在线状态Kafka 实现跨节点消息传递MySQL 分库分表存储消息Elasticsearch 支持搜索Push Service 负责离线通知。第三关键设计决策使用WebSocket而不是轮询保证实时性通过Redis 记录 userId → serverId 映射实现精准投递消息通过Kafka 异步传输提高可用性和扩展性所有消息落库并通过ACK确认机制 重试机制保证至少送达一次支持离线推送和重新连接后的消息补发已读状态通过独立上报机制更新并可通知对方。第四扩展性考虑未来可支持群聊需优化写扩散、语音视频WebRTC、消息加密端到端等功能。