正确答案：设计一个支持千万级用户同时在线的即时通讯系统需要从架构设计、通信协议、消息存储与同步、扩展性、可靠性、安全性和性能优化等多个维度综合考虑。核心方案包括采用分布式微服务架构、使用高效的长连接管理（如基于 WebSocket 或自研 TCP 协议）、引入消息队列解耦服务、利用分布式缓存和数据库分片技术，并通过网关层、接入层、逻辑层、存储层的分层设计实现高并发、低延迟的消息传递。解答思路： 1. 明确需求：千万级用户在线意味着系统需支持每秒数十万甚至上百万的消息吞吐，且要求低延迟（通常<200ms）、高可用（99.99% SLA）。 2. 拆解系统功能模块：包括用户连接管理、消息收发、好友关系、群组管理、离线消息、消息存储、推送机制等。 3. 选择合适的技术栈和架构模式：采用分布式的水平扩展架构，避免单点瓶颈。 4. 针对关键问题设计解决方案：如长连接维持、心跳机制、消息可靠投递、断线重连、消息去重、顺序保证等。 5. 考虑容灾、监控、降级策略以保障系统稳定性。深度知识讲解：一、整体架构分层设计 1. 接入层（Access Layer） - 功能：负责维护客户端的长连接（TCP/WebSocket），处理网络IO。 - 技术选型：可使用自研基于 Netty 的高性能网络框架，或采用开源方案如 Pushpin、Nginx + WebSocket。 - 关键点：每个接入节点维护数百万连接，需使用事件驱动模型（Reactor 模式），支持 EPOLL/NIO 提升 IO 并发能力。 - 连接状态管理：通过内存中的 ConcurrentHashMap 或类似结构保存 uid -> channel 映射。伪代码示例（Netty 中的 Channel 管理）： ``` public class ConnectionManager { private static final Map userChannels = new ConcurrentHashMap<>(); public static void addUser(long userId, Channel channel) { userChannels.put(userId, channel); } public static void removeUser(long userId) { userChannels.remove(userId); } public static Channel getChannel(long userId) { return userChannels.get(userId); } } ``` 2. 网关层（Gateway Layer） - 功能：路由请求到后端服务，统一鉴权、限流、熔断。 - 实现方式：基于 gRPC Gateway 或自定义协议转发。 - 支持动态扩容，配合注册中心（如 Nacos、Consul）实现服务发现。 3. 逻辑层（Logic Service） - 包括：登录认证服务、消息处理服务、好友服务、群组服务等。 - 微服务拆分：按业务边界划分服务，降低耦合。 - 使用 RPC 框架（如 Dubbo、gRPC）进行服务间调用。 4. 存储层（Storage Layer） - 用户信息：MySQL 分库分表（按 user_id 哈希），主从复制。 - 消息存储： - 在线消息：不落盘，直接内存转发。 - 离线消息：写入消息队列并持久化到数据库。 - 消息表设计：msg_id, from_uid, to_uid, content, timestamp, status - 分表策略：按接收方 user_id 取模或时间范围分表（如每月一张表）。 - 缓存层：Redis Cluster 存储用户状态、会话 token、最近联系人、未读计数等。 5. 消息队列（Message Queue） - 使用 Kafka 或 Pulsar 承接异步消息流转，削峰填谷。 - 场景：离线消息写入、通知广播、日志收集。 - 优势：高吞吐（百万TPS）、持久化、多订阅者消费。二、核心机制详解 1. 长连接管理与心跳保活 - 客户端每隔 30s 发送一次 ping，服务端回应 pong。 - 若连续 3 次未收到心跳，则判定连接断开，触发下线流程。 - 心跳包轻量化，避免占用过多带宽。 2. 消息投递保证（QoS） - QoS 0：最多一次（fire-and-forget） - QoS 1：至少一次（带确认重传） - QoS 2：恰好一次（复杂握手，适用于金融场景）常用实现： - 客户端发送消息时携带 client_msg_id（UUID） - 服务端收到后返回 ack(server_msg_id) - 若超时未收到 ack，客户端重发（需去重机制）去重机制： - 服务端使用 Redis Set 或 BloomFilter 记录已处理的 client_msg_id（有效期设为24小时） 3. 消息可达性与离线推送 - 判断目标用户是否在线：查询 Redis：HGETALL user_status:uid，包含 online_status, gateway_node 等字段。 - 在线：通过 gateway 将消息推送到对应连接。 - 离线： - 将消息写入 Kafka → 异步落库 - 同时写入离线消息队列 - 触发 APNs/FCM 推送（移动端） 4. 群聊消息扩散策略 - 写扩散（Write Fanout）：发送时遍历所有成员，每人一份消息写入其 inbox。优点：读取快；缺点：大群发消息压力大。 - 读扩散（Read Fanout）：消息只存一份，拉取时合并历史消息。优点：写入轻量；缺点：读取慢，难以排序。 - 混合模式（推荐）：小群（<100人）用写扩散；大群（>100人）用读扩散 + 热点缓存。 5. 分布式唯一 ID 生成 - 要求：全局唯一、趋势递增、高性能。 - 方案： - Snowflake 算法：64位ID = 时间戳(41bit) + 机器ID(10bit) + 序号(12bit) - 改进版：美团 Leaf、百度 UidGenerator Snowflake 伪代码： ``` class SnowflakeIdGenerator { private long lastTimestamp = 0L; private long sequence = 0L; private long workerId; private long datacenterId; synchronized long nextId() { long timestamp = System.currentTimeMillis(); if (timestamp < lastTimestamp) throw new RuntimeException("Clock moved backwards"); if (timestamp == lastTimestamp) { sequence = (sequence + 1) & 0xFFF; if (sequence == 0) { timestamp = waitNextMillis(timestamp); } } else { sequence = 0; } lastTimestamp = timestamp; return ((timestamp - TWEPOCH) << 22) | (datacenterId << 17) | (workerId << 12) | sequence; } } ``` 6. 水平扩展与负载均衡 - 接入层：LVS + Keepalived 做四层负载，或 F5。 - 应用层：Nginx 或 Envoy 做七层路由。 - 数据分片： - 用户分片：user_id % N → 分配到不同 DB 或 Redis 节点 - 消息队列分区：Kafka topic 分多个 partition，提高并行度 7. 安全机制 - 传输加密：TLS 1.3 加密通信 - 身份认证：OAuth2 + JWT Token，每次请求校验 - 防刷限流：令牌桶算法（Guava RateLimiter）或滑动窗口限流 - 敏感词过滤：集成 NLP 引擎或规则引擎 8. 监控与运维 - 全链路追踪：SkyWalking / Zipkin - 日志系统：ELK（Elasticsearch + Logstash + Kibana） - 告警系统：Prometheus + Grafana + Alertmanager - 自动扩缩容：Kubernetes HPA 根据 CPU/连接数自动伸缩 Pod 三、典型数据流举例：单聊消息发送 1. 客户端 A 登录： - 向 Auth Service 验证 token - 成功后建立 WebSocket 连接至某个 Gateway Node - Gateway 注册该连接至 Redis：SET user_gateway:{uid} {node_id} 2. A 发送消息给 B： - A 发送 {to: B, msg: "hello", client_msg_id: "uuid1"} - Gateway 转发至 Message Service - Message Service 查询 Redis 判断 B 是否在线 - 在线：查找 B 所在 Gateway Node，通过内部 RPC 推送消息最终由 B 的 Gateway 写回 WebSocket 连接 - 离线：将消息写入 Kafka → 异步落库 + 触发 FCM 推送 - 返回 ack 给 A 3. B 上线后： - 拉取离线消息（Pull Model） - 或服务端主动推送积压消息（Push on Reconnect）四、性能估算（粗略） - 千万级在线：假设平均每用户每分钟发1条消息 → 10^7 / 60 ≈ 16.7万条/秒 - 每条消息平均 200 字节 → 总吞吐约 3.3 GB/s - 需要数百台服务器集群支撑，Kafka 集群至少 10+ broker 五、可扩展知识点 1. 协议优化： - 使用 Protobuf 替代 JSON 减少序列化体积 - 自定义二进制协议提升解析效率 2. 边缘计算： - 在 CDN 边缘节点部署轻量接入层，降低延迟 3. 多数据中心部署： - 多地多活架构，避免单机房故障 - 使用 Gossip 协议同步状态 4. 冷热数据分离： - 热数据（最近7天）放 Redis - 冷数据（历史消息）归档至 HBase / S3 总结：构建千万级 IM 系统是一个复杂的系统工程，必须围绕“高并发、低延迟、高可用”三大目标展开设计。关键技术包括： - 分布式长连接管理（Netty + Reactor） - 消息中间件解耦（Kafka/Pulsar） - 分布式缓存与数据库分片（Redis Cluster + MySQL Sharding） - 可靠消息投递机制（ACK + 重试 + 去重） - 水平扩展架构（微服务 + Kubernetes）该系统不仅考验编码能力，更考察对分布式系统的整体理解和实战经验。建议面试者掌握 Netty、Redis、Kafka、ZooKeeper 等核心技术原理，并能结合实际场景灵活运用。

shopee后端二面面经

全站热榜

创作者周榜