设计一个前端系统，支持百万级用户同时访问，如何保证系统的可扩展性和稳定性？请从架构、技术选型、监控等方面说明。
Tencent软件开发-前端开发方向难度：困难
答案
1) 【一句话结论】
采用微服务架构拆分业务，结合CDN、负载均衡、缓存、消息队列等分布式技术，通过水平扩展、容错机制和实时监控，确保百万级并发下的系统可扩展性与稳定性。
2) 【原理/概念讲解】
老师会解释系统架构分层：前端层（CDN加速静态资源，负载均衡分发请求）、应用层（微服务拆分，如用户服务、订单服务，独立部署）、数据层（分布式数据库分库分表，Redis缓存热点数据，消息队列处理异步任务）。关键技术原理：
- 负载均衡：Nginx/HAProxy根据算法（轮询、权重、IP哈希）分发请求，避免单点过载。
- CDN：将静态资源缓存到边缘节点，用户请求先到离得最近的节点，减少源站压力。
- 缓存：Redis作为缓存层，解决数据库压力，通过缓存热点数据（如用户信息、商品列表），但需处理缓存雪崩（分布式限流）、击穿（设置互斥锁）、穿透（布隆过滤器）。
- 消息队列：Kafka/RabbitMQ解耦服务，如用户下单后，订单服务将订单信息写入队列，库存服务异步消费，避免服务阻塞。
- 数据库分库分表：水平拆分大表，如用户表按ID分库，订单表按时间分表，结合ShardingSphere等工具，提升数据库读写能力。
类比：CDN像快递中转站，缓存是本地仓库，消息队列是订单处理队列，微服务是独立的小工厂，各自负责一部分，协同工作。
3) 【对比与适用场景】
| 对比维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 定义 | 整个应用为一个单体，所有模块耦合在一起 | 将应用拆分为多个独立的服务，每个服务负责单一业务功能 |
| 扩展性 | 难以水平扩展，整体性能受限于单机资源 | 水平扩展，每个服务独立部署，根据负载调整资源 |
| 灵活性 | 模块间耦合度高，修改一个模块需全量部署 | 模块解耦，独立开发、部署、扩展 |
| 适用场景 | 小型应用，业务复杂度低 | 大型复杂系统，业务模块多且独立 |
| 注意点 | 部署复杂，故障影响全局 | 服务间通信成本高，需考虑服务发现、注册 |
4) 【示例】
用户访问登录页面（静态资源由CDN返回），请求后端用户服务登录接口。流程：
- 请求到达Nginx负载均衡器，按轮询分发到后端服务器。
- 后端用户服务检查Redis缓存：若用户信息存在（缓存命中），直接返回；否则查询数据库（缓存未命中），更新Redis缓存（设置过期时间）。
- 登录成功后，用户服务将用户状态写入Redis（如用户会话ID），并可能通过Kafka发送用户登录事件（异步处理日志、分析）。
- 数据库层面，用户表按ID分库（如库1存储ID 1-1000，库2存储1001-2000），订单表按时间分表（如表1存储2024年数据，表2存储2023年数据），通过ShardingSphere实现分库分表。
伪代码示例（请求流程）：
GET /api/user/login?username=xxx&password=xxx
后端处理：
# 负载均衡分发后
if redis.get(user_id) is not None:
return jsonify({'status': 'success', 'token': token})
else:
user = db.query(User).filter_by(username=username, password=password).first()
if user:
redis.set(user_id, user.to_dict(), ex=3600) # 缓存
return jsonify({'status': 'success', 'token': token})
else:
return jsonify({'status': 'error', 'message': '用户名或密码错误'})
5) 【面试口播版答案】
“面试官您好，针对百万级用户并发，我会从架构、技术选型、监控三方面设计系统。首先，架构上采用微服务拆分，比如用户、订单、商品服务独立部署，通过负载均衡（如Nginx）分发请求，避免单点过载。然后，技术选型上，静态资源用CDN加速，缓存热点数据用Redis，解决数据库压力；异步任务用Kafka，解耦服务，比如下单后订单服务写入队列，库存服务异步消费，避免阻塞。数据层用分库分表（如ShardingSphere），水平扩展数据库。监控方面，用Prometheus+Grafana监控请求延迟、错误率，用ELK收集日志，设置告警（如QPS超过阈值）。核心思路是通过分布式技术拆分压力，水平扩展资源，容错处理故障，确保系统稳定。”
6) 【追问清单】
- 问：数据库分库分表的具体方案？答：按业务分库（如用户库、订单库），按时间分表（如订单表按月分表），用ShardingSphere实现，避免单表过大。
- 问：如何处理缓存雪崩？答：设置分布式限流（如Sentinel），缓存过期时间随机化，或者用Redis集群+读写分离。
- 问：服务降级怎么做？答：根据QPS、错误率设置熔断器（如Hystrix），当服务超时或错误率超过阈值，返回默认值或空结果。
- 问：监控指标有哪些？答：请求延迟（P99）、错误率、QPS、缓存命中率、数据库连接数等。
- 问：如何保证数据一致性？答：分布式事务（如Seata），或者最终一致性（如消息队列确认机制）。
7) 【常见坑/雷区】
- 坑1：只说架构不提具体技术细节，比如只说微服务，不说负载均衡、缓存的具体方案，显得不具体。
- 坑2：忽略缓存问题，比如没提缓存雪崩、击穿、穿透的解决方案，面试官会追问这些细节。
- 坑3：没有考虑异步处理，比如所有请求都同步处理，导致服务阻塞，无法应对高并发。
- 坑4：数据库分库分表方案不明确，比如只说分表，不说如何处理跨表查询，或者分库分表工具。
- 坑5：监控指标不具体，比如只说监控，不说具体用哪些工具（如Prometheus、ELK），或者指标如何设置告警。