2025下半年高級(jí)軟件水平考試《系統(tǒng)架構(gòu)設(shè)計(jì)師(案例分析)》練習(xí)題及答案一、系統(tǒng)質(zhì)量屬性與架構(gòu)權(quán)衡案例分析【背景材料】某城商行新一代核心系統(tǒng)建設(shè)進(jìn)入架構(gòu)選型階段，業(yè)務(wù)方提出“秒殺類(lèi)理財(cái)發(fā)售”場(chǎng)景：1.發(fā)售期3分鐘，預(yù)估120萬(wàn)用戶同時(shí)搶購(gòu)5億元額度；2.不允許超賣(mài)，不允許庫(kù)存為負(fù)；3.交易成功率≥99.9%，P99延遲≤300ms；4.監(jiān)管要求7年內(nèi)交易記錄不可篡改；5.系統(tǒng)需支持灰度發(fā)布，故障回滾時(shí)間≤30s。架構(gòu)委員會(huì)給出兩套候選架構(gòu)：A.傳統(tǒng)單體+OracleRAC+ActiveMQ；B.微服務(wù)+自研分布式庫(kù)存服務(wù)+Kafka+MySQLGroupReplication+區(qū)塊鏈存證?！締?wèn)題1】（8分）請(qǐng)用ATAM方法列出兩套架構(gòu)在性能、可用性、可修改性、安全性四個(gè)質(zhì)量屬性場(chǎng)景下的主要權(quán)衡點(diǎn)，并以“質(zhì)量屬性架構(gòu)策略風(fēng)險(xiǎn)權(quán)衡”四元組形式呈現(xiàn)，至少8組?！敬鸢概c解析】1.性能架構(gòu)策略：A采用本地SQL悲觀鎖；風(fēng)險(xiǎn)：Oracle單節(jié)點(diǎn)CPU飆升；權(quán)衡：犧牲可擴(kuò)展性換取強(qiáng)一致性。2.性能架構(gòu)策略：B采用Redis分片+Lua腳本扣減；風(fēng)險(xiǎn)：Redis熱點(diǎn)Key；權(quán)衡：用最終一致性換高吞吐。3.可用性架構(gòu)策略：A用RAC雙活；風(fēng)險(xiǎn)：腦裂導(dǎo)致庫(kù)存重復(fù)扣減；權(quán)衡：降低分區(qū)容錯(cuò)能力換一致性。4.可用性架構(gòu)策略：B用Kafka異步消息；風(fēng)險(xiǎn)：消費(fèi)者積壓；權(quán)衡：提升分區(qū)容錯(cuò)但增加延遲。5.可修改性架構(gòu)策略：A單體EAR包；風(fēng)險(xiǎn)：代碼耦合；權(quán)衡：降低開(kāi)發(fā)成本但延長(zhǎng)發(fā)布周期。6.可修改性架構(gòu)策略：B微服務(wù)+領(lǐng)域拆分；風(fēng)險(xiǎn)：接口版本爆炸；權(quán)衡：提升獨(dú)立演進(jìn)卻增加運(yùn)維復(fù)雜度。7.安全性架構(gòu)策略：A用數(shù)據(jù)庫(kù)審計(jì)；風(fēng)險(xiǎn)：DBA可篡改；權(quán)衡：簡(jiǎn)化實(shí)現(xiàn)但無(wú)法滿足7年不可篡改。8.安全性架構(gòu)策略：B用Fabric區(qū)塊鏈存證；風(fēng)險(xiǎn)：TPS僅2萬(wàn)；權(quán)衡：提升可信性但成為性能瓶頸?！驹u(píng)分要點(diǎn)】每四元組1分，寫(xiě)出8組得8分；若缺少“權(quán)衡”扣0.5分?！締?wèn)題2】（7分）針對(duì)“不允許超賣(mài)”這一硬約束，B架構(gòu)中分布式庫(kù)存服務(wù)設(shè)計(jì)了“預(yù)扣+超時(shí)回補(bǔ)”機(jī)制：1.預(yù)扣使用RedisLua腳本保證原子性；2.預(yù)扣成功后發(fā)送Kafka消息，訂單服務(wù)消費(fèi)后異步落庫(kù)；3.若5分鐘未收到訂單落庫(kù)成功消息，則自動(dòng)回補(bǔ)。請(qǐng)畫(huà)出時(shí)序圖，并指出在網(wǎng)絡(luò)分區(qū)P場(chǎng)景下可能產(chǎn)生超賣(mài)的異常時(shí)序，給出改進(jìn)方案?！敬鸢概c解析】時(shí)序圖（文字描述）：用戶→庫(kù)存服務(wù):搶購(gòu)請(qǐng)求庫(kù)存服務(wù)→Redis:EVAL(lua,key,args)Redis→庫(kù)存服務(wù):返回剩余庫(kù)存庫(kù)存服務(wù)→Kafka:send(preorder)訂單服務(wù)→Kafka:poll訂單服務(wù)→MySQL:INSERT(order)MySQL→訂單服務(wù):OK訂單服務(wù)→Kafka:send(result)庫(kù)存服務(wù)→Kafka:pollresult異常時(shí)序（分區(qū)P）：T1預(yù)扣成功；T2網(wǎng)絡(luò)分區(qū)，訂單服務(wù)收不到preorder；T3庫(kù)存服務(wù)等待5min后回補(bǔ)；T4分區(qū)恢復(fù)，訂單服務(wù)重試，此時(shí)庫(kù)存已回補(bǔ)，再次扣減成功，導(dǎo)致總扣減>總庫(kù)存。改進(jìn)：1.預(yù)扣記錄持久化到MySQL庫(kù)存扣減表，狀態(tài)為PRE，利用唯一索引防重；2.回補(bǔ)時(shí)檢查該P(yáng)RE記錄是否已轉(zhuǎn)為CONFIRMED；3.引入全局事務(wù)ID（XID）貫穿Redis、Kafka、MySQL，利用MySQL的“select…forupdate”對(duì)XID行級(jí)鎖，確?；匮a(bǔ)與確認(rèn)串行化?！驹u(píng)分要點(diǎn)】時(shí)序3分，異常2分，改進(jìn)2分；若未指出“分區(qū)恢復(fù)后重試”扣1分?！締?wèn)題3】（5分）監(jiān)管要求7年不可篡改，B架構(gòu)采用Fabric區(qū)塊鏈。請(qǐng)計(jì)算：1.若每筆交易存證0.5KB，5億元額度、單筆1萬(wàn)元，共5萬(wàn)筆，需占多少磁盤(pán)？2.Fabric每區(qū)塊最大100KB，每塊約200筆，5萬(wàn)筆需多少塊？3.若采用LevelDB索引+快照，每年新增3萬(wàn)筆，7年后累計(jì)索引膨脹率約30%，評(píng)估7年后磁盤(pán)占用?！敬鸢浮?.5萬(wàn)筆×0.5KB=25MB；2.5萬(wàn)/200=250塊；3.7年累計(jì)21萬(wàn)筆，原始10.5MB，索引10.5×30%=3.15MB，合計(jì)13.65MB，遠(yuǎn)小于1TB商用盤(pán)，可接受?！窘馕觥恐攸c(diǎn)考察候選人能否把業(yè)務(wù)交易量轉(zhuǎn)化為鏈上存儲(chǔ)，理解區(qū)塊容量與索引膨脹。二、分布式緩存與數(shù)據(jù)一致性案例分析【背景材料】某短視頻平臺(tái)“點(diǎn)贊數(shù)”實(shí)時(shí)展示，日活1.2億，平均每秒8萬(wàn)次點(diǎn)贊，峰值30萬(wàn)QPS。架構(gòu)如下：1.客戶端→API網(wǎng)關(guān)→點(diǎn)贊服務(wù)；2.點(diǎn)贊服務(wù)寫(xiě)RedisCluster，采用masterslave+哨兵；3.異步線程每5s批量寫(xiě)MySQL；4.緩存淘汰策略：Redis用allkeyslru，TTL1h；5.展示服務(wù)讀Redis，未命中讀MySQL并回填。【問(wèn)題1】（6分）在主從異步復(fù)制場(chǎng)景下，主節(jié)點(diǎn)宕機(jī)，slave被哨兵提升為newmaster，但舊master有部分未同步寫(xiě)，導(dǎo)致點(diǎn)贊數(shù)丟失。請(qǐng)給出“丟失窗口”計(jì)算公式，并計(jì)算當(dāng)主從延遲200ms、點(diǎn)贊峰值30萬(wàn)QPS時(shí)，最大丟失點(diǎn)贊數(shù)?！敬鸢浮縼G失窗口=主從延遲200ms；最大丟失數(shù)=30萬(wàn)×0.2=6萬(wàn)?！窘馕觥抗?分，計(jì)算1分；指出“異步復(fù)制”本質(zhì)1分；給出“半同步復(fù)制”或“wait1”可降低窗口3分?！締?wèn)題2】（6分）為消除丟失，架構(gòu)組引入RediSearch模塊做“點(diǎn)贊索引”，并提出強(qiáng)一致方案：1.使用Redlock對(duì)資源加鎖；2.雙寫(xiě)Redis與MySQL，采用“寫(xiě)MySQL成功后再寫(xiě)Redis”順序；3.若Redis寫(xiě)失敗，同步刪除緩存并返回失敗。請(qǐng)指出該方案在并發(fā)10萬(wàn)QPS下可能產(chǎn)生的性能瓶頸，并給出量化估算?！敬鸢浮科款i1：Redlock需5個(gè)master節(jié)點(diǎn)，每次點(diǎn)贊5次RTT，平均5ms，10萬(wàn)QPS需500萬(wàn)次RTT/s，集群網(wǎng)卡帶寬約1Gbps，單包200byte，理論上限65萬(wàn)包/s，可支撐但延遲飆升；瓶頸2：雙寫(xiě)MySQL，單行insertRTT2ms，10萬(wàn)QPS需20萬(wàn)磁盤(pán)IOPS，遠(yuǎn)超NVMe單盤(pán)8萬(wàn)IOPS；瓶頸3：Redis寫(xiě)失敗觸發(fā)緩存刪除，緩存穿透回源MySQL，峰值放大3倍，30萬(wàn)QPS打崩DB?！窘馕觥苛炕浪阈杞o出RTT、IOPS、帶寬三維度，每點(diǎn)2分。【問(wèn)題3】（8分）給出“最終一致+補(bǔ)償”方案，要求：1.不降低點(diǎn)贊接口性能；2.丟失數(shù)<10/分鐘；3.支持冪等。請(qǐng)畫(huà)出架構(gòu)圖（文字描述），并說(shuō)明補(bǔ)償流程?！敬鸢浮考軜?gòu)：客戶端→API網(wǎng)關(guān)→點(diǎn)贊服務(wù)→Kafka（點(diǎn)贊事件）→Flink消費(fèi)→Redis增量累加→定時(shí)對(duì)賬→MySQL。補(bǔ)償：1.Flink檢查點(diǎn)5s，故障恢復(fù)時(shí)重放Kafka；2.對(duì)賬任務(wù)每1min比較Redis與MySQL差值，若差值>10，觸發(fā)補(bǔ)償更新Redis；3.點(diǎn)贊接口傳入冪等Token，Redis用SETNX保證同一Token只處理一次?！窘馕觥考軜?gòu)4分，補(bǔ)償2分，冪等2分；若未使用Kafka事務(wù)消息扣2分。三、微服務(wù)拆分與領(lǐng)域建模案例分析【背景材料】某醫(yī)藥電商平臺(tái)包含：商品、庫(kù)存、營(yíng)銷(xiāo)、訂單、支付、履約、售后、會(huì)員、評(píng)論、搜索9個(gè)模塊。原單體應(yīng)用代碼280萬(wàn)行，需求交付周期8周，線上事故月均5次。CTO決定微服務(wù)拆分，業(yè)務(wù)目標(biāo)：1.需求交付周期≤2周；2.線上事故≤1次/月；3.支持多租戶SaaS化輸出?！締?wèn)題1】（10分）請(qǐng)用DDD戰(zhàn)略設(shè)計(jì)給出限界上下文劃分結(jié)果，并說(shuō)明每個(gè)上下文的聚合根、領(lǐng)域事件、通用語(yǔ)言，至少7個(gè)上下文?！敬鸢浮?.商品上下文：聚合根SKU、類(lèi)目；事件“商品上架”；語(yǔ)言“SPU、SKU、規(guī)格”；2.庫(kù)存上下文：聚合根WarehouseStock、ReservedStock；事件“庫(kù)存預(yù)扣”；語(yǔ)言“可用庫(kù)存、預(yù)扣庫(kù)存”；3.營(yíng)銷(xiāo)上下文：聚合根Coupon、Promotion；事件“優(yōu)惠券領(lǐng)取”；語(yǔ)言“門(mén)檻、面額、適用商品”；4.訂單上下文：聚合根Order、OrderLine；事件“訂單已創(chuàng)建”；語(yǔ)言“下單、拆單、主訂單”；5.支付上下文：聚合根Payment、Refund；事件“支付成功”；語(yǔ)言“支付單、渠道、流水”；6.履約上下文：聚合根DeliveryOrder、Package；事件“發(fā)貨”；語(yǔ)言“揀貨、復(fù)核、出庫(kù)”；7.售后上下文：聚合根AfterSale、Return；事件“退貨收貨”；語(yǔ)言“售后單、退款單”；8.會(huì)員上下文：聚合根Member、Address；事件“會(huì)員注冊(cè)”；語(yǔ)言“成長(zhǎng)值、積分”；9.搜索上下文：聚合根SearchIndex；事件“索引更新”；語(yǔ)言“關(guān)鍵詞、權(quán)重”?！窘馕觥棵可舷挛?分，聚合根0.5分，事件0.5分；若缺少“多租戶”語(yǔ)言扣2分?！締?wèn)題2】（8分）針對(duì)“下單”場(chǎng)景，識(shí)別跨上下文交互，用上下文映射給出集成關(guān)系，并指出采用“開(kāi)放主機(jī)服務(wù)+發(fā)布語(yǔ)言”還是“共享內(nèi)核”，說(shuō)明理由?！敬鸢浮拷换ィ河唵巍鷰?kù)存：預(yù)扣庫(kù)存；訂單→營(yíng)銷(xiāo)：核銷(xiāo)優(yōu)惠券；訂單→支付：創(chuàng)建支付單；訂單→商品：校驗(yàn)上架狀態(tài)。映射：訂單庫(kù)存：OHS+PL（RESTAPI+JSON），因庫(kù)存需對(duì)外SaaS輸出；訂單營(yíng)銷(xiāo)：OHS+PL；訂單支付：OHS+PL；訂單商品：共享內(nèi)核，因商品代碼被訂單頻繁引用，且變化頻率低。理由：共享內(nèi)核減少重復(fù)對(duì)象轉(zhuǎn)換，但需團(tuán)隊(duì)緊密協(xié)同；OHS+PL保證邊界清晰?！窘馕觥坑成?分，理由4分；若全部共享內(nèi)核扣3分?！締?wèn)題3】（6分）拆分后首次上線出現(xiàn)“訂單服務(wù)”調(diào)用“庫(kù)存服務(wù)”超時(shí)，導(dǎo)致用戶下單失敗。日志顯示庫(kù)存服務(wù)RT99ms，訂單服務(wù)設(shè)置超時(shí)100ms，重試1次。實(shí)際失敗率0.8%。請(qǐng)用Little定律與排隊(duì)論估算：若目標(biāo)失敗率<0.1%，超時(shí)閾值應(yīng)設(shè)為多少？（假設(shè)服務(wù)到達(dá)服從泊松過(guò)程，服務(wù)時(shí)間服從指數(shù)分布，利用率ρ=0.7）【答案】M/M/1模型，ρ=0.7，平均排隊(duì)等待時(shí)間Wq=ρ/(μλ)=0.7/(1/0.0991/0.099×0.7)=0.231ms；總響應(yīng)時(shí)間=服務(wù)時(shí)間+排隊(duì)≈99+23.1=122.1ms；重試1次，失敗概率=P(T>100)=e^(100/122.1)=0.44，單次失敗0.44，重試后失敗0.44×0.44=0.1936，與觀測(cè)0.8%不符，說(shuō)明重試放大；目標(biāo)失敗率0.1%，則P(T>t)=0.003（開(kāi)方），t=122.1×ln(0.003)=658ms；故超時(shí)閾值應(yīng)設(shè)為660ms?！窘馕觥磕Ｐ?分，計(jì)算3分，結(jié)論1分；若未用排隊(duì)論扣4分。四、云原生架構(gòu)與成本優(yōu)化案例分析【背景材料】某社交App采用Kubernetes+AWS，微服務(wù)42個(gè)，Pod平均280個(gè)，日常CPU利用率18%，內(nèi)存利用率35%，月度賬單9.8萬(wàn)美元，其中EC2占72%。CTO要求半年內(nèi)降本30%，不得影響可用性?！締?wèn)題1】（6分）請(qǐng)用VerticalPodAutoscaler（VPA）與HorizontalPodAutoscaler（HPA）混合策略，給出量化步驟，估算可節(jié)省CPU資源多少？【答案】1.VPA分析歷史7天，發(fā)現(xiàn)80%時(shí)段CPU請(qǐng)求overprovision60%，可將request從1000m降至400m；2.HPA基于CPU70%閾值，擴(kuò)容，日常280Pod可縮至280×0.4/0.7=160Pod；3.合計(jì)CPU節(jié)省=(1000400)×280=168核，換算c5.large2vCPU，節(jié)省84實(shí)例；4.賬單EC2部分9.8×0.72=7.06萬(wàn)，節(jié)省84×0.085×24×30≈5.15萬(wàn)/月，降幅5.15/9.8=52.6%，超目標(biāo)。【解析】步驟3分，量化3分；若未考慮HPA與VPA疊加扣2分?！締?wèn)題2】（6分】部分服務(wù)為有狀態(tài)Redis，原使用AWSElasticCache主從，成本1.2萬(wàn)/月?，F(xiàn)考慮自管RedisonEBS+Spot實(shí)例，請(qǐng)給出SLA權(quán)衡與成本對(duì)比，并判斷是否值得替換?！敬鸢浮孔怨芗軜?gòu)：3節(jié)點(diǎn)+Sentinel，Spot價(jià)格0.006/小時(shí)，ondemand0.05/小時(shí)，每月成本3×0.006×24×30=12.96美元，EBS100GBgp3每月8.5美元，合計(jì)21.46美元；原ElasticCache1200美元；節(jié)省1178美元，降本98%；SLA：Spot中斷概率2%，通過(guò)Sentinel30s完成故障轉(zhuǎn)移，可用性99.75%，低于ElasticCache99.9%；權(quán)衡：若業(yè)務(wù)可接受5分鐘/月中斷，則值得替換；否則保留?！窘馕觥砍杀?分，SLA3分；未給出Sentinel故障轉(zhuǎn)移時(shí)間扣2分。【問(wèn)題3】（8分）團(tuán)隊(duì)決定采用Karpenter動(dòng)態(tài)節(jié)點(diǎn)組，請(qǐng)?jiān)O(shè)計(jì)“ProvisionNode”CRD模板，要求：1.支持多AZ打散；2.優(yōu)先選擇AMD實(shí)例；3.若Spot中斷，30s內(nèi)完成重調(diào)度；4.節(jié)點(diǎn)最大生命周期24h，強(qiáng)制滾動(dòng)。【答案】```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分；若未設(shè)置ttlSecondsUntilExpired扣2分。五、高可用架構(gòu)與故障演練案例分析【背景材料】某互聯(lián)網(wǎng)支付公司“代付”系統(tǒng)，日均1200萬(wàn)筆，峰值5萬(wàn)TPS，SLA要求99.99%，RPO=0，RTO≤30s。架構(gòu)：雙活數(shù)據(jù)中心A/B，距離80km，專(zhuān)線延遲3ms，MySQL5.7雙向復(fù)制，應(yīng)用層無(wú)狀態(tài)，流量網(wǎng)關(guān)基于DNS權(quán)重50:50?！締?wèn)題1】（10分】請(qǐng)給出“數(shù)據(jù)庫(kù)雙向復(fù)制”場(chǎng)景下，出現(xiàn)“雙寫(xiě)沖突”的3種典型case，并給出檢測(cè)與解決策略?！敬鸢浮緾ase1：同一訂單同時(shí)更新?tīng)顟B(tài)為