设计一个支持百万级用户、高并发访问的学习管理系统（LMS），请说明核心模块（用户管理、课程管理、作业提交、成绩统计）的设计思路，并重点阐述如何保证数据一致性（如分布式事务）和高可用性。

深圳大学宝钢股份难度：困难

答案

1) 【一句话结论】
采用微服务架构拆分核心模块，通过分布式数据库分库分表、读写分离，结合Redis缓存+消息队列异步处理，并采用Saga模式解决分布式事务，实现百万级用户、高并发下的数据一致性与高可用。

2) 【原理/概念讲解】

微服务架构：将LMS拆分为用户管理、课程管理、作业提交、成绩统计等独立服务，每个服务独立部署、扩展，通过API网关统一入口，解耦系统复杂度。
分布式事务：
- 两阶段提交（2PC）：协调者（领导者）协调所有参与者（从者），先预提交（事务准备），再提交（事务完成），保证强一致性，但阻塞时间长、性能低。
- Saga模式：将长事务拆分为多个短事务，通过消息队列（如Kafka）协调，若某步骤失败则触发补偿操作，实现最终一致性（适合高并发长事务）。
高可用设计：
- 数据库：主从复制（如MySQL主从），主库写，从库读，故障时自动切换（如Keepalived）。
- 服务：部署在K8s集群，负载均衡（Nginx）分发请求，故障时自动重启或迁移。
缓存策略：Redis缓存热点数据（如用户信息、课程列表），减少数据库压力；采用互斥锁（Redis SETNX）、限流、热点数据预热应对缓存雪崩。

3) 【对比与适用场景】

模式/组件	定义	特性	使用场景	注意点
分布式事务（2PC）	领导者协调参与者，预提交→提交	强一致性，阻塞时间长	需强一致性（如金融交易）	领导者故障导致全失败
分布式事务（Saga）	拆分长事务为短事务，消息队列协调	最终一致性，性能高，容错	长事务（如订单+库存+支付）	需保证消息可靠性与幂等性
缓存（强一致 vs 最终一致）	强一致：数据库更新后立即同步缓存；最终一致：异步更新	强一致：实时性高，但高并发下性能差；最终一致：低延迟，适合读多写少	读多写少场景（如用户信息、课程列表）	需处理缓存穿透（空值拦截）、雪崩（热点数据预热）

4) 【示例】
作业提交的Saga模式处理（伪代码）：

# 作业提交服务（服务A）
def submit_homework(user_id, course_id, content):
    # 1. 更新作业状态（课程服务B）
    result = course_service.update_homework_status(user_id, course_id, "待批")
    if not result:
        return False
    # 2. 发送消息到Kafka队列
    send_message("homework_status_update", {"user_id": user_id, "course_id": course_id, "status": "待批"})
    return True

# 课程服务（服务B）处理消息
def handle_homework_status_update(msg):
    user_id, course_id, status = msg
    if status == "待批":
        # 3. 扣减资源（库存服务C）
        result = inventory_service.deduct_resource(user_id, course_id)
        if result:
            send_message("resource_deduct_success", {"user_id": user_id, "course_id": course_id})
        else:
            send_message("resource_deduct_fail", {"user_id": user_id, "course_id": course_id})

5) 【面试口播版答案】
（约90秒）
“面试官您好，设计百万级用户、高并发的LMS，核心思路是微服务拆分+分布式架构。首先，模块拆分为用户管理、课程管理、作业提交、成绩统计等独立服务，通过API网关统一入口。数据层用MySQL分库分表（用户表按ID分片，课程表按课程ID分片），读写分离（主库写，从库读）。缓存用Redis缓存热点数据，减少数据库压力。对于高并发长事务（如作业提交），采用Saga模式：作业提交服务先更新作业状态为‘待批’，发送消息到消息队列，课程服务处理扣减资源并返回消息，若失败则补偿。高可用方面，服务部署在K8s集群，负载均衡Nginx分发请求，数据库主从复制，故障时自动切换。总结来说，通过微服务解耦、分布式数据库分库分表、缓存+消息队列异步处理，结合Saga模式保证事务一致性，实现高并发下的高可用。”

6) 【追问清单】

问：分布式事务具体怎么实现？比如两阶段提交的流程？
回答要点：两阶段提交中，协调者发起预提交（参与者响应后回执），再发起提交（若参与者失败则回滚）。实际中因阻塞问题，推荐Saga模式，通过异步消息和补偿机制解决。
问：如何保证缓存与数据库的一致性？比如作业提交后，缓存数据更新？
回答要点：采用最终一致性，作业提交后先更新数据库，再更新缓存（Redis SETNX或发布订阅），若缓存更新失败则重试，同时设置过期时间。
问：高并发下，用户登录的并发量很大，如何保证性能？
回答要点：用户登录用JWT+Redis缓存用户状态（用户ID+token），Redis短时间过期；数据库用户表加索引（用户名、邮箱），主从复制。
问：如果作业提交服务宕机，消息队列中的消息丢失怎么办？
回答要点：消息队列选Kafka（持久化到磁盘），服务重启后重新消费；作业提交服务实现幂等性（根据作业ID判断是否已提交）。

7) 【常见坑/雷区】

直接用两阶段提交处理长事务：导致性能瓶颈，阻塞其他请求。
忽略缓存雪崩：所有缓存数据同时过期，大量请求打到数据库。
分库分表策略不合理：用户表按ID分片，查询时跨分片，导致查询失败。
分布式锁使用不当：Redis SETNX加锁未设置过期时间，导致死锁。
忽略消息队列幂等性：重复处理消息，导致资源重复扣减。