东南大学教务系统在开学季选课期间通常面临高并发压力（如并发请求达数万次/秒）。请描述一个典型的教务系统架构，并说明如何处理高并发请求，保证数据一致性和系统稳定性？

1) 【一句话结论】
典型的教务系统采用微服务+分布式架构，通过负载均衡、缓存、消息队列、数据库分库分表等组件，结合限流熔断、异步处理等机制，有效应对高并发，保障数据一致性与系统稳定性。

2) 【原理/概念讲解】
老师口吻解释关键组件作用：

• 负载均衡：像交通枢纽，通过Nginx等工具分发请求到多个服务实例，避免单点过载。
• 微服务拆分：将系统拆为选课服务、用户服务、课程服务等独立模块，独立部署、扩展，降低耦合。
• 分布式缓存（Redis）：存储热门课程余量等热点数据，减少数据库压力（类比“超市货架”，减少对后端仓库的访问）。
• 数据库分库分表：水平拆分选课记录表（分库/分表），分散数据量，提升读写性能。
• 消息队列（如Kafka）：解耦服务间通信（如选课成功后异步通知），避免阻塞主流程。
• 限流熔断：通过Sentinel等工具，当请求超阈值时限制流量，防止系统崩溃（漏桶/令牌桶算法）。
• 异步处理：将非实时操作（日志、统计）放入任务队列，提高响应速度。

3) 【对比与适用场景】

架构模式	定义	特性	使用场景	注意点
单体架构	整个系统为单一应用，代码库、数据库集中管理	代码耦合度高，扩展困难，高并发下易瓶颈	小规模系统，开发周期短	不适合高并发，难以水平扩展
微服务架构	系统拆分为多个独立服务，每个服务负责单一功能	服务解耦，独立部署、扩展，技术异构	大规模系统，高并发、高可用	服务间通信复杂，需统一治理
缓存策略	内存缓存（本地）vs 分布式缓存（Redis）	本地缓存：速度快，故障时数据丢失；分布式：高可用，数据共享	热门数据缓存，减少数据库压力	需考虑缓存击穿/雪崩/穿透
数据库分库分表	水平拆分数据库表（分库）或表（分表）	分散数据量，提高读写性能	数据量大的表（如选课记录）	分片键设计复杂，跨分片查询困难

4) 【示例】
选课请求流程（伪代码）：

def select_course(user_id, course_id):
    # 1. 检查Redis缓存（课程余量）
    stock = redis.get(f'course_stock:{course_id}')
    if stock and int(stock) > 0:
        redis.decr(f'course_stock:{course_id}')
        return "选课成功"
    
    # 2. 缓存未命中，查询数据库
    stock_db = db.query(f"SELECT stock FROM course WHERE id={course_id}")
    if stock_db.stock > 0:
        db.update(f"UPDATE course SET stock = stock - 1 WHERE id={course_id}")
        
        # 3. 更新缓存（缓存击穿：互斥锁+过期时间）
        with redis.lock(f'course_stock:{course_id}'):
            redis.set(f'course_stock:{course_id}', stock_db.stock - 1, ex=3600)
        
        # 4. 异步通知
        kafka_produce("course_select_success", {"user_id": user_id, "course_id": course_id})
        return "选课成功"
    else:
        return "选课失败，余量不足"

5) 【面试口播版答案】
（约90秒）
“面试官您好，针对教务系统高并发选课场景，典型的架构是采用微服务+分布式架构。首先，通过负载均衡（如Nginx）分发请求到多个服务实例，避免单点过载。然后，引入Redis作为分布式缓存，存储热门课程的余量信息，减少数据库查询压力。对于数据库，通过分库分表（水平拆分选课记录表）分散数据量。当请求过多时，使用限流熔断（如Sentinel），限制流量，防止系统崩溃。对于非实时操作（如选课成功后的通知），通过消息队列（Kafka）异步处理，解耦服务，提高响应速度。同时，通过缓存击穿（设置过期时间+互斥锁）、缓存雪崩（随机过期时间）等策略保障缓存稳定性。数据一致性方面，选课成功后，先更新数据库，再更新缓存，并通过消息队列通知，确保最终一致性。这样，系统既能应对数万次/秒的高并发，又能保证数据一致性和稳定性。”

6) 【追问清单】

• 问题1：数据库一致性如何保证？
  回答要点：采用最终一致性，通过数据库事务（ACID）保证操作原子性，缓存更新后设置过期时间，消息队列异步通知。
• 问题2：限流策略具体如何设置？
  回答要点：基于令牌桶/漏桶算法，设置QPS阈值，超过则返回429，或降级处理。
• 问题3：缓存雪崩如何应对？
  回答要点：缓存数据设置随机过期时间，避免集中过期。
• 问题4：消息队列如何保证可靠性？
  回答要点：消息持久化（Kafka的持久化存储），重试机制，死信队列处理失败消息。
• 问题5：系统监控如何保障？
  回答要点：使用Prometheus+Grafana监控请求量、响应时间、错误率，设置告警阈值。

7) 【常见坑/雷区】

• 雷区1：直接用单体架构应对高并发，导致系统瓶颈，扩展困难。
• 雷区2：忽略缓存击穿/雪崩问题，导致缓存失效时大量请求直接访问数据库，引发雪崩。
• 雷区3：数据库分库分表设计不合理，分片键选择不当，导致查询效率低或跨分片查询复杂。
• 雷区4：限流策略设置过严或过松，过严影响用户体验，过松导致系统崩溃。
• 雷区5：消息队列未考虑可靠性，导致消息丢失，影响业务流程（如选课成功后未通知用户）。