设计一个支持百万级用户、高并发访问的在线作业提交与批改系统，需要考虑实时反馈、数据一致性和系统扩展性。请从系统架构、数据库设计、缓存策略、消息队列应用等方面阐述设计思路。
答案
1) 【一句话结论】采用微服务架构拆分核心模块，通过数据库分库分表、分布式缓存（Redis）和消息队列（Kafka）协同工作，结合WebSocket实现实时反馈，确保百万级并发下的系统扩展性与数据一致性。
2) 【原理/概念讲解】
老师：咱们先拆解核心需求——百万级用户、高并发访问、实时反馈、数据一致性和扩展性。首先，系统架构上，得用微服务拆分模块（比如作业提交、作业批改、用户管理、实时反馈），降低耦合，方便独立扩容。比如“作业提交”服务负责接收用户请求，把作业元数据（文件名、提交时间）存入Redis（作为读写缓存，低延迟），同时触发消息队列；“作业批改”服务异步消费消息，调用AI模型完成批改，结果同步到Redis和消息队列；“实时反馈”通过WebSocket长连接，让用户端订阅消息，实时接收结果。
然后看数据库设计，针对作业表、用户表等高频访问表，按业务或时间分片（比如作业表按提交时间分库，用户表按地域分库），避免单库瓶颈。
接着是缓存策略，Redis作为分布式缓存，存储热点数据（如用户信息、热门作业），用布隆过滤器过滤无效查询（比如用户查询不存在作业时，直接返回，减少数据库压力）；同时设置缓存过期时间，避免数据不一致。
再看消息队列，作业提交后先入队列，批改服务异步处理，避免阻塞主流程，保证实时性；Kafka作为消息队列，支持高吞吐和持久化，确保消息不丢失。
3) 【对比与适用场景】
以消息队列为例（Kafka vs RabbitMQ）：
| 对比项 | Kafka | RabbitMQ |
|---|---|---|
| 定义 | 分布式流处理平台 | 企业级消息中间件 |
| 特性 | 高吞吐、持久化、多消费者 | 队列模型、支持多种消息模式 |
| 使用场景 | 实时数据流处理、日志收集 | 微服务间解耦、任务调度 |
| 注意点 | 需要持久化存储，启动慢 | 队列模式可能导致消息积压 |
4) 【示例】
用户提交作业流程（伪代码）：
- 用户提交作业（
POST /submit?assignmentId=1&userId=1001，文件流+元数据）。 - 前端验证后，将作业元数据（文件名、提交时间）写入Redis（
redis.set(作业ID, 元数据)），同时上传文件到对象存储（如OSS）。 - 后端将“作业提交事件”推送到Kafka主题“assignment_submit”（消息体：
{作业ID, 用户ID, 文件路径}）。 - 批改服务（Worker）消费Kafka消息，从OSS下载文件，调用AI模型批改，结果写入Redis（
redis.set(作业ID, 结果)）和Kafka主题“assignment_grade”（消息体：{作业ID, 分数, 反馈}）。 - 用户通过WebSocket连接，订阅“assignment_grade”主题，实时接收批改结果，前端展示。
5) 【面试口播版答案】
面试官您好，针对百万级用户、高并发访问的在线作业系统，我的设计思路是采用微服务架构拆分核心模块，通过数据库分库分表、分布式缓存和消息队列协同工作，结合WebSocket实现实时反馈。具体来说，系统拆分为作业提交、作业批改、用户管理、实时反馈等微服务，作业提交服务处理用户请求，将作业元数据存入Redis并触发消息队列；批改服务异步消费消息，调用AI模型完成批改，结果同步到Redis和消息队列；用户端通过WebSocket订阅消息，实时获取反馈。数据库方面，作业表按时间分片，用户表按地域分库，避免单表压力。缓存策略上，Redis作为读写缓存，存储热点数据，布隆过滤器过滤无效查询。消息队列使用Kafka，保证异步处理的高吞吐和可靠性。这样设计既能应对百万级并发，又能保证实时反馈和数据一致性。
6) 【追问清单】
- 问题：实时反馈的具体实现，如何保证低延迟？
回答要点：通过WebSocket长连接，批改完成后直接推送消息，减少轮询延迟；同时优化批改服务性能，如使用多线程并发处理作业。 - 问题：数据一致性如何保证？比如作业提交后，用户看到的状态和实际批改结果是否一致？
回答要点：采用最终一致性，通过消息队列确保批改结果同步到Redis和用户端，同时设置状态锁（如Redis的SETNX），防止重复提交。 - 问题：系统扩展性如何处理？比如当用户量激增时，如何快速扩容？
回答要点：微服务独立部署，可通过容器化（如Docker+Kubernetes）快速扩容；数据库分库分表，新增分片即可扩容；缓存集群自动扩容。 - 问题：缓存策略中，如何应对缓存击穿和雪崩？
回答要点：缓存击穿用布隆过滤器预过滤，雪崩用Redis集群和限流（如Nginx限流）。 - 问题：消息队列的可靠性如何保障？比如消息丢失或重复消费？
回答要点：Kafka持久化存储，确保消息不丢失；消费端幂等处理（如根据作业ID检查是否已处理过）。
7) 【常见坑/雷区】
- 单表过大导致数据库性能瓶颈，未做分库分表。
- 缓存未设置过期时间，导致数据不一致（如用户修改作业后，缓存未更新）。
- 实时反馈依赖轮询，导致高延迟，未使用WebSocket。
- 消息队列未考虑可靠性，导致批改结果丢失。
- 系统模块耦合度高，扩展性差，未采用微服务架构。