2025年上半年系统架构设计师真题及答案解析

2025年上半年系统架构设计师练习题及答案解析一、单项选择题（每题1分，共30分。每题只有一个最符合题意的选项）1.某电商平台在“618”大促期间将订单流量按用户尾号哈希到32个分片库，大促后发现尾号7的库CPU飙高，其余库负载正常。造成该现象的最可能原因是A.哈希算法存在雪崩效应B.用户尾号分布极度不均C.热点商品被大量秒杀D.分片键选取错误导致数据倾斜答案：C解析：哈希分片本身均匀，但热点商品被同一尾号用户集中抢购，导致该分片瞬时QPS过高，属于“热点键”问题，与哈希算法无关。2.在领域驱动设计（DDD）中，以下关于“聚合根”的说法正确的是A.聚合根必须暴露所有内部实体给应用层B.聚合根负责保证整个聚合的业务不变量C.一个限界上下文只能有一个聚合根D.聚合根之间通过数据库外键直接关联答案：B解析：聚合根是聚合的入口与一致性边界，负责维护聚合内业务规则；A违反封装，C无此限制，D应通过ID引用而非外键。3.某系统采用两阶段提交（2PC）协议，协调者在prepare阶段收到3个参与者中的2个“同意”后即进入commit阶段，结果第3个参与者在commit阶段超时未响应。此时系统一致性状态为A.已一致提交B.已一致回滚C.不一致：部分提交部分回滚D.不一致：全部回滚答案：A解析：2PC进入commit阶段即视为事务通过，协调者会重试超时节点，最终所有节点都会提交，保证一致性。4.某微服务使用SpringCloudGateway，运维需要在线变更路由规则而不重启网关。最合理的实现方式是A.修改yml文件并重启B.将规则存入Nacos，通过@RefreshScope动态刷新C.将规则存入MySQL，网关定时全表扫描D.使用SpringCloudBus广播RefreshEvent答案：B解析：Nacos作为配置中心支持动态推送，@RefreshScope可实时刷新路由定义，无需重启；D需额外组件，B最轻量。5.某系统使用Kafka3.5，副本因子3，min.insync.replicas=2，acks=all，某分区ISR={0,1,2}，此时Broker2宕机，生产者继续发送消息，以下说法正确的是A.新写入可能丢失B.新写入一定成功C.新写入一定失败D.新写入可能失败但已提交消息不丢失答案：D解析：ISR剩余{0,1}满足min.insync.replicas=2，acks=all仍可写入；已提交消息至少存在于两个副本，Broker2宕机不会丢数据。6.某团队采用“API优先”策略，使用OpenAPI3.0描述契约，前端与后端并行开发。为降低集成风险，最合适的测试策略是A.等后端完成后统一联调B.使用WireMock基于契约构建Mock服务C.前端直连开发库表测试D.使用Postman手工对比JSON答案：B解析：WireMock可按OpenAPI契约生成Mock，提前暴露接口不匹配问题，实现真正并行。7.某系统使用MySQL8.0，读QPS4万、写QPS1万，主从延迟稳定在200ms以内。为将读延迟降至10ms以内，且不增加应用复杂度，首选方案是A.引入Redis缓存B.使用MySQLGroupReplicationC.升级磁盘为NVMeD.增加从库数量答案：A解析：缓存可屏蔽200ms主从延迟，且对应用透明；B需改复制模式，C仅提升单机性能，D无法消除延迟。8.某Serverless平台采用Knative，并发策略设为“软限制10”，某容器实例内存512MB，实测并发到15时RT陡增，最可能瓶颈是A.虚拟CPU限额B.单线程模型C.内存不足触发OOMD.软限制只是建议，无实际作用答案：A解析：Knative软限制超限仍可调度，但CPUThrottling加剧，RT上升；内存未达上限不会OOM。9.在ISO/IEC25010质量模型中，“易安装性”属于A.功能适合性B.可靠性C.易用性D.可移植性答案：D解析：可移植性子特性包括适应性、易安装性、共存性、可替换性。10.某金融核心系统采用“TCC”分布式事务模式，Try阶段冻结账户金额，Cancel阶段解冻。若Cancel幂等设计不当，可能出现A.脏读B.超售C.重复解冻导致资金流失D.幻读答案：C解析：Cancel重复执行会多次解冻，造成资金风险；需记录冻结流水并做幂等校验。11.某系统使用Elasticsearch8.11，集群节点角色为：3master，10data_hot，5data_warm，2data_cold。为降低暖节点磁盘占用，最佳ILM策略是A.30天后forcemerge到1段并迁移到warm，90天后迁移coldB.1天后迁移warm并收缩分片为1，7天后迁移coldC.30天后删除D.写入时即指定warm节点答案：A解析：forcemerge可减少段数量，降低暖节点磁盘占用；收缩分片需额外资源，A最平衡。12.某云原生应用使用OPAGatekeeper做准入控制，要求所有Pod必须挂载名为“audit”的EmptyDir卷，应使用的ConstraintTemplate类型为A.K8sPSPHostNetworkB.K8sRequiredLabelsC.K8sRequiredVolumesD.K8sUniqueIngressHost答案：C解析：K8sRequiredVolumes可校验卷声明，匹配EmptyDir名称。13.某系统使用gRPC，proto文件新增字段“stringtrace_id=7”，客户端未升级，服务器已升级，为保证兼容需A.字段编号改为90001B.将trace_id改为requiredC.字段保持optional且编号不变D.使用JSON传输答案：C解析：Proto3默认字段可选，新增编号不重复使用即可保证向后兼容。14.某团队采用“事件风暴”建模，识别出“支付成功”事件后，下一步应A.直接设计数据库表B.寻找导致该事件的命令与聚合C.绘制UML时序图D.编写API文档答案：B解析：事件风暴顺序：事件→命令→聚合→边界，B为正确步骤。15.某系统使用Prometheus+Grafana，指标http_request_duration_seconds为Histogram，如需统计99线，应使用A.rate(http_request_duration_seconds[5m])B.histogram_quantile(0.99,http_request_duration_seconds_bucket)C.http_request_duration_seconds{quantile=”0.99”}D.avg_over_time(http_request_duration_seconds[5m])答案：B解析：Histogram需histogram_quantile函数计算分位数；Summary才自带quantile标签。16.某系统采用“蓝绿发布”，切换流量后新版本出现内存泄漏，回滚耗时10分钟，引发SLA违约。为缩短回滚时间，最佳改进是A.改用滚动发布B.预热Pod并保留热备池，DNS秒级切换C.降低Heap大小D.增加健康检查间隔答案：B解析：保持热备池+DNS/API网关秒级切换，可将回滚时间降至秒级；滚动发布无法解决已泄漏实例。17.某系统使用Cilium的eBPF实现K8s网络策略，策略如下：```yamlingress:fromEndpoints:matchLabels:{app:frontend}toPorts:port:8080```以下说法正确的是A.仅标签为frontend的Pod可访问目标8080B.同一Namespace下所有Pod均可访问C.策略无效，需加namespaceSelectorD.仅NodePort可访问答案：A解析：Cilium默认按标签匹配，不限制Namespace，除非显式namespaceSelector。18.某系统使用Java21，启用虚拟线程（VirtualThread）后，发现数据库连接池很快耗尽，最可能原因是A.虚拟线程数量不足B.连接池大小远小于虚拟线程数C.虚拟线程不支持JDBCD.数据库不支持虚拟线程答案：B解析：虚拟线程可创建百万级，但连接池仍为有限资源，需调大池或采用反应式驱动。19.某系统使用GitLabCI，流水线含build、unittest、sonar、dockerbuild、deploy五阶段，需保证sonar质量阈通过方可deploy，应使用A.only:variablesB.when:manualC.needs:sonarD.rules:if:$SONAR_QUALITY_GATE==“OK”答案：D解析：rules可读取Sonarwebhook写入的变量，实现质量门控。20.某系统使用OAuth2，授权码模式，授权服务器返回code后，客户端用code换token时应使用A.GET/token?code=xxxB.POST/token，body携带client_secretC.POST/token，Authorization头Basic编码client_id:secretD.将code放入Cookie答案：C解析：OAuth2规范要求POST，客户端认证可用Basic头或body，C最标准。21.某系统使用ArgoCD做GitOps，应用清单在Git仓库目录manifests/，运维误将目录改名为manifest/，ArgoCD会A.自动修正目录名B.保持最后一次同步状态C.标记应用为Unknown并停止同步D.删除集群内所有资源答案：C解析：ArgoCD无法找到路径会标记Unknown，不会主动删除资源，保障安全。22.某系统使用ClickHouse23.8，表引擎为MergeTree，按dt分区，每日3亿行，查询仅最近7天，为减少磁盘IO，最佳实践是A.设置TTL7天B.使用Prewhere替代WhereC.将分区粒度改为按月D.启用LZ4HC压缩答案：A解析：TTL自动删除过期分区，减少扫描数据量；Prewhere优化已默认启用。23.某系统使用Nginx转发WebSocket，需支持1万并发长连接，应调整的内核参数为A.net.ipv4.tcp_tw_reuseB.net.core.somaxconnC.net.ipv4.ip_local_port_rangeD.filter.nf_conntrack_max答案：B解析：somaxconn控制监听队列长度，万级并发需调大；长连接不耗端口，A/C无关。24.某系统使用MongoDB7，事务跨3个分片，为保证强一致性，应使用A.readConcern:majority,writeConcern:majorityB.readConcern:local,writeConcern:1C.禁用分片D.使用因果一致性会话答案：A解析：多分片事务需majority读写，确保持久化到多数节点；因果一致性无法替代。25.某系统使用SpringRetry，配置@Retryable(maxAttempts=5,backoff=@Backoff(delay=1000,multiplier=2))，第3次重试间隔为A.1000msB.2000msC.3000msD.4000ms答案：B解析：退避算法1→2→4秒，第3次重试间隔为2秒（首次1秒，第二次2秒，第三次4秒，题目问“第3次重试间隔”即第2次等待时长）。26.某系统使用Istio1.20，VirtualService按权重90:10灰度，但监控发现比例偏差大，最可能遗漏A.DestinationRule未定义subsetB.未启用mTLSC.sidecar注入失败D.未配置circuitbreaker答案：A解析：subset未定义导致VirtualService权重失效，流量全部流向默认版本。27.某系统使用Raft协议，集群5节点，网络分区导致{1,2}与{3,4,5}隔离，此时A.任意分区均可提交日志B.仅{3,4,5}可提交C.系统停止服务D.需人工干预答案：B解析：Raft需多数派，{3,4,5}满足3票，可继续提交；{1,2}无法选主。28.某系统使用Flutter开发移动应用，需调用原生AndroidSDK，应使用A.PlatformChannelB.JNIC.WebViewD.ReactNativebridge答案：A解析：Flutter通过PlatformChannel与原生通信，B仅适用于Android原生开发。29.某系统使用GitFlow，release/1.4.0分支已创建，此时发现master分支有严重Bug，应A.直接在release分支修复后合并B.在hotfix分支修复，合并到master与developC.回滚masterD.忽略，等release发布再说答案：B解析：GitFlow规定线上Bug走hotfix分支，保证master随时可发布。30.某系统使用SLSA框架保障供应链安全，要求构建过程可审计，需满足A.SLSALevel0B.SLSALevel1C.SLSALevel2D.SLSALevel3答案：C解析：Level2要求构建在可信构建服务中完成并生成签名证明，满足可审计。二、案例分析题（共5题，每题10分，共50分）案例一（10分）某城商行核心系统采用“单元化+异地多活”架构，单元内采用微服务，单元间数据最终一致。现有以下场景：1.客户A在上海单元开立账户，余额1000元；2.客户A立即飞往北京，在北京单元通过ATM取现200元；3.上海单元到账短信延迟5分钟后收到。问题：1.画出单元间数据同步时序图，标注“写冲突窗口”。（4分）2.给出一种避免“重复入账”或“重复扣款”的机制，需说明幂等键设计、校验位置与并发控制。（6分）答案：1.时序图：t0：上海单元开户写本地Account表，余额=1000，生成事件AccountCreated（version=1，unit=SH）；t1：事件通过DTS同步至北京单元，延迟≈200ms；t2：客户在北京ATM发起Withdraw200，北京单元本地无余额，查缓存得1000，允许扣款，本地余额=800，生成事件Withdrawed（version=2，unit=BJ）；t3：Withdrawed事件回传上海，延迟≈200ms；t4：上海收到事件更新余额=800；写冲突窗口：t0～t1（200ms），此时北京单元看不到开户数据，需走“读异地不可写”或“延迟拒绝”策略。2.幂等机制：幂等键：业务单号+单元编码+全局唯一序号（如Snowflake）。校验位置：服务入口网关层与账务聚合根。并发控制：a.采用“乐观锁”：Account表加version字段，事件携带version_expect，更新时whereversion=expect；b.事件幂等表：event_id主键，消费端先判重；c.取款交易走“异地申请本地确认”两步：北京单元先申请冻结，上海单元确认后扣款，确保冲突窗口内拒绝异地写。案例二（10分）某短视频公司采用CDN+对象存储+转码集群架构，上传链路为：APP→边缘节点→源站→对象存储→转码→回写。高峰期间出现“上传成功但播放404”投诉。问题：1.列出3种可能根因。（3分）2.给出可观测性方案，需包含指标、日志、追踪各1项关键项。（3分）3.设计一种“上传即播放”低延迟方案，目标端到延迟<3秒，需说明转码策略与回源机制。（4分）答案：1.根因：a.转码任务队列积压，导致文件未生成；b.CDN边缘缓存404，长TTL导致持续回源失败；c.上传回调丢失，数据库状态未更新，播放服务直接404。2.可观测：指标：upload_success_rate_5min（标签：边缘节点、错误码）；日志：边缘节点Nginx日志需记录xrequestid、xtraceid、upstream_response_time；追踪：Jaeger链路覆盖“上传→转码→CDN预热”全流程，span含upload_id。3.低延迟方案：采用“双码率”策略：边缘节点在上传同时生成H.264480p低码文件并立即回写CDN，高码文件异步转码；上传完成后由边缘节点通过HTTP/3PUSH将低码文件推至CDN二级缓存，回源优先级：低码→高码；播放端先请求低码，延迟<1.5秒，后台异步拉取高码，2.5秒内切换至高清，整体<3秒。案例三（10分）某IoT平台每秒接收800万条设备上报，峰值QPS12万，消息大小0.5KB，采用Kafka集群，分区数300，副本因子3，retention=24h。问题：1.计算每日磁盘占用量（含副本），给出公式与结果。（3分）2.发现消费端频繁触发rebalance，导致延迟飙高，列出2种调优手段。（4分）3.设计“冷数据”归档至OSS的方案，需满足查询近7天热数据<100ms，7天后可接受分钟级，说明索引与存储格式。（3分）答案：1.磁盘占用：单条0.5KB，日总量=800万×86400×0.5KB≈34.56TB；含副本×3，总计103.68TB。2.调优：a.提高session.timeout.ms=30s，erval.ms=3s，减少误判；b.采用cooperativestickyassignor，并调大max.poll.records=500，降低poll间隔。3.归档：采用Kafka→KafkaConnectS3Sink，按小时分区写入Parquet，文件名含dt=yyyyMMddHH；热数据保留在Kafka7天，冷数据转存OSS并建立Hive外表，按device_id、dt建索引；查询近7天直接读Kafka，延迟<100ms；7天后通过Presto查询OSS，分钟级返回。案例四（10分）某电商大促采用“库存预扣”模式，流程：下单→Redis预扣→支付→确认扣减数据库。大促期间出现“超卖20件”事故。问题：1.给出超卖的技术根因。（2分）2.设计“防超卖”一致性方案，需包含Redis与DB同步策略、回滚机制。（5分）3.说明如何在大促前通过“混沌工程”验证该方案。（3分）答案：1.根因：并发下Redis预扣与DB校验非原子，且Redis扣减后未及时回滚，导致多个订单通过校验。2.方案：a.采用Lua脚本保证“查库存→预扣”原子，脚本返回剩余库存；b.预扣同时在MySQL插入预售流水（状态=PRE，唯一索引order_id），DB层加悲观锁select…forupdate；c.支付成功后更新流水状态=CONFIRM，并扣减真实库存；d.未支付超时（30分钟）关闭订单