Files

57 lines
3.3 KiB
JSON
Raw Permalink Normal View History

2026-09-02 18:22:20 +08:00
{
"topic": "example-topic",
"type": "scenario",
"schema_version": "1.0.0",
"generated": "2026-01-01T00:00:00Z",
"questions": [
{
"id": "dom-sub-top-sn-001",
"type": "scenario",
"difficulty": 5,
"tags": ["example", "template", "system-design"],
"question": "请分析以下技术场景并回答问题。",
"context": "某电商平台在双十一大促期间,订单量突然增长 10 倍,导致系统出现以下问题:1) 数据库响应时间从 50ms 飙升到 5s;2) 部分用户看到下单成功但实际未扣减库存;3) 消息队列积压超过 100 万条消息。系统架构为:Nginx -> Spring Boot 应用 -> MySQL 主从 -> RabbitMQ。",
"code": null,
"sub_questions": [
{
"index": 1,
"type": "short_answer",
"question": "针对数据库响应缓慢问题,请提出至少三种优化方案。",
"answer": "1) 引入 Redis 缓存热点数据,减少数据库查询;2) 对订单表进行分库分表,分散读写压力;3) 读写分离,将读请求路由到从库;4) 优化慢 SQL,添加合适索引;5) 使用连接池并调优参数。",
"keywords": ["缓存", "分库分表", "读写分离", "索引", "连接池"],
"scoring_rubric": "每提出一种合理方案得 20 分,最高 100 分。方案需具体可行,不能只说概念。"
},
{
"index": 2,
"type": "multiple_choice",
"question": "关于库存超卖问题,以下哪些是有效的解决方案?",
"options": {
"A": "使用 Redis 分布式锁控制库存扣减",
"B": "在数据库层面使用乐观锁(版本号机制)",
"C": "使用消息队列异步处理订单",
"D": "增加应用服务器数量",
"E": "使用 Redis 原子操作 DECR 实现库存预扣减"
},
"answer": ["A", "B", "E"],
"explanation": "A 正确:分布式锁可以保证同一时刻只有一个请求能修改库存。B 正确:乐观锁通过版本号防止并发更新冲突。C 不直接解决超卖:异步处理可能加剧超卖。D 不解决:增加服务器不能解决并发竞争问题。E 正确:Redis DECR 是原子操作,可以保证扣减的原子性。"
},
{
"index": 3,
"type": "single_choice",
"question": "对于消息队列积压问题,最优先的处理方式是?",
"options": {
"A": "增加消费者实例数量",
"B": "丢弃部分消息",
"C": "临时扩容消费者并优化消费逻辑",
"D": "重启消息队列服务"
},
"answer": "C",
"explanation": "C 是最佳方案:临时扩容可以快速提升消费能力,同时优化消费逻辑(如批量处理、减少 IO)可以从根本上提升吞吐量。A 不够全面;B 会导致数据丢失;D 不能解决积压问题。"
}
],
"explanation": "这是一个典型的高并发系统问题场景。核心挑战包括:数据库瓶颈、并发一致性、消息堆积。解决思路需要从缓存、数据库优化、分布式一致性、消息队列调优等多个维度综合考虑。",
"source": null,
"related": []
}
]
}