设计一个高并发用户登录与课程选课系统，需要考虑用户认证、会话管理、缓存策略、数据库分片等，如何保证系统在高并发下的性能和稳定性？
深圳大学中建土木难度：中等
答案
1) 【一句话结论】
核心是通过分布式架构（负载均衡、缓存、数据库分片）结合缓存策略（击穿/雪崩防护）与分布式锁机制，实现高并发下的性能与稳定性，各组件协同保障用户认证、会话管理、选课流程的可靠性。
2) 【原理/概念讲解】
老师口吻，解释关键概念：
- 负载均衡：前端部署负载均衡器（如Nginx），将用户请求分发到后端多个服务实例，避免单点故障，提高并发处理能力（类比：像交通枢纽，把车流分散到多个路口，避免拥堵）。
- 用户认证：高并发下用JWT（无状态，通过签名验证身份，支持刷新机制避免Token过期后用户操作中断）；或Token+Redis会话（有状态，需分布式存储会话，避免单点故障）。
- 会话管理：传统Session存储在服务器，高并发下服务器压力大会崩溃，需用Redis分布式存储Session ID与用户信息，多服务器共享会话（类比：把用户“座位卡”存到共享仓库，所有服务器都能查）。
- 缓存策略：缓存分层（Redis为一级缓存，数据库为二级），热点数据（如热门课程、用户个人信息）提前预热到缓存，减少数据库压力；防击穿用互斥锁+空值缓存（先锁再查，若缓存为空则缓存空值并加锁，避免大量请求同时击穿数据库），防雪崩用随机过期时间或热点数据预热（避免大量缓存同时过期）。
- 数据库分片：水平分片（按业务维度拆分表，如课程表按课程ID分片），将大表拆分为多个小表，分散数据库压力，提升单表性能；跨分片查询需额外处理（如分片路由器合并数据，类比：把一个大仓库分成多个小仓库，每个小仓库负责部分商品，查询时汇总各仓库数据）。
- 分布式锁：选课等业务用Redis分布式锁（如SETNX），避免高并发下重复选课，确保数据一致性（类比：抢票时用锁，确保每人只能买一张，避免重复购买）。
3) 【对比与适用场景】
| 组件/策略 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 负载均衡器（如Nginx） | 前端请求分发组件 | 将请求分发到后端多个服务实例，提高可用性和并发处理能力 | 高并发请求的入口 | 需配置健康检查，避免分发到故障实例 |
| Redis缓存 | 分布式内存数据库 | 低延迟，支持高并发读写，适合热点数据 | 用户认证Token、Session、热点课程信息 | 需防击穿（互斥锁+空值缓存）、雪崩（随机过期） |
| 本地缓存（如Guava Cache） | 应用进程内缓存 | 速度快，无网络开销 | 单机非核心数据 | 高并发下内存溢出风险 |
| 数据库水平分片（按课程ID） | 按业务维度拆分大表为多个小表 | 分散单表压力，提升单表性能 | 大规模课程表、选课表 | 跨分片查询需额外处理，分片键选择影响热点数据分布 |
| 分布式锁（Redis SETNX） | 防止高并发下重复操作 | 轻量级，高并发下性能较好 | 选课、库存扣减等业务 | 锁超时设置需合理，避免死锁 |
4) 【示例】
用户登录流程（伪代码）：
- 前端发送POST请求
/api/login，参数：username, password。 - 认证服务验证用户名密码，成功则生成JWT Token（含用户ID、过期时间、刷新令牌）。
- 返回Token给前端（如
{"token": "eyJ...", "refreshToken": "..."}）。 - 后续请求携带Token（Header:
Authorization: Bearer <token>）。 - 服务层拦截请求，从Redis验证Token（或解析JWT签名），若有效则从Redis获取用户信息（
redis.hgetall(userId)）。
选课流程（含分布式锁）：
- 前端发送POST请求
/api/course/select，参数：courseId, userId。 - 服务层先尝试获取Redis分布式锁（
lockKey = "select:course:" + courseId + ":" + userId，redis.setnx(lockKey, userId, EX 10s)）。 - 锁成功则查询数据库分片（通过课程ID路由到对应分片，如课程ID 1-1000在分片1，1001-2000在分片2）：
- 查询课程表分片：
db.selectFrom(courseShard1, courseId)。 - 检查用户是否已选（
select count(*) from course_select where courseId=? and userId=?）。
- 查询课程表分片：
- 若未选，执行插入：
db.insertInto(courseSelectShard1, courseId, userId)。 - 释放锁：
redis.del(lockKey)。 - 若锁失败，重试或返回错误（如“选课失败，请稍后重试”）。
5) 【面试口播版答案】
面试官您好，针对高并发用户登录与课程选课系统，核心是通过分布式架构（负载均衡、缓存、数据库分片）结合缓存策略与分布式锁，实现性能与稳定性。用户认证采用JWT无状态机制，避免Token过期后用户操作中断；会话管理用Redis分布式存储，解决高并发下Session服务器崩溃。缓存策略上，Redis作为一级缓存，对热门课程、用户信息等热点数据提前预热，同时用互斥锁+空值缓存防缓存击穿，随机过期时间防雪崩。数据库按课程ID水平分片，分散选课表压力，跨分片查询用路由器合并数据。选课流程加Redis分布式锁，避免重复选课，确保数据一致性。这样各组件协同保障高并发下的可靠性。
6) 【追问清单】
- 问题1：如何保证Session ID的唯一性和安全性？
回答要点：用UUID生成Session ID，结合Redis SETNX原子操作确保唯一，JWT签名时加入用户信息防篡改。 - 问题2：数据库分片后如何处理跨分片查询（如统计用户选课总数）？
回答要点：通过分片路由器聚合各分片数据，或使用中间件合并结果。 - 问题3：缓存击穿/雪崩的具体实现细节？
回答要点：击穿用互斥锁+空值缓存，雪崩用随机过期时间或热点数据预热。 - 问题4：选课流程中分布式锁的选型？
回答要点：Redis适合高并发，Zookeeper适合复杂锁，这里推荐Redis SETNX实现轻量级锁。 - 问题5：消息队列在选课流程中的作用？
回答要点：异步处理选课业务，避免数据库瞬时高并发，提升系统响应速度。
7) 【常见坑/雷区】
- 坑1：忽略负载均衡导致单点故障，高并发下服务崩溃。
- 坑2：数据库分片未按业务维度拆分，热点课程分片压力过大。
- 坑3：缓存未设置过期策略，导致用户信息未更新（如课程价格变动）。
- 坑4：认证方式选择不当，如Session在高并发下性能差，或JWT未考虑刷新机制。
- 坑5：未处理跨分片查询，导致统计等业务失败。