在考试季，系统面临高并发访问（如成绩查询、考试报名），如何保障系统稳定？请说明负载均衡、缓存策略及容灾方案。
三峡大学专任教师难度：中等
答案
1) 【一句话结论】考试季高并发下，通过负载均衡分散请求压力、缓存策略减少数据库访问、容灾方案保障业务连续性，需结合数据库连接池优化、资源规划及数据一致性措施，三者协同保障系统稳定。
2) 【原理/概念讲解】
- 负载均衡：通过反向代理（如Nginx）将大量请求分发至多台服务器，避免单点过载。类比“城市交通枢纽”，主干道拥堵时通过支路分流，防止单点拥堵。
- 缓存策略：将热点数据（如成绩查询结果）存入Redis等缓存，减少数据库压力。热点数据识别需通过访问频率统计（如Redis的zset记录访问次数），动态缓存高频数据。
- 容灾方案：采用主备或多活架构，主库处理写操作，备库同步数据。多活架构需通过半同步复制（减少binlog同步延迟）保障数据一致性，故障时快速切换。
3) 【对比与适用场景】
| 类型/策略 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 负载均衡（Nginx） | 反向代理+负载均衡 | 功能丰富，配置灵活，支持轮询/加权轮询等算法 | Web应用高并发 | 需配置upstream模块，结合健康检查 |
| 负载均衡（LVS） | 专有负载均衡 | 高性能，适合大规模 | 大型系统 | 需内核支持，配置复杂 |
| 缓存策略（LRU） | 最近最少使用 | 淘汰最久未使用项 | 访问频率变化大的数据 | 可能导致冷启动 |
| 缓存策略（基于访问频率） | 动态缓存高频数据 | 根据访问次数排序，优先缓存热点 | 高并发热点数据 | 需实时统计访问频率 |
| 容灾方案（主备） | 主节点处理写，备节点热备 | 切换时间短，备节点利用率低 | 对切换时间要求高的场景 | 需健康检查机制 |
| 容灾方案（多活） | 多节点同时处理请求 | 切换时间短，数据同步成本高 | 对高可用要求高的场景 | 需数据同步机制（如半同步复制） |
4) 【示例】
- 负载均衡（Nginx配置）：
upstream exam_backends { server 192.168.1.1:8080 weight=3; # 加权轮询，性能高的服务器权重更高 server 192.168.1.2:8080 weight=2; server 192.168.1.3:8080 weight=1; health_check; } server { listen 80; server_name exam.tsdx.com; location / { proxy_pass http://exam_backends; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } - 数据库连接池（HikariCP配置）：
HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:mysql://db1:3306/exam_db"); config.setUsername("user"); config.setPassword("pass"); config.setMaximumPoolSize(100); // 最大连接数 config.setConnectionTimeout(10000); // 连接超时10秒 HikariDataSource ds = new HikariDataSource(config); - 热点数据识别（Redis zset示例）：
def get_hot_score(student_id): key = "score:hot" # 记录访问次数 redis.zadd(key, student_id, time.time()) # 超时1小时 redis.expire(key, 3600) # 获取Top 100热点数据 hot_ids = redis.zrevrange(key, 0, 99) # 缓存热点数据 for sid in hot_ids: score = redis.get(f"score:{sid}") if score: redis.setex(f"score:{sid}", 3600, score) return redis.get(f"score:{student_id}") - MySQL半同步复制配置（主库）：
[mysqld] server-id = 1 log-bin = /var/log/mysql/mysql-bin.log binlog-do-db = exam_system semisync_master = 1 # 开启半同步复制
5) 【面试口播版答案】
考试季高并发时，保障系统稳定需从三方面入手：负载均衡、缓存策略、容灾方案。首先，负载均衡用Nginx将请求分发到多台服务器，配置upstream用加权轮询，根据服务器性能分配权重，避免单机过载。其次，缓存策略用Redis缓存成绩查询等热点数据，通过访问频率统计（如zset记录访问次数）识别热点，设置1小时TTL，查询时先看缓存，命中则直接返回，减少数据库压力。最后，容灾方案采用MySQL主备架构，主库处理写操作，备库通过半同步复制同步数据（减少binlog同步延迟），故障时通过健康检查快速切换到备库，保证业务不中断。同时配置数据库连接池（如HikariCP设置最大连接数100，连接超时10秒），避免数据库连接耗尽。三者结合，能有效应对高并发，保障系统稳定。
6) 【追问清单】
- 问：数据库连接池配置中，最大连接数如何确定？
答：根据服务器CPU/内存调整，通常设为服务器核心数的2-3倍，避免资源浪费。 - 问：热点数据识别具体如何实现？
答：用Redis的zset存储每个数据的访问次数，每次访问时zadd增加计数，并设置1小时过期时间，定期排序取Top N作为热点数据缓存。 - 问：容灾方案中半同步复制如何减少延迟？
答：配置MySQL的semisync_master=1，使备库在收到binlog后立即确认，减少同步延迟，保证数据一致性。 - 问：负载均衡算法选择轮询和加权轮询的区别？
答：轮询按顺序分发请求，适合资源均衡；加权轮询根据服务器性能分配权重，性能高的服务器处理更多请求，提升整体吞吐量。
7) 【常见坑/雷区】
- 数据库连接池未配置最大连接数/超时时间，导致连接耗尽。
- 缓存未设置热点数据识别，导致缓存命中率低，数据库压力仍大。
- 容灾方案未考虑半同步复制，导致数据同步延迟影响业务。
- 未明确系统资源（如服务器数量、数据库容量），方案可信度不足。
- 缓存策略未设置过期时间，导致数据不一致或缓存穿透。