先说实话：2025 年上半年这一场，能逐题读到文字版题目的是综合知识（博客园有一份题目汇总，共 62 个题目条目加 5 个英文阅读空），但那份汇总只有题面，没有答案；另一份腾讯云开发者社区的整理给出了 9 道题的明确答案。案例分析和论文，我读到的是考生回忆的题目方向，没有读到逐问的标准答案。所以这篇文章我给所有结论打了三档标签，请务必看清楚：
- 【来源确认】：我真实读到的页面里写明了答案；
- 【自行推导】：来源没给答案，我根据教材知识或自己验算得出；不是来源确认的答案，但我对推理过程有把握，并写明理由；
- 【待核实】：题面不全、选项存疑或教材存在分歧，我不下结论。
版权与使用说明：真题版权归考试主办方所有。本文每题只做“题意概括 + 选项要点”，不整页搬运原卷；解析为个人整理，不代表官方评分标准。请以官方发布及正版真题为准。
一、场次概况：先确认考试存在、在哪天
| 项目 | 内容 | 来源与说明 |
|---|---|---|
| 场次 | 2025 年上半年，确有此场次 | 湖南省工信厅等地方转发的人社部通知：2025 年上半年软考考试时间为 5 月 24 日至 27 日。 |
| 考试日期 | 2025 年 5 月 24 日（系统架构设计师） | 多家机构页面（环球网校等）写明高级资格在 5 月 24 日上午综合知识 + 案例分析、下午论文；地方通知里只给了 24–27 日的整体窗口，并注明“具体以准考证为准”。 |
| 时间分配 | 上午 8:30–12:30（综合知识 + 案例分析连考，240 分钟），下午 14:30–16:30（论文，120 分钟） | 环球网校页面。 |
| 题型 | 综合知识 75 题，案例分析 5 题，论文 4 选 1，各科满分 75 | 多个页面一致。 |
| 合格线 | 各科 45 分 | 人社部统一口径，前文《考试概览》有详述。 |
一处日期冲突：希赛网的案例分析汇总页里出现了“2025 年 4 月 28 日”的日期，与 5 月 24 日对不上。那个日期我判断是页面里考前备考提示的残留文字（按人社部通知，4 月 28 日距报名截止不远，并不是考试日），不采用，以 5 月 24 日（以准考证为准）为准。
这一场的气质我用一句话概括：“AI 味”明显变浓。综合知识里出现了大模型生成代码的核心架构、工业大模型分层；案例分析的必答题是深度学习模型平台，选做里有端侧 AI 与云侧 AI 算力；论文里出现了 AI 生成测试用例。但与此同时，底层基本功（内聚、4+1、死锁、数据库三级模式、REST、SOA）依然大量出现，新热点占比不大，老考点稳住了基本盘。
二、综合知识
综合知识的题面来自博客园“系统架构设计师 2025 年上半年 综合知识”题目汇总（整理者的编号，不等同考场题号；该页面里还有几道重复收录的题，例如调试与测试的区别、EDF 调度、Scrum 排序各出现了两次，应是回忆版合并时的重复）。答案来自腾讯云开发者社区“2025 年 5 月真题回忆 + 对答案”页面（它的编号与上面那份也不一样，我只能按题意去对应）。下面所有表格里的“状态”列就是三档标签。
2.1 来源确认的 9 题（答案速对）
| 编号 | 主题 | 答案 | 状态 | 我的核对 |
|---|---|---|---|---|
| C1 | 页大小 4KB、内存 16GB，位示图占多少 KB | A（512KB） | 来源确认 | 已验算：16GB ÷ 4KB = 4M（2²²）个页框，每页 1 位，共 2²² 位 = 2¹⁹ 字节 = 512KB，一致 |
| C2 | 调制解调技术的功能 | B（模拟信道传数字信号） | 来源确认 | 符合通信基础 |
| C3 | CMMI 分为几级 | 5 级 | 来源确认 | CMMI 阶段式表示为 5 个成熟度等级；连续式为 0–5 共 6 个能力等级，本题按 5 级 |
| C4 | 国家秘密（机密级）一般保密期限不超过多少年 | B（二十年） | 来源确认 | 保密法口径：绝密 30 年、机密 20 年、秘密 10 年，与一致 |
| C5 | 半双工通信至少需要几个逻辑通道 | A（1 个逻辑通道） | 来源确认 | 半双工可双向但不能同时，共用一个通道 |
| C6 | Scrum 产品待办列表按什么排序 | B（商业价值） | 来源确认 | 产品负责人按商业价值排序，符合 Scrum 指南 |
| C7 | 单元测试的依据 | C（详细设计） | 来源确认 | V 模型对应关系：单元测试 ↔ 详细设计 |
| C8 | 不属于项目管理和支撑过程域输出的内容 | A（源代码） | 来源确认 | 源代码是开发工程域产物，计划、跟踪、质量报告才是管理支撑类 |
| C9 | RUP 中确定体系结构、制定计划的阶段 | 来源写 A（初始） | 存在分歧 | 见下文 2.3 的专门说明 |
以上 9 题都只来自同一个来源（腾讯云社区页面）。C9 与我的教材知识冲突，所以我不把它算成“已确认”。
2.2 题意还原与答案分级（按知识块）
下面每题都是“题意概括 + 选项要点 + 状态 + 解析”。【自行推导】的答案是我写的，不是来源确认的，请当作“我的判断”去用。
A. 操作系统、通信、存储
| 条目 | 题意概括 | 答案与状态 | 解析 |
|---|---|---|---|
| 3 | 机密级国家秘密保密期限一般不超过多少年 | 20 年（来源确认，见 C4） | 记“绝 30、机 20、秘 10” |
| 4 | 半双工通信至少几个逻辑通道 | A（来源确认，见 C5） | 单工 1 方向，半双工 1 通道分时双向，全双工需同时双向 |
| 7 | 5 个进程各需 2 个资源，至少多少资源才能保证不死锁 | 6【自行推导】 | 最坏情况：每个进程各拿到 1 个资源（共 5 个），都在等第二个 → 死锁。再多 1 个资源，必有一个进程能拿齐 2 个并完成、释放。公式：n 个进程各需 k 个，不死锁最少资源 = n(k−1)+1 = 5×1+1 = 6 |
| 8 | 信道带宽 3000Hz，32 种信号状态，无噪声最大传输速率 | 30 kbps【自行推导】 | 奈奎斯特定理：最大速率 = 2W·log₂N = 2×3000×log₂32 = 2×3000×5 = 30000 bps |
| 9 | 一次可编程只读存储器的缩写 | B（PROM）【自行推导】 | ROM 掩膜；PROM 可编程一次；EPROM 紫外擦除；EEPROM 电擦除 |
| 10 | 以下不属于“非实时嵌入式操作系统”的是（VxWorks / iOS / Android / WinCE） | 【待核实】 | 题干是双重否定，而 VxWorks 与 WinCE 都是常见的实时嵌入式系统，iOS、Android 是非实时的。两个实时系统并列，我读到的转述可能丢了选项细节，不下结论 |
| 11 | 进程从执行状态转为就绪状态的原因 | B（主动让出 CPU）【自行推导】 | wait()、键盘输入、信号量等待都会让进程阻塞，不会回就绪；只有时间片到、被抢占或主动让出（yield）才是运行→就绪 |
| 56 | 用户首次打开文件，系统首先做什么 | A（读 FCB 到内存）【自行推导】 | open 的本质是把文件控制块（FCB/inode）读入内存，建立打开文件表项；之后读写才用文件描述符 |
| 33 / 50 | 强实时调度算法里按“紧急程度”定优先级的是（EDF / FIFO / LLF / RMS）；EDF 满足什么要求 | 【待核实】 | “紧急程度”可理解为截止时间（EDF）或松弛度（LLF）；两个选项都有道理，我没读到原题措辞。EDF 属于动态优先级调度，在单处理器上、利用率不超过 100% 时可调度，常用于强实时，但题面选项我不全，也不下结论 |
B. 软件工程、测试、过程
| 条目 | 题意概括 | 答案与状态 | 解析 |
|---|---|---|---|
| 5 | 内聚类型从强到弱的正确排序 | B（功能、顺序、通信、过程、时间、逻辑、偶然）【自行推导】 | 教材固定顺序，口诀“功顺通过时逻偶” |
| 15 | 净室软件工程的理论基础 | A（函数理论和抽样理论）【自行推导】 | 净室方法用函数理论做设计与正确性验证，用统计抽样做质量认证 |
| 16 | RUP 中确定体系结构、制定计划和资源需求的阶段 | 【分歧】 | 见 2.3 |
| 20 | 不属于黑盒测试的方法 | C（路径覆盖）【自行推导】，另一来源页面也列出这一题，答案一致（该页面未给字母，只写“路径覆盖不属于黑盒”） | 黑盒：等价类、边界值、因果图、判定表；路径覆盖是白盒 |
| 21 | 哪个开发模型增加了风险评估环节 | B（螺旋模型）【自行推导】 | 螺旋模型的四象限里有风险分析，是它最大特色 |
| 22 / 49 | 调试与测试区别中错误的说法 | A（“调试在测试前面”/“测试永远在调试后”一类）【自行推导】 | 先测试发现缺陷，再调试定位修复，顺序是测试 → 调试。测试可以预估周期，调试因为要找原因往往难预估，起始条件不明确，这两条说法是对的 |
| 24 | 不属于测试度量指标的是（故障率、MTTR、测试准备时间、测试完成时间） | 【待核实】 | 选项表述过于简略，无法判断“度量指标”的口径 |
| 43 | 回归测试的目的 | A（不引入新 bug）【自行推导】 | 回归测试是在修改后确认原有功能没被破坏，目的是防止引入新缺陷 |
| 45 | 条件覆盖与判定覆盖的关系 | C（互不一定包含）【自行推导】 | 条件覆盖保证每个条件取真取假，但判定结果可能始终同为真或同为假；判定覆盖保证两个分支，但每个条件不一定都取遍真假。本专栏《2024 年下半年真题》里有反例说明 |
| 46 | 不属于“可靠性”子特性的是（容错性、成熟性、可恢复性、健壮性） | D（健壮性）【自行推导】 | 按 ISO/IEC 25010 口径，可靠性包含成熟性、可用性、容错性、可恢复性；“健壮性”是通俗词，不是标准子特性。教材口径可能不同，标为自行推导 |
| 47 | 数据流图中表示“加工和转换”的组件 | B（处理/加工）【自行推导】 | DFD 四元素：外部实体、加工、数据流、数据存储 |
| 23 | 结构化分析方法的特点 | B（面向数据流）【自行推导】 | 结构化分析：自顶向下、逐层分解、面向数据流；A “自底向上”显然错 |
| 61 | 影响软件质量的三组因素 | A（产品运行、产品修改、产品转移）【自行推导】 | McCall 质量模型的三个视角 |
| 52 | 一个类完全继承父类，同时还扩展其他能力，属于哪种继承 | 【待核实】 | 面向对象继承分类（特化、包含、取代、受限等）在不同教材里定义有差异，题面我没读全，不下结论 |
| 53 | “双生命周期模型”指哪两个生命周期 | A（领域工程和应用工程）【自行推导】 | 软件复用里的双生命周期：领域工程（开发可复用资产）+ 应用工程（用资产开发产品） |
| 59 | 需求跟踪中错误的描述 | A【自行推导】 | 正向跟踪是检查需求规格说明书中的每一项需求能否在后续工作成果里找到对应；反向跟踪才是检查后续工作成果是否都能在需求里找到出处。选项 A 把正向说成了反向，故错；二者合称“双向跟踪” |
| 12 | Web 服务器性能评测方法不包括 | D（UI 测试）【自行推导】 | 性能评测常用基准测试、压力测试、可靠性测试；界面测试不属于性能评测 |
| 37 | AB 测试的正确描述 | A（同一时间、相似用户）【自行推导】 | AB 测试要控制变量：同一时间段，把相似的用户随机分成两组，分别看到版本 A 与 B，对比指标 |
C. 架构、设计、SOA、微服务
| 条目 | 题意概括 | 答案与状态 | 解析 |
|---|---|---|---|
| 6 | 微服务断路器的三种状态 | B（打开、关闭、半开）【自行推导】 | Closed 正常；失败达阈值→Open 快速失败；等待一段时间→Half-Open 放少量请求试探，成功则回到 Closed |
| 13 | 4+1 视图中描述软件到硬件映射的是 | D（物理视图）【自行推导】 | 物理视图描述软件如何部署到硬件节点 |
| 14 | 4+1 视图中关注运行特性的是 | B（进程视图）【自行推导】 | 进程视图关注并发、同步、性能，也就是运行时特性 |
| 25 | WebService 的核心技术 | 【待核实】 | 选项我读到的是“计算池、五层模型、开放式 Web、网格计算”，与常见的 SOAP/WSDL/UDDI 对不上，转述可能有误 |
| 30 | SOA 中服务请求者与提供者的通信传输规范 | B（SOAP）【自行推导】 | UUID 是标识、WSDL 是描述、XML 是格式；通信规范是 SOAP |
| 31 | REST 中部分更新用的 HTTP 方法 | C（PATCH）【自行推导】 | PUT 全量替换，PATCH 局部更新，POST 新建 |
| 51 | 黑板架构中的数据处理构件 | B（知识源）【自行推导】 | 黑板三件套：知识源（处理）、黑板（共享数据）、控制（调度） |
| 57 | 关于 C/S 架构的错误说法 | A（“B/S 是一种特殊的双层C/S”）【自行推导】 | 教材口径：B/S 是一种特殊的三层C/S 结构（浏览器、Web 服务器、数据库服务器），故 A 错；三层比两层多一个应用服务器，分为表示层、功能层、数据层 |
| 58 | SOA 中进一步解耦请求者与提供者的组件 | B（ESB）【自行推导】 | 企业服务总线负责路由、转换、协议适配，把点对点耦合变成“总线接入” |
| 60 | 关于架构脆弱性的错误描述 | C（“管道过滤器无法并发”）【自行推导】 | 管道过滤器的各过滤器可并行，所以说它“无法并发”是错的；分层需跨多层通信有性能问题、黑板可能无解、事件驱动顺序不可控，都是对的 |
D. 数据库与安全
| 条目 | 题意概括 | 答案与状态 | 解析 |
|---|---|---|---|
| 26 | OSI 安全体系的 5 类安全服务 | A（鉴别、访问控制、数据机密性、数据完整性、抗抵赖）【自行推导】 | X.800 口径的五类，也是软考常考的固定集合 |
| 27 | 三级模式中表示用户局部数据的是 | B（外模式）【自行推导】 | 外模式=用户视图/子模式，概念模式=全局逻辑，内模式=物理存储 |
| 28 | 描述数据类型、结构、记录间联系、完整性与安全性的是 | B（概念模式）【自行推导】 | 概念（逻辑）模式描述全局逻辑结构 |
| 32 | 内模式描述的内容 | A（物理结构和存储方式）【自行推导】 | 内模式=存储模式，描述数据的物理结构和存储方式 |
| 29 | R(a,b,c,d)，a→cd，c→b，候选码 | a【自行推导】 | a→c,d；c→b，所以 a→b，a 的闭包为 abcd，a 本身就是码；它是单属性，自然最小 |
| 39 | 申请软件著作权需提交的鉴别材料 | A（程序和文档）【自行推导】 | 软件著作权登记提交的是程序鉴别材料与文档鉴别材料 |
| 40 | 监理“四控三管一协调”的四控 | D（投资、进度、质量、变更）【自行推导】 | 信息系统工程监理的四控是投资控制、进度控制、质量控制、变更控制；三管是合同、信息、安全管理，一协调是沟通协调。该记忆来自教材口径，选项措辞以正版试卷为准 |
| 34 | 数据治理应用场景不包括 | 【待核实】 | 选项只读到“风险控制、存储备份、预测分析、用户画像”，不足以判断 |
E. 数学计算与新技术
| 条目 | 题意概括 | 答案与状态 | 解析 |
|---|---|---|---|
| 35 | 100 人，Java 45、C 53、Python 55，Java∩C 28、C∩Python 32、Python∩Java 35，三者都会 20，三种都不会的人数 | 22【自行推导】 | 容斥：|A∪B∪C| = 45+53+55 − 28 − 32 − 35 + 20 = 153 − 95 + 20 = 78；100 − 78 = 22 |
| 36 | 约束 x−1≥0，x−y≤0，x+y−4≤0，求 y/x 最大值 | 3【自行推导】 | 可行域是三角形，顶点 (1,1)、(1,3)、(2,2)；y/x 是顶点到原点连线斜率，(1,3) 处为 3，最大 |
| 38 | 10 个作业 A–J 的网络图，D 推迟 3 天开始，总工期推迟几天 | 【待核实】 | 必须有作业依赖表，我没读到，无法计算。套路：看 D 的总时差，推迟量超出总时差的部分才是总工期的推迟量 |
| 54 | 5 个对象，每个对象 2 种属性取值，组合总数 | 32【自行推导】 | 2⁵ = 32 |
| 62 | DFD 中 B、C 不能同时产生，二者之间用什么符号 | ⊕（互斥/异或）【自行推导】 | 数据流图里 ⊕ 表示“二选一、互斥”，* 表示“与”，+ 表示“或”。符号体系以教材为准 |
| 17 | 大模型生成代码的核心架构 | A（Transformer）【自行推导】 | 主流代码大模型基于 Transformer |
| 19 | ERP 的三流 | A（物流、资金流、信息流）【自行推导】 | 经典口径 |
| 41 | 工业大模型中，基础设施层与应用层之间的三层 | 【待核实】 | 属于较新的行业口径，我没有读到权威出处，不下结论 |
| 42 | 边缘计算优点不包括 | 【待核实】 | “提升带宽”一项的措辞存疑，边缘计算通常是降低回传带宽占用而非提升带宽 |
| 55 | 没有标注的数据应使用什么算法 | A（聚类）【自行推导】 | 无标签数据属于无监督学习，典型是聚类 |
| 18 | 逆向工程中用户指导下的搜索与变换，通常导出哪两个层级的信息 | 【待核实】 | 教材把逆向工程信息分为实现级、结构级、功能级、领域级，本题对应哪两级我没有把握，不下结论 |
2.3 答案分歧专栏：RUP 那一题
腾讯云页面把 RUP 那道题的答案标为“A（初始）”，而题面我读到的有两个版本：一个是“设计体系结构和工作计划”，另一个是“确定系统体系结构，制定计划和资源要求”。按 RUP 教材：
| 阶段 | 主要目标 |
|---|---|
| 初始（Inception） | 确定项目范围、业务案例，识别关键用例，粗略估计成本与计划 |
| 细化（Elaboration） | 确定并验证系统架构，制定详细项目计划和资源需求，消除主要风险 |
| 构造（Construction） | 完成开发，构建可运行产品 |
| 交付（Transition） | 产品移交用户，部署、培训、维护 |
“确定体系结构、制定计划和资源要求”几乎就是细化阶段的定义，所以我倾向 B。但来源给了 A，而我没读到原题的完整选项，也可能是题干是另一种问法（例如问“确定范围和建立业务案例”）被转述时改写。因此我不采信也不推翻，标为“存在分歧，请以正版试卷为准”。这也正是我坚持分档标注的原因。
2.4 英文阅读（5 空）
来源页面里有一篇关于 system quality attributes（系统质量属性）的英文短文，5 个空的选项分别围绕：architect/developer/tester/user；meaningful/operational/meaningless/useful；scenarios/vocabulary/solutions/problems；performance/security/availability/usability；scenarios/definitions/taxonomies/communities。我没有读到短文原文，也没有读到答案，所以 5 个空全部“答案待核实”。做这类题的策略：质量属性主题的英文文章，常在讲“质量属性名称有歧义，需要用场景（scenarios）来精确描述，而不是只谈 performance、security 这些词”，所以带 scenarios 的空优先推敲这个逻辑，但只能当做线索，不是答案。
2.5 综合知识覆盖小结
| 类别 | 题数 | 说明 |
|---|---|---|
| 来源确认答案 | 8 题（另 1 题存在分歧） | 位示图、调制解调、CMMI、保密期限、半双工、Scrum、单元测试依据、支撑域输出 |
| 自行推导答案 | 约 42 题 | 见上表标注，不属于来源确认 |
| 待核实 | 约 13 题 + 英文 5 空 | 含题面不全、选项存疑 |
| 未覆盖 | 其余部分 | 75 题里，汇总页未收录的部分我没读到，不编 |
三、案例分析：能确认的考点与答题要点
案例分析这一科，两个页面（希赛网案例汇总、一位 CSDN 博主的“案例题总结”经搜索摘要可见）给出的考点线索是：
- 必答题：深度学习模型平台。第一问给出若干质量属性场景，要求填写对应的质量属性名称；第二问考解释器风格架构的组成图填空，并要求说明该平台为何适合解释器风格。
- 选做：Redis。主从复制全量复制流程图填空（涉及 BGSAVE）、增量复制流程图填空，以及 RDB 与 AOF 两种持久化方式的对比。
- 选做：医药信息知识图谱。知识图谱分层架构、Scrapy 爬虫流程与异步 I/O、知识图谱存储与智能问答的实现。
- 选做：端侧 AI 与云侧 AI 算力。嵌入式 AI、云 AI 与端 AI 的对比。另有一个页面提到“区块链相关内容”，另一个页面没有提，存疑，不采信。
- 各题分值、每一问的标准答案：答案待核实，我没读到。GitHub 上有 2025 年 5 月案例真题 PDF，但我无法在这里读取 PDF。
下面是我自己写的考点答题要点，不是官方参考答案。
3.1 质量属性场景到属性名的映射
这类填空的套路是：抓住场景中的响应度量关键词反推属性。速查表：
| 场景里的关键词 | 对应质量属性 |
|---|---|
| 响应时间、吞吐量、并发、延迟、资源占用 | 性能 |
| 故障检测与恢复时间、可用时间比例、宕机、降级 | 可用性 |
| 非授权访问、加密、审计、攻击检测 | 安全性 |
| 新增功能的修改成本、改动范围、部署时间 | 可修改性 |
| 故障定位、可观测、注入测试、测试覆盖 | 可测试性 |
| 学习曲线、界面操作步骤、撤销、用户满意度 | 易用性 |
| 跨平台、适配新硬件或新版本 | 可移植性 / 互操作性 |
对于深度学习模型平台，典型场景举例：“训练任务提交后 5 分钟内完成资源调度”（性能）、“某 GPU 节点故障后任务自动迁移并在 1 分钟内继续”（可用性）、“新增一种模型框架只需增加适配插件”（可修改性）。这些例子是我按常识编的示范，不是原题场景。质量属性战术的完整版在《综合知识精讲（上）》里。
3.2 解释器风格架构
组成：解释器风格（虚拟机风格的一种）由四个部分构成：被解释的程序（伪代码/模型描述）、解释引擎（执行程序的核心）、被解释程序的当前状态（控制状态）、解释引擎的内部状态。经典例子：JVM、Python 解释器、规则引擎、脚本引擎。深度学习平台里，用户提交的计算图/模型描述相当于“被解释的程序”，运行时的图执行引擎就是“解释引擎”，它把计算图映射到底层 GPU/NPU 上执行。
适合的理由（答题要点）：① 动态执行：模型结构可以动态构建与修改；② 硬件抽象：同一份模型描述可由不同后端执行，屏蔽硬件差异；③ 即时优化：执行前可以做图优化、算子融合；④ 可扩展：新增算子、后端只需扩展引擎；⑤ 跨平台。缺点：解释执行有性能损失，调试复杂，需要靠即时编译（JIT）等手段弥补。
3.3 Redis 主从复制与持久化
全量复制流程（典型）：① 从节点发送 PSYNC 请求（首次无 runid）；② 主节点返回 FULLRESYNC（带 runid 与偏移量）；③ 主节点执行 BGSAVE 生成 RDB；④ 同时把 RDB 生成期间的新写命令记录到复制缓冲区（复制积压区）；⑤ 主节点把 RDB 发给从节点；⑥ 从节点清空旧数据并载入 RDB；⑦ 主节点再把缓冲区里积累的写命令发给从节点，追平数据。
增量复制流程：主从断线重连后，从节点带上自己的 runid 与复制偏移量发 PSYNC；主节点检查 runid 匹配且偏移量仍在复制积压缓冲区内，则回复 CONTINUE，只发送缺失的那段命令；若偏移量已被覆盖，退化为全量复制。
RDB 与 AOF 对比：
| 对比项 | RDB（快照） | AOF（追加日志） |
|---|---|---|
| 原理 | 定时把内存数据生成二进制快照 | 记录每条写命令，重启时重放 |
| 文件与恢复 | 文件紧凑，恢复速度快 | 文件较大，恢复较慢（可 AOF 重写压缩） |
| 数据安全 | 两次快照之间的数据可能丢失 | 可配置每秒或每条同步，丢数据更少 |
| 对性能影响 | fork 子进程时有瞬时开销 | 持续写盘，every-sec 策略开销可控 |
| 生产建议 | 用于备份与快速恢复 | 对数据安全要求高时开启；Redis 4.0+ 可混合持久化 |
提示：我在搜索摘要里读到有页面写“RDB 缺点是文件体积大、恢复速度慢”，这与 RDB 的一般特征相反（RDB 通常更小、恢复更快），我判断是转述把 RDB 和 AOF 的缺点弄混了，请以 Redis 官方文档的口径为准。
3.4 知识图谱系统（自写要点）
- 分层架构：数据层（多源异构数据：网页、文献、结构化库）→ 抽取与构建层（实体识别、关系抽取、实体对齐、知识融合）→ 存储层（图数据库如 Neo4j，配合检索引擎）→ 推理与服务层（图查询、推理、问答）→ 应用层（智能问答、辅助决策）。
- Scrapy 爬虫流程：Spider 产生请求 → Engine 调度 → Scheduler 排队 → Downloader 下载 → Spider 解析出 Item 与新请求 → Item Pipeline 清洗、存储；异步 I/O（基于 Twisted 事件循环）使得一个线程可并发处理大量网络请求，提高爬取吞吐。
- 智能问答：问题解析（意图识别、实体链接）→ 转换为图查询（Cypher/SPARQL）→ 图数据库检索 → 答案生成。结合大模型时常用 RAG：把图谱检索结果作为上下文喂给模型。
3.5 端侧 AI 与云侧 AI（自写要点）
| 维度 | 云侧 AI | 端侧 AI |
|---|---|---|
| 算力 | 集中、强大、可弹性扩展 | 受限于终端芯片与功耗 |
| 时延 | 依赖网络，往返时延较高 | 本地推理，时延低 |
| 隐私 | 数据上云，需合规保护 | 数据留在本地，隐私更好 |
| 成本 | 按用量付费，随规模增长 | 一次性硬件成本，边际成本低 |
| 模型 | 可用超大模型 | 需压缩（量化、剪枝、蒸馏） |
常见答题落点：端云协同——简单、实时、隐私敏感任务在端侧，复杂、大模型任务上云。案例题答题模板见《案例分析：题型拆解与答题模板》。
四、论文：四道题的考查方向与写作方案
希赛网论文页与多篇考生回忆一致列出了本场的四道题（我用自己的话概括，不照抄原文）：
| 题号 | 题目方向 | 核心考查 | 难度感受（我的判断） |
|---|---|---|---|
| 1 | 系统负载均衡设计方法 | 负载均衡的层次与算法；项目中如何设计与落地；问题与对策 | 素材多，套路化 |
| 2 | 事件驱动架构 | EDA 概念、组成（事件生产者、通道、消费者）、优缺点；项目中的应用与难点 | 需要消息中间件实战经验 |
| 3 | 多模型数据库及应用 | 多模型数据库的概念与优势；选型、落地与问题 | 较新，经验少的人吃力 |
| 4 | 软件测试方法及应用（AI 生成测试用例） | AI 工具在生成测试用例中的具体应用；AI 测试用例生成的基本处理流程及各步骤；项目中如何做软件测试 | 有测试经验者可写，AI 部分需要积累 |
说明：没有找到官方标准范文，下面的提纲与素材都是我自己整理的。通用骨架见《论文写作：套路、模板与素材库》。
4.1 论系统负载均衡设计方法
层次：DNS 负载均衡、四层负载（LVS、云 LB，基于 IP+端口）、七层负载（Nginx、HAProxy、网关，基于 HTTP 内容）、应用内客户端负载均衡（如服务注册发现 + 客户端选择）。
| 算法 | 原理 | 适合场景 |
|---|---|---|
| 轮询 / 加权轮询 | 按顺序或权重分配 | 服务器性能相近或可按权重区分 |
| 最少连接 | 分给当前连接数最少的节点 | 请求处理时间差异大 |
| IP 哈希 / 一致性哈希 | 同一来源映射到同一节点，节点变化影响小 | 会话保持、缓存亲和 |
| 最短响应时间 | 选响应最快的节点 | 对延迟敏感 |
要解决的问题：会话保持（粘性会话或把 Session 外置到 Redis）、健康检查与故障摘除、负载均衡器自身单点（keepalived 主备、多活集群）、后端扩缩容动态发现、长连接与 WebSocket 的均衡。提纲：摘要 → 项目背景（业务高并发、单点风险）→ 负载均衡概述 → 架构设计（接入层、算法选型、健康检查、容灾）→ 难点与对策 → 效果（吞吐、可用性、扩容时间）→ 总结。
4.2 论事件驱动架构（EDA）
核心概念：系统组件通过事件的产生、传播与消费来交互，生产者不知道谁消费，天然松耦合、异步。常见拓扑：中介者拓扑（有事件中介编排流程，便于管控）与代理者拓扑（无中心编排，组件链式响应，扩展性好但流程难追踪）。
| 优点 | 难点 | 对策 |
|---|---|---|
| 松耦合、易扩展 | 事件顺序与一致性 | 分区有序、事件版本号、幂等消费、最终一致 |
| 异步削峰 | 消息丢失与重复 | 生产者确认、持久化、消费者 ACK、去重表 |
| 天然适合实时响应 | 流程难追踪与调试 | 链路追踪、事件日志、Saga 编排 |
| 可复用事件做审计、重放 | 事件风暴导致雪崩 | 限流、死信队列、背压 |
提纲：背景（订单、库存、物流多系统协同）→ EDA 概述与拓扑 → 选型（Kafka/RocketMQ/RabbitMQ）→ 事件建模与主题划分 → 一致性与幂等设计 → 难点与对策 → 效果 → 总结。可与 DDD 领域事件结合，论述更有深度。
4.3 论多模型数据库及应用
概念：多模型数据库在同一个数据库引擎里同时支持多种数据模型（关系、文档、键值、图、时序、向量等），用统一的查询与事务语义访问，避免“一个业务拆到五六个库”的多库运维与数据搬运。代表产品如 ArangoDB、Azure Cosmos DB、OrientDB，国内外也有产品在关系库上叠加 JSON、图、向量能力（写论文时选你真实接触过的）。
| 优势 | 挑战 | 对策 |
|---|---|---|
| 减少异构数据库数量，降低运维与集成成本 | 各模型能力通常不如专用库深 | 关键场景做基准测试，必要时核心模型仍用专用库 |
| 跨模型查询与事务一致 | 数据建模复杂，模型选择错误代价大 | 按访问模式建模、评审与演练 |
| 适合知识图谱 + 文档 + 检索等混合场景 | 生态与人才不足、存在厂商绑定 | 选择开放协议与标准查询语言，保留导出路径 |
提纲：背景（业务同时需要关系、文档、图数据）→ 多模型数据库概述 → 选型对比（多库并存 vs 多模型）→ 架构设计 → 数据迁移与建模 → 难点与对策 → 效果（查询延迟、运维成本、开发效率）→ 总结。
4.4 论软件测试方法及应用（含 AI 生成测试用例）
这一题把“传统测试方法 + AI 应用”合在一起，要求至少三块：AI 在生成用例里的具体应用、AI 生成用例的处理流程、自己项目里的测试实践。我整理的流程（自写，不是标准答案）：
- 需求与上下文输入：收集需求文档、接口定义（OpenAPI）、历史缺陷、代码变更（diff），整理成模型可理解的提示词或结构化输入。
- 用例生成：由大模型按等价类、边界值、场景法等测试设计方法生成用例草案，包含前置条件、步骤、预期结果、测试数据。
- 去重与校验：与已有用例库做相似度去重；检查格式完整性、可执行性；剔除与需求矛盾的“幻觉”用例。
- 人工评审：测试工程师审阅、补充，标注缺陷与高价值用例，形成反馈。
- 脚本化与执行：把用例转换为自动化脚本（接口测试、UI 测试），接入 CI 执行。
- 结果分析与迭代：用失败结果、覆盖率、缺陷发现率反馈优化提示词与模型（如加入 RAG 引入业务知识）。
AI 的风险与对策：幻觉（人工评审、断言与需求对齐）、数据安全（代码与需求脱敏、私有化部署）、用例质量不稳定（提示词模板化、少样本示例）、可解释性不足（保留生成依据）。传统测试方法部分则讲黑盒（等价类、边界值、因果图、判定表）与白盒（语句、判定、条件、路径覆盖）、分层测试（单元、集成、系统、验收）、回归与性能测试。
4.5 摘要示例（自写，仅供练手）
2024 年 6 月，我参与了某电商企业“订单履约平台”的建设，担任系统架构师，负责整体架构设计。平台需要在大促期间承载数倍于平日的流量，并保证服务不因单点故障中断。本文结合该项目，论述了系统负载均衡的设计方法：在接入层采用 DNS 与云负载均衡相结合实现多地域分流，在网关层通过 Nginx 集群实现七层转发与限流，在服务层借助注册中心实现客户端加权负载均衡，并通过健康检查、会话外置与主备容灾消除单点。实施中针对会话保持、节点动态扩缩容和长连接均衡等问题采取了相应对策。系统上线后在多次大促中平稳运行，弹性扩容时间明显缩短，验证了方案的有效性。
数字我故意没写死，请在你自己的论文里换成真实项目的量化结果；论文最忌编造与项目不符的数据。
五、本场考点热度总结
| 科目 | 已确认/线索中的考点 | 建议优先级 |
|---|---|---|
| 综合知识 | 内聚排序、4+1、断路器、REST/SOAP/ESB、三级模式、OSI 安全服务、测试基础、Scrum、净室与复用、计算题（死锁资源数、奈奎斯特、容斥、线性规划、位示图）、AI 新热点（大模型、边缘计算） | 基础知识与计算题是稳分项；AI 题只占少数，知道概念即可 |
| 案例分析 | 质量属性场景、解释器风格、Redis 复制与持久化、知识图谱、端云 AI | “模式 + 组件 + 流程图填空”要会画、会说；Redis 这一类中间件原理值得投入 |
| 论文 | 负载均衡、事件驱动、多模型数据库、AI 测试用例 | 准备“高可用与负载”“异步事件”“数据架构”三块素材，再留一块“AI 应用” |
一句话备忘：2025 上半年这一场，综合知识靠“老基本功 + 计算题”稳住，新热点（大模型、边缘计算）点到为止；案例盯住质量属性、解释器风格与 Redis 复制持久化；论文押“高可用负载、事件驱动、数据架构、AI 应用”四条线。我标了“自行推导”和“待核实”的，请你务必对正版真题再核一遍。
六、答案冲突与待核实项
- 考试日期：希赛网案例页里的“4 月 28 日”与 5 月 24 日冲突，已判断为页面残留文字，以 5 月 24 日（准考证为准）为准。
- RUP 阶段题：来源答案 A（初始）与教材“细化阶段确定架构”冲突，存在分歧，未采信。
- 综合知识：仅 8 题有来源确认答案；约 42 题为我的自行推导（已逐条标注，非来源确认）；其余（含条目 10、18、24、25、33/50、34、38、41、42、52 与英文阅读 5 空）待核实。
- 两份综合知识来源的题号体系不一致，无法逐题号对照，只能按题意匹配。
- 案例分析各题分值与标准答案、是否有区块链题：待核实。
- CSDN 与知乎页面在我这边无法访问，未能完成多源交叉验证。
参考资料
- 博客园 huanshare：系统架构设计师 2025 年上半年 综合知识（题目汇总）——综合知识题面与选项要点来源（无答案）。
- 腾讯云开发者社区：【2025 年 5 月】系统架构设计师真题回忆 + 对答案——9 道综合知识题的明确答案来源。
- 希赛网：2025 上半年系统架构设计师案例分析考试真题——案例分析考点线索（深度学习平台、Redis、知识图谱、端云 AI）。
- 希赛网：2025 上半年系统架构设计师论文考试真题——四道论文题目方向。
- 湖南省工信厅转发：2025 年上半年软考工作通知——官方口径的考试窗口 5 月 24 日至 27 日，高级资格含系统架构设计师。
- GitHub：xxlllq/system_architect——确认仓库收录 2025 年 5 月综合知识与案例分析真题解析 PDF（未能读取 PDF 内容）。
再次提醒：以上均为第三方整理，可能存在遗漏或错误，请以考试主办方发布及正版真题为准；本文解析与素材为个人整理，不代表官方评分标准。
一起聊聊