2025下半年高级软件水平考试《系统架构设计师(案例分析)》真题及答案

2025下半年高级软件水平考试《系统架构设计师(案例分析)》练习题及答案一、系统质量属性与架构权衡案例分析【背景材料】某城商行新一代核心系统建设进入架构选型阶段，业务方提出“秒杀类理财发售”场景：1.发售期3分钟，预估120万用户同时抢购5亿元额度；2.不允许超卖，不允许库存为负；3.交易成功率≥99.9%，P99延迟≤300ms；4.监管要求7年内交易记录不可篡改；5.系统需支持灰度发布，故障回滚时间≤30s。架构委员会给出两套候选架构：A.传统单体+OracleRAC+ActiveMQ；B.微服务+自研分布式库存服务+Kafka+MySQLGroupReplication+区块链存证。【问题1】（8分）请用ATAM方法列出两套架构在性能、可用性、可修改性、安全性四个质量属性场景下的主要权衡点，并以“质量属性架构策略风险权衡”四元组形式呈现，至少8组。【答案与解析】1.性能架构策略：A采用本地SQL悲观锁；风险：Oracle单节点CPU飙升；权衡：牺牲可扩展性换取强一致性。2.性能架构策略：B采用Redis分片+Lua脚本扣减；风险：Redis热点Key；权衡：用最终一致性换高吞吐。3.可用性架构策略：A用RAC双活；风险：脑裂导致库存重复扣减；权衡：降低分区容错能力换一致性。4.可用性架构策略：B用Kafka异步消息；风险：消费者积压；权衡：提升分区容错但增加延迟。5.可修改性架构策略：A单体EAR包；风险：代码耦合；权衡：降低开发成本但延长发布周期。6.可修改性架构策略：B微服务+领域拆分；风险：接口版本爆炸；权衡：提升独立演进却增加运维复杂度。7.安全性架构策略：A用数据库审计；风险：DBA可篡改；权衡：简化实现但无法满足7年不可篡改。8.安全性架构策略：B用Fabric区块链存证；风险：TPS仅2万；权衡：提升可信性但成为性能瓶颈。【评分要点】每四元组1分，写出8组得8分；若缺少“权衡”扣0.5分。【问题2】（7分）针对“不允许超卖”这一硬约束，B架构中分布式库存服务设计了“预扣+超时回补”机制：1.预扣使用RedisLua脚本保证原子性；2.预扣成功后发送Kafka消息，订单服务消费后异步落库；3.若5分钟未收到订单落库成功消息，则自动回补。请画出时序图，并指出在网络分区P场景下可能产生超卖的异常时序，给出改进方案。【答案与解析】时序图（文字描述）：用户→库存服务:抢购请求库存服务→Redis:EVAL(lua,key,args)Redis→库存服务:返回剩余库存库存服务→Kafka:send(preorder)订单服务→Kafka:poll订单服务→MySQL:INSERT(order)MySQL→订单服务:OK订单服务→Kafka:send(result)库存服务→Kafka:pollresult异常时序（分区P）：T1预扣成功；T2网络分区，订单服务收不到preorder；T3库存服务等待5min后回补；T4分区恢复，订单服务重试，此时库存已回补，再次扣减成功，导致总扣减>总库存。改进：1.预扣记录持久化到MySQL库存扣减表，状态为PRE，利用唯一索引防重；2.回补时检查该PRE记录是否已转为CONFIRMED；3.引入全局事务ID（XID）贯穿Redis、Kafka、MySQL，利用MySQL的“select…forupdate”对XID行级锁，确保回补与确认串行化。【评分要点】时序3分，异常2分，改进2分；若未指出“分区恢复后重试”扣1分。【问题3】（5分）监管要求7年不可篡改，B架构采用Fabric区块链。请计算：1.若每笔交易存证0.5KB，5亿元额度、单笔1万元，共5万笔，需占多少磁盘？2.Fabric每区块最大100KB，每块约200笔，5万笔需多少块？3.若采用LevelDB索引+快照，每年新增3万笔，7年后累计索引膨胀率约30%，评估7年后磁盘占用。【答案】1.5万笔×0.5KB=25MB；2.5万/200=250块；3.7年累计21万笔，原始10.5MB，索引10.5×30%=3.15MB，合计13.65MB，远小于1TB商用盘，可接受。【解析】重点考察候选人能否把业务交易量转化为链上存储，理解区块容量与索引膨胀。二、分布式缓存与数据一致性案例分析【背景材料】某短视频平台“点赞数”实时展示，日活1.2亿，平均每秒8万次点赞，峰值30万QPS。架构如下：1.客户端→API网关→点赞服务；2.点赞服务写RedisCluster，采用masterslave+哨兵；3.异步线程每5s批量写MySQL；4.缓存淘汰策略：Redis用allkeyslru，TTL1h；5.展示服务读Redis，未命中读MySQL并回填。【问题1】（6分）在主从异步复制场景下，主节点宕机，slave被哨兵提升为newmaster，但旧master有部分未同步写，导致点赞数丢失。请给出“丢失窗口”计算公式，并计算当主从延迟200ms、点赞峰值30万QPS时，最大丢失点赞数。【答案】丢失窗口=主从延迟200ms；最大丢失数=30万×0.2=6万。【解析】公式1分，计算1分；指出“异步复制”本质1分；给出“半同步复制”或“wait1”可降低窗口3分。【问题2】（6分）为消除丢失，架构组引入RediSearch模块做“点赞索引”，并提出强一致方案：1.使用Redlock对资源加锁；2.双写Redis与MySQL，采用“写MySQL成功后再写Redis”顺序；3.若Redis写失败，同步删除缓存并返回失败。请指出该方案在并发10万QPS下可能产生的性能瓶颈，并给出量化估算。【答案】瓶颈1：Redlock需5个master节点，每次点赞5次RTT，平均5ms，10万QPS需500万次RTT/s，集群网卡带宽约1Gbps，单包200byte，理论上限65万包/s，可支撑但延迟飙升；瓶颈2：双写MySQL，单行insertRTT2ms，10万QPS需20万磁盘IOPS，远超NVMe单盘8万IOPS；瓶颈3：Redis写失败触发缓存删除，缓存穿透回源MySQL，峰值放大3倍，30万QPS打崩DB。【解析】量化估算需给出RTT、IOPS、带宽三维度，每点2分。【问题3】（8分）给出“最终一致+补偿”方案，要求：1.不降低点赞接口性能；2.丢失数<10/分钟；3.支持幂等。请画出架构图（文字描述），并说明补偿流程。【答案】架构：客户端→API网关→点赞服务→Kafka（点赞事件）→Flink消费→Redis增量累加→定时对账→MySQL。补偿：1.Flink检查点5s，故障恢复时重放Kafka；2.对账任务每1min比较Redis与MySQL差值，若差值>10，触发补偿更新Redis；3.点赞接口传入幂等Token，Redis用SETNX保证同一Token只处理一次。【解析】架构4分，补偿2分，幂等2分；若未使用Kafka事务消息扣2分。三、微服务拆分与领域建模案例分析【背景材料】某医药电商平台包含：商品、库存、营销、订单、支付、履约、售后、会员、评论、搜索9个模块。原单体应用代码280万行，需求交付周期8周，线上事故月均5次。CTO决定微服务拆分，业务目标：1.需求交付周期≤2周；2.线上事故≤1次/月；3.支持多租户SaaS化输出。【问题1】（10分）请用DDD战略设计给出限界上下文划分结果，并说明每个上下文的聚合根、领域事件、通用语言，至少7个上下文。【答案】1.商品上下文：聚合根SKU、类目；事件“商品上架”；语言“SPU、SKU、规格”；2.库存上下文：聚合根WarehouseStock、ReservedStock；事件“库存预扣”；语言“可用库存、预扣库存”；3.营销上下文：聚合根Coupon、Promotion；事件“优惠券领取”；语言“门槛、面额、适用商品”；4.订单上下文：聚合根Order、OrderLine；事件“订单已创建”；语言“下单、拆单、主订单”；5.支付上下文：聚合根Payment、Refund；事件“支付成功”；语言“支付单、渠道、流水”；6.履约上下文：聚合根DeliveryOrder、Package；事件“发货”；语言“拣货、复核、出库”；7.售后上下文：聚合根AfterSale、Return；事件“退货收货”；语言“售后单、退款单”；8.会员上下文：聚合根Member、Address；事件“会员注册”；语言“成长值、积分”；9.搜索上下文：聚合根SearchIndex；事件“索引更新”；语言“关键词、权重”。【解析】每上下文1分，聚合根0.5分，事件0.5分；若缺少“多租户”语言扣2分。【问题2】（8分）针对“下单”场景，识别跨上下文交互，用上下文映射给出集成关系，并指出采用“开放主机服务+发布语言”还是“共享内核”，说明理由。【答案】交互：订单→库存：预扣库存；订单→营销：核销优惠券；订单→支付：创建支付单；订单→商品：校验上架状态。映射：订单库存：OHS+PL（RESTAPI+JSON），因库存需对外SaaS输出；订单营销：OHS+PL；订单支付：OHS+PL；订单商品：共享内核，因商品代码被订单频繁引用，且变化频率低。理由：共享内核减少重复对象转换，但需团队紧密协同；OHS+PL保证边界清晰。【解析】映射4分，理由4分；若全部共享内核扣3分。【问题3】（6分）拆分后首次上线出现“订单服务”调用“库存服务”超时，导致用户下单失败。日志显示库存服务RT99ms，订单服务设置超时100ms，重试1次。实际失败率0.8%。请用Little定律与排队论估算：若目标失败率<0.1%，超时阈值应设为多少？（假设服务到达服从泊松过程，服务时间服从指数分布，利用率ρ=0.7）【答案】M/M/1模型，ρ=0.7，平均排队等待时间Wq=ρ/(μλ)=0.7/(1/0.0991/0.099×0.7)=0.231ms；总响应时间=服务时间+排队≈99+23.1=122.1ms；重试1次，失败概率=P(T>100)=e^(100/122.1)=0.44，单次失败0.44，重试后失败0.44×0.44=0.1936，与观测0.8%不符，说明重试放大；目标失败率0.1%，则P(T>t)=0.003（开方），t=122.1×ln(0.003)=658ms；故超时阈值应设为660ms。【解析】模型2分，计算3分，结论1分；若未用排队论扣4分。四、云原生架构与成本优化案例分析【背景材料】某社交App采用Kubernetes+AWS，微服务42个，Pod平均280个，日常CPU利用率18%，内存利用率35%，月度账单9.8万美元，其中EC2占72%。CTO要求半年内降本30%，不得影响可用性。【问题1】（6分）请用VerticalPodAutoscaler（VPA）与HorizontalPodAutoscaler（HPA）混合策略，给出量化步骤，估算可节省CPU资源多少？【答案】1.VPA分析历史7天，发现80%时段CPU请求overprovision60%，可将request从1000m降至400m；2.HPA基于CPU70%阈值，扩容，日常280Pod可缩至280×0.4/0.7=160Pod；3.合计CPU节省=(1000400)×280=168核，换算c5.large2vCPU，节省84实例；4.账单EC2部分9.8×0.72=7.06万，节省84×0.085×24×30≈5.15万/月，降幅5.15/9.8=52.6%，超目标。【解析】步骤3分，量化3分；若未考虑HPA与VPA叠加扣2分。【问题2】（6分】部分服务为有状态Redis，原使用AWSElasticCache主从，成本1.2万/月。现考虑自管RedisonEBS+Spot实例，请给出SLA权衡与成本对比，并判断是否值得替换。【答案】自管架构：3节点+Sentinel，Spot价格0.006/小时，ondemand0.05/小时，每月成本3×0.006×24×30=12.96美元，EBS100GBgp3每月8.5美元，合计21.46美元；原ElasticCache1200美元；节省1178美元，降本98%；SLA：Spot中断概率2%，通过Sentinel30s完成故障转移，可用性99.75%，低于ElasticCache99.9%；权衡：若业务可接受5分钟/月中断，则值得替换；否则保留。【解析】成本3分，SLA3分；未给出Sentinel故障转移时间扣2分。【问题3】（8分）团队决定采用Karpenter动态节点组，请设计“ProvisionNode”CRD模板，要求：1.支持多AZ打散；2.优先选择AMD实例；3.若Spot中断，30s内完成重调度；4.节点最大生命周期24h，强制滚动。【答案】```yamlapiVersion:karpenter.sh/v1alpha5kind:Provisionermetadata:name:socialappspec:requirements:key:topology.kubernetes.io/zoneoperator:Invalues:["useast1a","useast1b","useast1c"]key:kubernetes.io/archoperator:Invalues:["amd64"]key:karpenter.sh/capacitytypeoperator:Invalues:["spot","ondemand"]limits:resources:cpu:2000memory:4000GittlSecondsUntilExpired:86400ttlSecondsAfterEmpty:30```【解析】每要求2分，共8分；若未设置ttlSecondsUntilExpired扣2分。五、高可用架构与故障演练案例分析【背景材料】某互联网支付公司“代付”系统，日均1200万笔，峰值5万TPS，SLA要求99.99%，RPO=0，RTO≤30s。架构：双活数据中心A/B，距离80km，专线延迟3ms，MySQL5.7双向复制，应用层无状态，流量网关基于DNS权重50:50。【问题1】（10分】请给出“数据库双向复制”场景下，出现“双写冲突”的3种典型case，并给出检测与解决策略。【答案】Case1：同一订单同时更新状态为