2025年软考系统设计要点试题及答案

2025年软考系统设计要点试题及答案一、单项选择题（每题2分，共20分）1.在需求分析阶段，某系统需要支持用户实时查询过去30天内的交易记录，且日均查询量超过500万次。该需求属于（）A.功能需求B.性能需求C.安全需求D.可维护需求2.某电商系统采用“前端静态资源CDN加速+应用层微服务+数据库读写分离”架构，其核心设计目标是（）A.提升可扩展性B.降低开发成本C.增强安全性D.简化部署流程3.设计关系型数据库时，若某表存在“订单ID→（用户ID，商品ID，下单时间，支付状态）”且“用户ID→用户姓名”，则该表最高满足（）A.1NFB.2NFC.3NFD.BCNF4.分布式系统中，为解决“网络分区导致节点间通信中断”问题，通常采用的一致性策略是（）A.Paxos协议B.最终一致性C.强一致性D.单调读一致性5.某医疗系统要求“患者病历数据在传输过程中必须加密，且密钥每30分钟自动轮换”，该设计属于（）A.数据完整性设计B.数据保密性设计C.数据可用性设计D.数据可追溯性设计6.设计高并发系统时，若某接口的平均响应时间为200ms，最大并发数为5000，则该接口的吞吐量约为（）（提示：吞吐量=并发数/响应时间）A.25000次/秒B.2500次/秒C.5000次/秒D.10000次/秒7.采用模型-视图-控制器（MVC）模式设计Web系统时，“用户输入验证”通常应放在（）A.模型层B.视图层C.控制器层D.服务层8.为提升系统可维护性，设计时应优先遵循的原则是（）A.高内聚低耦合B.尽可能复用第三方组件C.减少日志记录D.合并功能模块9.某物联网系统需处理百万级设备的实时数据（每秒10万条），且要求“数据丢失率低于0.01%”，最适合的消息中间件是（）A.RabbitMQB.KafkaC.RedisD.ActiveMQ10.设计容灾系统时，“RPO（恢复点目标）”主要衡量（）A.系统故障后恢复所需时间B.故障前可接受的数据丢失量C.灾备中心与主中心的距离D.灾备切换的自动化程度二、简答题（每题8分，共40分）1.简述用例图在系统设计中的作用，并说明“扩展用例”与“包含用例”的区别。2.分层架构设计中，通常分为表现层、应用层、服务层和数据层。请说明各层的核心职责，并举例说明跨层调用可能引发的问题。3.数据库设计中，如何选择合适的索引策略？请结合“用户表（用户ID，姓名，手机号，注册时间）”说明何时创建主键索引、唯一索引和普通索引。4.分布式系统中，如何解决“脑裂”问题？请列举至少3种解决方案，并说明其适用场景。5.系统性能测试中，“负载测试”与“压力测试”的区别是什么？设计性能测试用例时，应重点关注哪些指标？三、综合分析题（每题20分，共40分）（一）某在线教育平台需设计“直播课程”子系统，核心需求如下：-支持同时在线10万人观看高清直播（1080P，25fps）；-教师可实时发起答题互动（5秒内统计全班答案）；-课程结束后，提供包含观看时长、互动次数的学习报告；-需防范录屏软件盗播，支持直播流动态水印。请完成以下设计：1.画出系统架构图（用文字描述关键组件）；2.说明直播流传输的技术选型（如协议、CDN、推流/拉流方案）；3.设计答题互动的高并发处理方案（包括消息队列选型、响应延迟优化）；4.提出动态水印的实现思路（需包含水印提供、嵌入、验证流程）。（二）某银行核心交易系统需进行重构，原系统采用单体架构，存在“修改一个功能需全量部署”“数据库事务锁冲突频繁”“高峰期响应时间超过5秒”等问题。新系统要求支持“日均1000万笔交易”“交易成功率≥99.99%”“单笔交易响应时间≤200ms”。请回答：1.推荐采用哪种架构模式（如微服务、事件驱动、Serverless），并说明理由；2.设计数据库优化方案（包括分库分表策略、事务隔离级别选择、索引优化）；3.提出高可用保障措施（包括冗余部署、故障自动切换、流量限流）；4.说明如何验证系统是否满足“交易成功率≥99.99%”的要求（需包含测试方法、指标统计方式）。答案一、单项选择题1.B（实时查询的高并发量属于性能需求）2.A（微服务和读写分离主要提升扩展性）3.B（存在部分依赖：用户ID→用户姓名，不满足3NF）4.B（网络分区时强一致性难以保证，最终一致性更适用）5.B（加密和密钥轮换属于保密性设计）6.A（5000/0.2=25000次/秒）7.C（控制器负责处理用户输入和验证）8.A（高内聚低耦合是可维护性的核心原则）9.B（Kafka适合高吞吐、低丢失的实时数据处理）10.B（RPO指允许丢失的最近数据量）二、简答题1.用例图作用：通过用户与系统的交互场景，明确系统功能边界和需求范围。扩展用例（Extend）：在基础用例的特定点（扩展点）插入额外行为，如“正常支付”扩展“优惠券抵扣”；包含用例（Include）：将基础用例中重复的子行为提取为独立用例，如“支付”包含“身份验证”。2.各层职责：-表现层：处理用户交互（如Web页面、APP界面）；-应用层：协调服务层完成业务逻辑（如订单创建流程）；-服务层：提供通用业务能力（如支付服务、用户服务）；-数据层：管理数据存储与访问（如数据库、缓存）。跨层调用问题：例如表现层直接调用数据层，会导致业务逻辑分散，降低可维护性；若服务层绕过应用层被表现层调用，可能破坏业务流程的原子性。3.索引选择策略：-主键索引：必须创建（用户ID），保证数据唯一且快速定位；-唯一索引：若手机号需唯一（业务需求），为“手机号”创建唯一索引，防止重复注册；-普通索引：若频繁按“注册时间”查询（如统计月新增用户），为“注册时间”创建普通索引，加速范围查询。4.脑裂解决方案：-共享存储仲裁：通过共享存储（如NAS）判断主节点状态（适用于双机热备场景）；-心跳检测+多数派协议：节点间心跳通信，超过半数存活则认为有效（适用于分布式集群）；-第三方监控（Fencing）：引入独立监控服务，故障时切断脑裂节点的资源访问（适用于物理机集群）。5.负载测试与压力测试区别：-负载测试：逐步增加负载，验证系统在不同负载下的性能表现（如找到吞吐量拐点）；-压力测试：超过预期负载（如2倍峰值），验证系统的极限容量和崩溃点。性能测试关注指标：响应时间、吞吐量、并发数、错误率、资源利用率（CPU/内存/IO）。三、综合分析题（一）直播课程子系统设计1.系统架构关键组件：-推流端（教师侧）：OBS推流工具→推流服务器（RTMP协议）；-直播分发：CDN节点（边缘计算加速）→拉流端（HLS/FLV协议）；-互动模块：WebSocket服务器（处理答题消息）→Kafka消息队列（缓冲高并发请求）；-存储层：OSS（对象存储）存直播回放→Elasticsearch（存储互动日志）；-水印模块：动态水印提供服务→视频流处理服务器（嵌入水印）。2.直播流传输技术选型：-推流协议：RTMP（低延迟，适合实时互动）；-拉流协议：HLS（HTTP-FLV备用，兼容不同终端）；-CDN选择：支持边缘节点缓存的云厂商CDN（如阿里云CDN），降低回源率；-推流方案：教师通过OBS推流至源站，源站将流同步至CDN边缘节点；-拉流方案：用户从最近的CDN节点拉流，减少延迟。3.答题互动处理方案：-消息队列选型：Kafka（高吞吐，支持百万级消息/秒）；-流程设计：教师发起答题→WebSocket服务器广播题目→用户提交答案→Kafka分区存储（按班级ID分区）→消费者组（每个班级一个消费者）实时统计→结果返回教师端；-延迟优化：-消息压缩（LZ4算法减少传输量）；-消费者批量处理（每100条提交一次，平衡延迟与吞吐量）；-本地缓存班级在线人数（Redis存储，避免频繁查询数据库）。4.动态水印实现思路：-提供：根据用户ID、时间戳提供唯一水印内容（如“用户1234_202506011500”）；-嵌入：视频流处理服务器通过FFmpeg在I帧（关键帧）中叠加半透明水印（位置随机偏移，每秒更新）；-验证：录制内容通过OCR识别水印→提取用户ID和时间→与直播日志（存储在Elasticsearch）比对，不一致则判定盗播。（二）银行核心交易系统重构1.架构模式推荐：微服务架构。理由：-解决单体架构的全量部署问题（微服务可独立部署）；-支持按业务功能拆分（如账户服务、支付服务、清算服务）；-配合容器化（Docker）和K8s编排，提升弹性伸缩能力。2.数据库优化方案：-分库分表：按用户ID取模（如1024库），交易表按时间（月）分表（解决锁冲突和单表过大问题）；-事务隔离级别：默认读已提交（ReadCommitted），关键交易（如转账）使用可重复读（RepeatableRead），避免脏读；-索引优化：交易表创建复合索引（用户ID+交易时间），加速“用户近30天交易查询”；账户表为“账户余额”创建覆盖索引，减少回表。3.高可用保障措施：-冗余部署：每个微服务部署3个实例（跨可用区），数据库采用主从+半同步复制；-故障切换：K8s健康检查（HTTP心跳+TCP端口检测），实例异常时自动重启或迁移；数据库使用ProxySQL实现主从自动切换；-流量限流：网关层（如Nginx）对每个服务设置QPS阈值（如5000次/秒），超限请求返回429错误；业务层使用GuavaRateLimiter限制关键接口（如支付接口）的并