设计一个支持百万级用户同时在线的社交应用（如微信聊天界面）的前端架构，如何保证低延迟、高可用？请从请求优化、数据缓存、资源加载、服务端交互等方面阐述方案。
Tencent软件开发-前端开发方向难度：中等
答案
1) 【一句话结论】
核心是通过请求层（HTTP/2多路复用、合并请求）、分层缓存（浏览器+Redis+CDN）、资源智能加载（预加载+懒加载+移动端优化）、服务端实时通信（WebSocket+Kafka消息队列）及高可用架构（集群+负载均衡+故障转移），实现百万级并发下的低延迟与高可用。
2) 【原理/概念讲解】
老师：百万级用户同时在线的核心挑战是网络延迟、服务器负载和数据同步。我们从四个维度设计方案：
- 请求优化：减少网络往返。比如合并多个小请求为一个大请求（减少HTTP头重复传输），启用HTTP/2多路复用（类似管道，同时传输多个请求/响应，减少TCP连接开销），降低轮询频率（从高频轮询改为长连接+心跳检测，比如每30秒检测一次连接状态）。
- 数据缓存：分层缓存降低请求压力。浏览器缓存静态资源（CSS/JS）通过Cache-Control和ETag，服务端用Redis缓存热门聊天记录、用户在线状态（设置TTL，如5分钟过期），CDN缓存边缘节点静态资源（减少用户到服务器的距离，比如腾讯云CDN）。同时，消息持久化用Kafka：消息生产者将消息写入Kafka，消费者（服务端）从Kafka读取并推送给用户，确保百万级消息的可靠传输和分发（Kafka的分区、副本机制保证高可用）。
- 资源加载：预加载关键资源（如聊天界面CSS/JS），懒加载图片/附件（滚动时加载），根据资源对首屏体验的影响权重（如聊天界面权重w=10，加载时间t=0.5s，则P=20；图片权重w=1，t=2s，P=0.5，优先预加载聊天界面资源），动态调整机制：根据用户行为日志（如用户常访问的聊天对象、最近打开的界面）实时更新资源权重，比如用户频繁打开与A用户的聊天，则A用户的聊天资源权重提升。
- 服务端交互：WebSocket用于实时消息推送（低延迟，无轮询往返），结合REST/GraphQL获取非实时数据（如用户资料、聊天历史），服务端采用集群+负载均衡（如Nginx+多节点），故障转移（主节点故障时自动切换到备用节点，通过健康检查）。
3) 【对比与适用场景】
| 策略/方式 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| HTTP/2多路复用 | HTTP/2协议下的请求/响应复用机制 | 同时传输多个请求/响应，减少TCP连接开销，提升并发性能 | 需要低延迟的场景（如社交应用实时交互） | 需前端与服务端均支持HTTP/2 |
| HTTP/1.1 | 传统HTTP协议 | 每个请求/响应需独立TCP连接，连接数限制（如浏览器6-8个） | 非实时数据传输（如静态页面） | 连接数多时性能下降 |
| Kafka消息队列 | 分布式消息系统 | 高吞吐、持久化、分区复制 | 实时消息分发（百万级消息） | 需配置分区数、副本因子，避免单点故障 |
| Redis缓存 | 分布式内存数据库 | 高速读写，支持数据过期 | 热门数据（聊天记录、用户状态） | 需设置TTL，避免缓存雪崩（随机过期时间） |
| CDN缓存 | 边缘节点缓存 | 减少用户到服务器的距离 | 静态资源（大文件、热门页面） | 需配置缓存规则，避免动态内容被缓存 |
| 预加载 | 提前请求资源 | 提升关键资源加载速度 | 关键资源（聊天界面、消息列表） | 需控制预加载资源数量，避免带宽占用 |
4) 【示例】
- Kafka消息持久化流程：
生产者（服务端）将消息写入Kafka主题（如“chat_messages”），Kafka将消息持久化到磁盘（日志文件），消费者（服务端）从主题中读取消息并推送给WebSocket连接的用户（比如通过WebSocket的onmessage事件）。假设百万级用户，Kafka的分区数设置为100，每个分区处理1万并发，副本因子为3，确保高可用。 - 预加载权重计算：
伪代码：
动态调整：根据用户行为日志（如用户最近30分钟打开的聊天对象列表），更新资源权重，比如用户频繁打开与“张三”的聊天，则“张三”的聊天资源权重提升至15。function calculatePriority(resource) { const weight = resource.type === 'chat' ? 10 : 1; // 聊天资源权重高 const loadTime = resource.size / 1000; // 假设单位KB，计算加载时间（ms） return weight / loadTime; // 权重/加载时间，值越大优先级越高 }
5) 【面试口播版答案】
面试官您好，针对百万级用户同时在线的社交应用，我的核心方案是围绕“低延迟”和“高可用”从四个维度优化：首先是请求优化，通过合并小请求、启用HTTP/2多路复用减少网络往返，降低轮询频率；然后是数据缓存，采用浏览器缓存静态资源、Redis缓存热门数据（TTL 5分钟）、CDN缓存边缘资源，同时用Kafka作为消息队列处理百万级消息的可靠传输和分发；接着是资源加载，对聊天界面等关键资源预加载（根据权重计算优先级，动态调整权重），非关键资源懒加载，并加入移动端优化（如图片压缩、适配不同屏幕）；最后是服务端交互，用WebSocket实现实时消息推送（心跳检测+指数退连），结合REST/GraphQL获取非实时数据，服务端通过集群+负载均衡（如Nginx）和故障转移保障高可用。这样能确保百万并发下低延迟和高可用。
6) 【追问清单】
- 问题：如何保障服务端的高可用？
回答要点：服务端采用集群部署（多节点），通过负载均衡（如Nginx）分发请求，故障节点自动切换（如主节点故障时切换到备用节点，通过健康检查）。 - 问题：Kafka消息队列如何保证消息可靠传输？
回答要点：Kafka通过分区、副本机制，确保消息不丢失，比如副本因子为3，即使一个节点故障，消息仍可通过副本恢复。 - 问题：预加载的权重动态调整机制具体如何实现？
回答要点：通过用户行为日志（如最近打开的聊天对象、点击频率），实时更新资源权重，比如用户频繁打开某聊天，则该聊天资源权重提升。 - 问题：移动端性能优化有哪些具体措施？
回答要点：图片压缩（如WebP格式）、懒加载（滚动时加载）、资源适配（根据屏幕尺寸加载不同分辨率图片）、减少HTTP请求（合并CSS/JS）。
7) 【常见坑/雷区】
- 忽略消息持久化与Kafka，导致消息丢失或延迟；
- 缓存策略未考虑数据一致性，比如Redis缓存过期时未同步服务端数据；
- 资源预加载优先级固定，未动态调整，导致非关键资源占用带宽；
- WebSocket未处理断线，影响实时消息推送；
- 未考虑移动端性能，如图片未适配导致加载慢，影响用户体验。