这一篇是 2024 年下半年（11 月）那一场的复盘。先交代我的做法：这一场我能逐题读到文字版答案的，是综合知识部分（一位博主在博客园整理了 60 个编号条目加 5 道英文阅读空，含若干“双空题”）；案例分析和论文我只能读到题目方向，没有读到可靠的逐问标准答案。所以本文的原则沿用专栏一贯的规矩：有来源的给答案并写自己的解析，没来源的标“答案待核实”，绝不脑补。解析部分全部是我自己写的，并且我对每道题都用自己的知识做了一遍核对，核对不上的会直接标出来。
版权与使用说明：真题版权归考试主办方所有。本文每题只做“题意概括 + 选项要点”，不整页搬运原卷，解析为个人整理，不代表官方评分标准。请以官方发布及正版真题为准。
一、场次概况：先确认考试存在、在哪天
| 项目 | 内容 | 来源与说明 |
|---|---|---|
| 场次 | 2024 年下半年，确有此场次 | 希赛网、环球网校均有该场次的备考与真题汇总页。 |
| 考试日期 | 2024 年 11 月 10 日（希赛网考前公告写明“11 月 10 日举行”） | 环球网校的考试时间页写的是“11 月 9 日至 12 日”，这是全国整个下半年软考的窗口期，不是架构师专场；以希赛网 11 月 10 日为准，存在分歧，以官方公告为准。 |
| 时间安排 | 上午 8:30–12:30 综合知识 + 案例分析连考（240 分钟），下午 14:30–16:30 论文（120 分钟） | 希赛网、环球网校页面一致。 |
| 综合知识 | 75 题单选，75 分 | 环球网校页面。 |
| 案例分析 | 5 道题，环球网校页面表述为“选择其中 2 道作答” | 这与专栏前文写的“第一题必答 + 其余选做”的口径不同（必答题算一题，合计做 3 题，满分 75）。存在表述分歧，考场规则以准考证与考场说明为准。 |
| 论文 | 4 选 1，满分 75 | 多个页面一致。 |
| 合格线 | 各科满分 60%，即 45 分 | 人社部自 2022 年度起的统一口径，前文《考试概览》有详述。 |
本场最有辨识度的特点：综合知识里“双空题”很多（一道题两个空，比如安全特性、数据安全治理、质量属性场景、ATAM 与效用树、企业集成），英文阅读是一篇关于黑板架构的短文，论文则整体偏“经典架构主题”：SOA、异构数据集成、软件维护、分布式事务。
二、综合知识答案速对表
编号说明：博客园来源的编号是整理者的顺序，不保证等同考场题号，所以下面的“第 N 条”只是本文内的条目号。带“+”的是双空题，两个空各一个答案。该来源整理的是 1–60 条加 5 个英文阅读空，也就是说考卷里的其余题目（该来源没有列出）本文一概标“答案待核实”，不猜。
| 条目 | 答案 | 条目 | 答案 | 条目 | 答案 | 条目 | 答案 |
|---|---|---|---|---|---|---|---|
| 1 | B + D | 16 | B | 31 | A | 46 | D |
| 2 | B | 17 | A | 32 | A | 47 | D |
| 3 | D + D | 18 | A | 33 | A | 48 | D |
| 4 | B | 19 | B + A | 34 | C + A | 49 | A |
| 5 | C | 20 | A | 35 | D | 50 | C |
| 6 | B | 21 | D | 36 | C | 51 | B |
| 7 | B | 22 | A | 37 | B | 52 | B |
| 8 | C | 23 | D | 38 | C | 53 | A |
| 9 | B | 24 | C | 39 | D | 54 | C（待核实） |
| 10 | A | 25 | D | 40 | B | 55 | B |
| 11 | A + D | 26 | C | 41 | D | 56 | B |
| 12 | B | 27 | A | 42 | C | 57 | A |
| 13 | D | 28 | C | 43 | C | 58 | D |
| 14 | D | 29 | C | 44 | D | 59 | B |
| 15 | A | 30 | A | 45 | A | 60 | A |
英文阅读（黑板架构短文，5 个空）：C、D、D、D、C（来源仅列出答案字母）。
来源数：以上全部来自单一来源（博客园“2024 年 11 月架构真题解析”）。我在下面的解析里对每条都做了知识层面的核对；其中第 54 条选项字母存疑（下文有专门说明），其余未发现与教材冲突。另外我想查 CSDN 上几位博主的整理做交叉验证，但 CSDN 页面在我这边访问一律报错打不开，所以没有实现多源交叉，这一点请你心里有数。
三、综合知识逐题解析（按知识块分组）
3.1 架构风格、架构评估与质量属性（重头戏）
这一块是每场必考、而且分数最稳的。本场的关键词是：黑板（仓库）风格、管道-过滤器、事件驱动、进程通信、调用/返回、4+1 视图、ATAM 全家桶、质量属性场景。
| 条目 | 题意概括 | 答案 | 我的解析 |
|---|---|---|---|
| 4 | 仓库体系结构中，说明“当前数据状态”的组成部分是什么（黑板、中央数据结构、独立构件、知识源） | B 中央数据结构 | 仓库风格两大件：中央数据结构（表示当前状态）和一组独立构件（对数据结构做操作）。黑板系统是仓库风格的特例，它的三件套是知识源、黑板数据结构、控制，其中黑板（中央数据）存放问题求解的当前状态。看到“说明当前状态”就选数据结构。 |
| 11 | 质量属性场景的六要素里“响应”的定义；可用性度量中不属于“响应度量”的是 | A + D | 质量属性场景六要素：刺激源、刺激、环境、制品、响应、响应度量。响应是“刺激到达后系统所采取的活动”，响应度量是“怎么量化这个响应”。可用性的响应度量常见的有：故障检测时间、恢复时间、可用时间比例等。第二空选 D“数据延迟时间”是因为它更像性能度量，不是可用性的响应度量。 |
| 17 | 典型“4+1”视图包含哪些 | A | Kruchten 的 4+1：逻辑视图、进程视图、开发（实现）视图、物理视图 + 场景（用例）视图。来源里写作“制作”，应理解为开发/实现视图。口诀：“逻进开物 + 场景”。场景视图串联另外四个，是那个“+1”。 |
| 19 | ATAM 是什么方法；效用树的结构 | B + A | ATAM（Architecture Tradeoff Analysis Method）是架构权衡分析方法。效用树自顶向下：树根（效用）→ 质量属性 → 属性分类（精化）→ 场景。场景的叶子节点带优先级标记。 |
| 30 | 关于体系结构风格特点的正确描述 | A（管道-过滤可并行） | 管道-过滤器风格中，各过滤器相对独立，只通过管道传输数据，天然可以并行（只要数据流允许）；缺点是不适合交互式应用，共享状态麻烦。批处理顺序则是数据整批传递、不能并行，别把二者混了。 |
| 31 | “加密级别”同时影响安全性和性能，这属于 | A 权衡点 | ATAM 四类概念必须分清：敏感点（一个属性对某个决策敏感）、权衡点（一个决策同时影响多个质量属性且方向相反）、风险点（有潜在问题的决策）、非风险点（好的决策）。加密级别↑安全↑性能↓，是典型权衡点。 |
| 33 | 体系结构需求的三个来源 | A | 教材口径：质量目标、系统的商业目标、开发组织（开发人员）的商业目标。它们共同构成“架构驱动因素”。 |
| 34 | 企业集成自下而上的层次；数据集成模式 | C + A | 企业集成平台自下而上：网络集成、数据集成、会聚（应用）集成、服务（流程）集成，来源答案与此一致。数据集成常见模式：联邦、复制、接口（基于接口的集成），另有数据仓库/ETL 等。记忆：“网数聚服”。 |
| 39 | 进程通信风格的连接件 | D 消息传递 | 进程通信风格：构件是独立的进程，连接件是消息传递（同步或异步）。此题在 2025 下半年、2026 上半年都有姊妹题，属“常青树”。 |
| 45 | ATAM 中关于场景优先级的说法，错误的是 | A | ATAM 投票时把场景按“重要性”与“实现难度”做二维排序，用(H,M,L)表示，优先级是由干系人投票产生的，并不是“安全类场景天然优先”。题干里“安全性场景一定高优先级”这类绝对化说法，基本都是陷阱。 |
| 50 | 调用/返回风格的子风格不包括 | C 黑板 | 调用/返回风格包含：主程序/子程序、面向对象、层次型。黑板属于数据流以外的“以数据为中心（仓库）”风格。 |
| 51 | 事件驱动（隐式调用）中构件的特性 | B 独立、非耦合 | 事件驱动系统中事件发布者不知道谁订阅，构件相互独立、松耦合，通过事件总线交互。优点是易扩展演化，缺点是难以推断执行顺序与结果。 |
| 56 | ATAM 利益相关者头脑风暴的三类场景 | B 用例、增长、探索 | 用例场景（典型使用）、增长场景（预期的演化）、探索场景（极端、压力情形）。口诀“用增探”。 |
| 57 | 基于度量的架构评估中，评估过程推导出系统的 | A 质量属性 | 架构评估三类方法：基于场景（SAAM、ATAM、CBAM）、基于度量、基于数学模型。基于度量的方法通过对架构的静态结构度量，推导系统的质量属性（如可修改性、复杂度）。 |
| 60 | 体系结构演化过程缺失的步骤 | A 更新构件的交互 | 教材的演化过程：需求变化归类 → 制订演化计划 → 修改、增加或删除构件 → 更新构件的交互 → 构件组装与测试 → 技术评审。来源把缺失步骤判为“更新构件相互作用”，与教材一致。 |
深入讲讲：ATAM 四概念与质量属性场景六要素
这一块本场一口气考了三题半（条目 11、19、31、45、56），足见命题人对它的喜爱。我给你一个“一页纸”的整理：
| 主题 | 要点 | 易错点 |
|---|---|---|
| 质量属性场景 | 刺激源、刺激、环境、制品、响应、响应度量 | 把“响应”和“响应度量”互换；把“制品”理解成“人” |
| ATAM 阶段 | 陈述（表示）阶段 → 调查和分析阶段 → 测试阶段 → 报告阶段 | 只背步骤名，忘了“效用树在调查分析阶段生成” |
| 效用树 | 效用 → 质量属性 → 属性分类 → 场景；场景用 (重要性, 难度) 标注 | 少写“属性分类”这一层 |
| 四类点 | 敏感点、权衡点、风险点、非风险点 | 把“权衡点”当成“风险点” |
| 与 SAAM/CBAM | SAAM 侧重可修改性、场景驱动；ATAM 多属性权衡；CBAM 算成本收益 | 把 CBAM 说成找风险点 |
更完整的质量属性战术（可用性、性能、安全性、可修改性、可测试性、易用性）请回看《综合知识精讲（上）：架构基础与软件工程》。
3.2 软件工程、测试、设计模式、复用
| 条目 | 题意概括 | 答案 | 我的解析 |
|---|---|---|---|
| 14 | RUP 的驱动方式 | D 用例驱动 | RUP 三大特点：用例驱动、以架构为中心、迭代增量。四个阶段：初始、细化、构建、交付。 |
| 22 | 不属于白盒测试的技术 | A 功能测试 | 白盒：控制流（语句/判定/条件/路径覆盖）、数据流、变异测试等；功能测试是黑盒。 |
| 23 | 关于覆盖标准之间关系的错误描述 | D | 覆盖强弱：语句 < 判定 < 条件 < 判定/条件 < 条件组合 < 路径，但“条件覆盖”与“判定覆盖”并不互相包含：满足条件覆盖不一定满足判定覆盖（例如两个条件组合结果同为真或同为假）。来源文字提示错误项是“条件覆盖不必具备判定覆盖”的反面表述，我核对后认同答案 D，具体选项措辞请以正版试卷为准。 |
| 24 | 添加新功能属于哪类维护 | C 完善性 | 维护四类：改正性（改错）、适应性（环境变了）、完善性（加功能、改性能，占比最大约 50%）、预防性（为以后好维护而改）。 |
| 25 | 设计模式分类哪个正确 | D 原型属创建型 | 创建型 5 个：抽象工厂、工厂方法、单例、建造者、原型。解释器、观察者属于行为型，装饰器、代理属于结构型。 |
| 26 | “处理对象的创建，把创建与使用分离”属于哪类模式 | C 创建型 | 创建型模式的本质：封装对象的创建过程，把“用谁、怎么造”与使用方解耦。 |
| 32 | 界面元素与跳转关系用哪两种 UML 图表示 | A 类图和顺序图 | 界面元素可用类图（边界类）描述，界面跳转的交互顺序可用顺序图描述。也有人用状态图表示界面跳转，考试以来源答案为准，此条仅单一来源。 |
| 35 | 软件复用过程的第一阶段 | D 构造/获取 | 复用基本过程按来源口径：构造/获取构件 → 管理与存储 → 检索与提取 → 适配 → 应用。教材另一种描述是“构件库的建立是前提”，本条为单一来源。 |
| 36 | 处理元素相关，且必须按特定次序执行 | C 过程内聚 | 内聚强→弱：功能 > 顺序 > 通信 > 过程 > 时间 > 逻辑 > 偶然。过程内聚：元素按控制流程的顺序执行，但彼此数据不一定相关。与顺序内聚的差别：顺序内聚是“前者输出是后者输入”。 |
| 37 | 系统测试用来发现哪个阶段的错误 | B 需求分析阶段 | 测试与开发阶段对应（V 模型）：单元测试↔详细设计，集成测试↔概要设计，系统测试↔需求分析，验收测试↔用户需求。 |
| 38 | 用例图中参与者之间的关系 | C 继承（泛化） | 用例图中参与者之间只有泛化；用例之间才有包含、扩展、泛化。这是高频陷阱。 |
| 40 | 数据驱动脚本把测试输入存在哪 | B 数据文件 | 自动化测试脚本演进：线性 → 结构化 → 共享 → 数据驱动（输入存数据文件）→ 关键字驱动。 |
| 44 | 跨不同应用领域重用软件元素 | D 横向重用 | 横向重用：不同领域间重用（如标准库）；纵向重用：同一领域内重用（如某行业框架）。 |
| 46 | N 版本程序设计新增的三个阶段 | D | N 版本：在常规开发之外增加相异成分规范评审、相异性确认、背靠背测试。目的是通过多版本独立开发做容错。 |
| 52 | 配置管理的重要组成中不包括 | B UML | UML 是建模语言，不是配置管理标准或体系。CMMI、PMBOK、ISO 9000 是与过程/质量/管理相关的体系，来源把它们视作配置管理的关联体系。 |
| 53 | 螺旋模型基于哪个模型扩展 | A 快速原型 | 螺旋模型结合瀑布模型与快速原型，强调风险分析；来源选快速原型。 |
展开：覆盖标准对比表与例子（自写）
| 覆盖标准 | 要求 | 强度 |
|---|---|---|
| 语句覆盖 | 每条语句至少执行一次 | 最弱 |
| 判定覆盖（分支） | 每个判定的真、假分支至少各走一次 | 强于语句 |
| 条件覆盖 | 每个判定里的每个条件取真、取假各一次 | 与判定覆盖不互相包含 |
| 判定/条件覆盖 | 同时满足判定与条件覆盖 | 强于前两者 |
| 条件组合覆盖 | 每个判定里条件取值的所有组合至少一次 | 更强 |
| 路径覆盖 | 所有可能路径至少执行一次 | 最强（也最难做到） |
例子：判定 if (A && B)。用例 (A=真,B=假) 和 (A=假,B=真) 使 A、B 各取过真假，满足条件覆盖，但判定结果两次都是“假”，从未走到“真”分支，判定覆盖不满足。这就是“条件覆盖 ≠ 判定覆盖”的活例子。
3.3 操作系统、网络、数据库
| 条目 | 题意概括 | 答案 | 我的解析 |
|---|---|---|---|
| 5 | 不能作为死锁预防措施的条件 | C 互斥 | 死锁四必要条件：互斥、请求保持（占有等待）、不可抢占、循环等待。预防就是破坏其中之一。但互斥是资源固有性质（如打印机），通常无法破坏，所以实践里预防措施破坏的是另外三条。此题问的正是“互斥”。 |
| 6 | 传输层定义的协议 | B TCP/UDP | 应用层：FTP、SMTP、Telnet、NFS；传输层：TCP、UDP；网络层：IP、ICMP。 |
| 7 | 时间片用完，进程转为什么状态 | B 就绪 | 运行 → 就绪（时间片到或被抢占）；运行 → 阻塞（等 I/O）；阻塞 → 就绪（I/O 完成）；就绪 → 运行（被调度）。 |
| 12 | “性别”取值限制属于哪类完整性 | B 用户定义完整性 | 三类完整性：实体（主键非空唯一）、参照（外键）、用户定义（业务取值约束，如性别、年龄范围）。 |
| 13 | 多道批处理，两作业并发执行的最短时间 | D 220ms | 题面的 CPU/IO 时序我没有完整读到，这里只引用来源答案。解题套路：画甘特图，CPU 只能被一个作业占用，I/O 可与另一作业的 CPU 重叠，逐段累加即可。单一来源，答案待核实。 |
| 18 | 路由器工作在 OSI 哪一层 | A 网络层 | 物理层：集线器；数据链路层：交换机、网桥；网络层：路由器；应用层：网关。 |
| 27 | R(a,b,c) 与 S(b,c,d) 自然连接，结果列数 | A 4 | 自然连接按同名属性 b、c 等值连接，并去掉重复列：a、b、c、d 共 4 列。如果是等值连接（不去重）则是 6 列，考试爱拿这两个对比。 |
| 28 | 关系操作的特点 | C 集合 | 关系操作的特点是集合操作：操作对象和结果都是集合（元组的集合），而不是一次一条记录。 |
| 29 | R(A,B,C,D)，B→D、AB→C，求码 | C AB | A、B 都不出现在任何函数依赖的右边，必在码中；AB 的闭包：AB → C（由 AB→C），B → D，得到 ABCD，所以 AB 是码。我自己验算一致。 |
| 42 | 用户态执行特权指令引发的中断 | C 访管中断 | 按来源答案为“访管（自陷）中断”。考点辨析：访管中断由执行访管指令（系统调用）引发；用户态执行特权指令属于“非法指令”类的内部异常，两者在不同教材里归类略有差异，此条仅单一来源，按来源答案记。 |
| 48 | 分段存储中“段”的大小 | D 动态可变 | 页是固定大小（由系统决定），段按逻辑单位划分，大小不固定，可动态增长。页式对用户透明，段式对用户可见。 |
3.4 信息安全、法规与通信
| 条目 | 题意概括 | 答案 | 我的解析 |
|---|---|---|---|
| 1 | 保证信息机密性与完整性的安全特性（四个选项给出配对） | B + D | 信息安全基本属性：机密性、完整性、可用性，延伸有不可否认性、可控性。两个空分别落在“机密性”“完整性”上。 |
| 3 | 数据安全治理的目标与“分类分级”所属体系层级 | D + D | 这类题对应《数据安全能力成熟度模型》和数据安全治理框架：治理目标、数据分类分级、全生命周期（采集、传输、存储、使用、共享、销毁）安全。选项原文我读到的是概括形式，答案来自单一来源，待核实。 |
| 9 | 退职后相关发明的职务发明保护期 | B 1 年 | 《专利法实施细则》：退休、调离原单位后或劳动、人事关系终止后1 年内作出的、与原单位工作或分配任务有关的发明创造，属职务发明。 |
| 10 | 同一外观设计专利中相似设计最多数量 | A 10 | 同一产品两项以上相似外观设计可作为一件申请，最多 10 项。 |
| 15 | 关于 SQL 注入的错误说法 | A | 来源判定错误项是“使用 ORM 不能降低注入风险”一类的说法。知识核对：预编译（参数化查询）是首选防御；ORM 底层通常使用参数化查询，能显著降低风险，但拼接原生 SQL 时照样会被注入。 |
| 16 | 关于 SOAP 的错误说法 | B | SOAP 由信封、编码规则、RPC 表示、绑定四部分组成。来源认为错误项是“信封和编码在不同命名空间”的说法，与我对 SOAP 规范的印象并不完全吻合（规范中二者分别有各自的命名空间），此条仅单一来源，答案以来源为准，原选项措辞待核实。 |
| 41 | WSDL 描述 Web 服务的三个基本属性 | D | WSDL 回答三个问题：做什么（服务接口）、如何访问（绑定与协议）、位于何处（地址）。 |
| 43 | 安全审计的四个要素 | C | 来源答案：控制目标、安全漏洞、控制措施、控制测试。 |
| 47 | 关于 MD5 的错误说法 | D | MD5 输出 128 位，单向，但已被证明存在碰撞，不再抗碰撞，不应用于数字签名等安全场景；选“MD5 抗碰撞”为错。 |
| 49 | 为学习研究软件设计思想而使用软件 | A | 《计算机软件保护条例》：为学习和研究软件内含的设计思想和原理，通过安装、显示、传输或存储软件等方式使用软件的，可以不经软件著作权人许可，不向其支付报酬。 |
| 54 | 提高信道容量的方法 | C（字母待核实） | 这条我有保留。香农定理：C = B·log2(1+S/N)，增大带宽 B、提高信噪比 S/N 都会增大信道容量。来源给出“C”，转述里写成“大带宽 + 降低信噪比”，这与公式矛盾，很可能是转述或选项配对错位。我的判断：正确结论应是“增大带宽并提高信噪比”，具体哪个字母请看正版试卷，本文不强行下结论。 |
3.5 数学、管理计算与其他
| 条目 | 题意概括 | 答案 | 我的解析 |
|---|---|---|---|
| 2 | 0 到 1000 之间恰好有一位数字是 5 的整数个数 | B 243 | 我自己验算：一位数 5 只有 1 个；两位数 5x（x≠5）9 个，x5（x∈1–9，x≠5）8 个，共 17；三位数：百位 5 时另两位不是 5 共 9×9=81，十位 5 时 8×9=72，个位 5 时 8×9=72，共 225；1000 无 5。总计 1+17+225 = 243，与来源一致。 |
| 8 | 不属于“易用性”关注的 | C 环境修复能力 | 易用性关注：学习曲线（易学性）、完成任务效率、错误处理与满意度。“环境修复”更偏可用性/可恢复性。 |
| 20 | 容斥原理求三种球都不会的人数 | A 22 | 题目数据没有完整读到，仅引用来源答案。解题套路：总人数 − |A∪B∪C|，其中 |A∪B∪C| = |A|+|B|+|C|−|A∩B|−|A∩C|−|B∩C|+|A∩B∩C|。单一来源，待核实。 |
| 21 | 最短工期下的最少成本 | D 132 万 | 题面的活动网络图我没有读到，只引用来源答案。套路：先求关键路径得最短工期，再对非关键活动用最省成本的方式（延长工期换低成本）逐个选取。单一来源，待核实。 |
| 55 | 信息化需求的三个层次 | B 战略、运作、技术 | 教材口径：战略需求、运作需求、技术需求。 |
| 58 | 基于内容推荐方式“不属于优点”的是 | D 新用户问题 | 推荐算法对比：基于内容——不依赖其他用户、能推荐新项目/冷门项目，但有特征提取受限、过度专门化等缺点；协同过滤——依赖用户数据，有新用户/冷启动问题。严格说新用户在基于内容里也有冷启动，本条题干措辞我没读到原文，按来源答案。 |
| 59 | 专家系统采用的技术基础 | B 知识表示和推理 | 专家系统三要素：知识库、推理机、解释器/用户接口，核心技术是知识表示与推理。 |
3.6 英文阅读：黑板架构
来源提到这一场的英文阅读是一篇关于黑板架构系统的短文，5 个空，答案为 C、D、D、D、C。我没有读到原文文字，所以不做逐空解析，只给你做这类题的通用方法：先通读抓住“黑板 = 共享知识库，知识源独立、由控制组件调度”的主线，再看每个空前后的动词与名词搭配。黑板系统的三件套（知识源 Knowledge Source、黑板 Blackboard、控制 Control/Scheduler）建议在脑子里有英文词，不然英文题直接吃亏。参考词汇：opportunistic（机会式推理）、incremental（增量式）、hypothesis（假设）、solution space（解空间）。
3.7 其余综合知识题：答案待核实
综合知识共 75 题，本文整理的来源涵盖 60 个编号条目（含 5 个双空，约占 65 个答案点位）加 5 个英文空。考卷其余未被该来源覆盖的题目，我一概标“答案待核实”。CSDN、知乎上有多位博主的整理，但页面在我这边打不开或需要登录，所以没能交叉核对。如果你手上有完整正版试卷，建议对着速对表逐条核对，尤其是我标了“单一来源”的。
四、案例分析：能确认的两道与答题要点
案例分析这一科，我能读到的文字信息只有考生回忆的题目方向：
- 质量属性与功能性 / 云服务器高可靠性：填空部分涉及“质量属性 vs 功能性”的区别，以及可用性指标的填写（回忆中有“1 分钟内检测到故障、1 小时内恢复”之类的数值）；简答要求说明ping/echo 与心跳（heartbeat）两种故障检测方式的原理，并回答从资源利用率角度为什么心跳方式更合适。
- Cache-Aside 缓存架构：读流程与写流程的流程图填空；“线程 1 写、线程 2 读”时可能出现的缓存与数据库不一致，以及解决办法。
- 其余题目（以及分值、具体设问、标准答案）：答案待核实，我没有找到可读的文字版。GitHub 上的仓库里有案例真题 PDF，但我无法在这里读取 PDF 内容。
下面是我自己写的“考点答题要点”，不是官方参考答案，用来帮你补这两块知识。
4.1 故障检测：ping/echo 与心跳
| 对比项 | ping/echo | 心跳（Heartbeat） |
|---|---|---|
| 方向 | 监控方主动发 ping，被监控方回 echo（拉） | 被监控方周期性主动发送心跳消息（推） |
| 判定 | 在超时时间内收不到 echo 就判故障 | 在若干周期内收不到心跳就判故障 |
| 开销 | 每次检测是一来一回两条消息，监控方要维护请求与等待 | 单向一条小消息，开销约为一半，且可携带负载信息 |
| 适用 | 监控方集中、被监控对象少 | 被监控对象多、要减少监控流量与监控端压力 |
为什么从资源利用率看心跳更合适，答题三句话：① 心跳是单向消息，网络与 CPU 开销比一问一答的 ping/echo 小；② 监控方不需要为每个被监控对象维护等待回应的状态，压力更低；③ 心跳还能捎带状态信息（负载、版本），便于顺便做健康判断。此外要点出可用性 = MTBF/(MTBF+MTTR)，检测时间与恢复时间是响应度量，题目要求“1 分钟检测、1 小时恢复”就是对这两个度量的量化要求。可用性战术分三类：故障检测、故障恢复（冗余、回滚、重试等）、故障预防，详见《案例分析：题型拆解与答题模板》。
4.2 Cache-Aside（旁路缓存）读写流程与一致性
读流程：应用先查缓存 → 命中则直接返回 → 未命中则查数据库 → 把结果写入缓存（带 TTL）→ 返回。
写流程（推荐）：先更新数据库 → 再删除缓存（而不是更新缓存）。下一次读时重建缓存。
为什么“先写库再删缓存”：因为 Cache-Aside 中缓存与数据库是两个独立存储，由应用代码负责一致性。对比其他顺序：
| 方案 | 并发下的问题 |
|---|---|
| 先删缓存，再写库 | 删缓存后、写库前，另一个线程读到旧库并回填旧值到缓存，之后库被更新 → 缓存长期是脏数据 |
| 先写库，再删缓存 | 仍存在极小概率：读线程读库（旧值）后、回填缓存前，写线程完成写库并删缓存，读线程随后回填旧值 → 脏数据，但需要“读慢于写”，概率低，且有 TTL 兜底 |
| 先写库，再更新缓存 | 两个写线程交错时，缓存最终值可能与库不一致 |
线程 1 写、线程 2 读的一致性风险与对策：风险来自上表所述的交错；对策可答：延迟双删（写库后删缓存，延迟一小段时间再删一次）、缓存设置过期时间兜底、通过 binlog/消息队列异步订阅变更来删除或刷新缓存（如 Canal）、对强一致场景加读写锁或直接读库。再补两个经典缓存问题：穿透（缓存空值/布隆过滤器）、击穿（热点加互斥锁）、雪崩（TTL 加随机抖动、多级缓存、限流降级）。
五、论文：四道题的考查方向与写作方案
多个页面一致地给出了本场四道论文题的方向（我用自己的话概括，不照抄原文）：
| 方向 | 核心考查 | 难度感受（我的判断） |
|---|---|---|
| 论多种异构数据源集成方法 | 项目背景与角色；异构数据源集成有哪些方法（联邦、ETL/数据仓库、数据复制、中间件/API 等）；具体实施与问题 | 数据集成做过的人有素材，略偏技术细节 |
| 论软件维护及其应用 | 项目背景；软件维护的内容（四类维护）和提高可维护性的常用技术；实际维护中遇到的问题与解决 | 最“通用”，素材最好找 |
| 论面向服务的架构设计（SOA） | 基于 Web Service 的 SOA 实现过程；SOA 的特征、如何支撑功能重用；项目中如何落地及问题与对策 | 经典老题，套路成熟 |
| 论分布式事务及其解决方案 | 分布式事务的概念与难点；2PC/TCC/Saga/本地消息表/最大努力通知等方案；选型与落地 | 必须真做过才写得实，容易写虚 |
说明：各页面对这四道题的“试题几”编号不一致，所以我不标题号。没有找到官方标准范文，下面的提纲和素材全部是我自己整理的。论文通用骨架见《论文写作：套路、模板与素材库》。
5.1 论面向服务的架构设计（SOA）
概念要点：SOA 是一种把应用拆成松耦合、可复用、有明确接口契约的服务，通过标准协议进行交互的架构风格。基于 Web Service 的实现过程可按“服务建模 → 服务定义与描述（WSDL）→ 服务发布与注册（UDDI，现实中多用注册中心）→ 服务发现与调用（SOAP/REST）→ 服务编排与治理（BPEL、ESB）”来写。
SOA 的特征（评分常考）：
- 松耦合：服务提供方与消费方只依赖接口契约，不依赖实现。
- 位置透明、协议标准化（SOAP/HTTP/XML，或 REST/JSON）。
- 粗粒度服务、无状态倾向、可组合（编排成业务流程）。
- 服务自治、可重用，支持异构平台互操作。
典型挑战与对策：
| 挑战 | 对策 |
|---|---|
| 服务粒度难划分 | 按业务能力划分（可借 DDD 限界上下文），先粗后细，避免过度拆分导致调用链过长 |
| ESB 成为单点与瓶颈 | ESB 集群化、去中心化网关、或改用轻量级注册中心 + 客户端负载均衡 |
| 服务版本管理 | 接口向后兼容、版本号、灰度发布、契约测试 |
| 服务间安全 | WS-Security、OAuth2/JWT、网关统一鉴权 |
| 性能（XML 解析慢） | 缓存、异步消息、报文压缩、关键路径改用二进制或 JSON 协议 |
| 事务一致性 | 最终一致、Saga/补偿，避免跨服务强事务 |
提纲：摘要（项目、角色、SOA 落地与效果）→ 项目背景（烟囱式系统多、重复建设、需整合）→ SOA 概述与特征 → 基于 Web Service 的实现过程（结合自己项目）→ 服务划分与接口设计 → 实施难点与对策 → 效果（重用率、上线周期缩短、接口对接成本下降）→ 总结。
5.2 论异构数据源集成方法
| 集成方式 | 特点 | 适用场景 |
|---|---|---|
| 联邦数据库 / 数据虚拟化 | 数据不搬迁，统一查询层按需访问各源 | 实时性要求高、数据量适中、源端可访问 |
| 数据仓库 / ETL | 抽取、转换、加载到统一存储，支持分析 | 决策分析、历史数据汇总 |
| 数据复制 / 同步（CDC） | 变更数据捕获，实时或准实时同步 | 读写分离、多活、异构迁移 |
| 中间件 / 接口集成（API、消息） | 通过标准接口或消息队列交换数据 | 应用层松耦合集成 |
| 数据湖 / 湖仓 | 原始数据集中存储，按需建模 | 多模态、非结构化数据 |
实施难点：语义冲突（同名不同义、同义不同名）、编码与时区格式差异、主数据不一致（主数据管理 MDM）、数据质量（脏数据、缺失、重复）、性能与一致性。对策：统一元数据与数据字典、主数据治理、数据清洗规则、增量同步、数据血缘与监控。提纲沿用“背景 → 方法概述 → 选型与架构 → 实施难点 → 效果”。
5.3 论软件维护及其应用
四类维护：改正性、适应性、完善性、预防性（见 3.2 的条目 24）。提高可维护性的技术与方法：模块化与低耦合高内聚、遵守编码规范、完善文档、单元测试与回归测试、重构、设计模式、配置管理与版本控制、代码评审、静态分析、持续集成、日志与可观测性。维护过程中常见问题：文档缺失或过期、原开发人员流失、修改引入新缺陷（涟漪效应）、遗留系统技术债、需求变更频繁。对策可写“建立变更管理流程、自动化回归、逐步重构、逆向工程补文档、灰度发布”。
5.4 论分布式事务及其解决方案
| 方案 | 一致性 | 要点 | 缺点 |
|---|---|---|---|
| 2PC / XA | 强一致 | 协调者先准备后提交，两阶段 | 同步阻塞、协调者单点、性能差 |
| 3PC | 强一致（改进） | 增加预提交，降低阻塞 | 实现复杂，仍非绝对安全 |
| TCC | 最终一致 | Try 预留资源、Confirm 确认、Cancel 回滚 | 业务侵入大，需要幂等与空回滚处理 |
| Saga | 最终一致 | 长事务拆成本地事务，失败时执行补偿 | 补偿设计复杂，隔离性弱 |
| 本地消息表 / 事务消息 | 最终一致 | 本地事务与消息写入同一事务，再异步投递 | 需要重试、幂等消费 |
| 最大努力通知 | 弱一致 | 重复通知 + 查询接口兜底 | 适合对账型场景 |
理论支撑要讲清 CAP 与 BASE：分布式下网络分区不可避免，在一致性与可用性之间权衡，多数互联网业务选择基本可用、软状态、最终一致。落地时必须提到幂等性（唯一业务号、去重表）、重试与补偿、对账。
5.5 摘要示例（自写，仅供练手）
2023 年 5 月，我参与了某制造企业“业务协同平台”的建设，担任系统架构师，负责整体架构设计与集成方案。企业原有 ERP、MES、WMS 等系统各自为政，数据口径不一致、接口重复建设严重。本文结合该项目，论述了面向服务的架构设计：以业务能力为依据划分服务，基于 Web Service 定义服务契约，通过服务注册中心与网关实现发布、发现与治理，并采用消息队列与补偿机制保证跨服务的最终一致。实施中针对服务粒度、性能与版本兼容等问题采取了相应对策。平台上线后服务重用率明显提升，新业务对接周期显著缩短，验证了方案的有效性。
数字我故意不写死，请在你自己的论文里换成真实项目的量化结果。
六、本场考点热度总结与复习建议
| 科目 | 高频考点 | 建议 |
|---|---|---|
| 综合知识 | 架构风格（黑板/管道/事件驱动/进程通信/调用返回）、ATAM 全家桶、4+1、质量属性场景、内聚、覆盖标准、维护类型、死锁与进程状态、函数依赖与码、法规（专利/著作权）、SQL 注入与 MD5 | 架构与评估是提分主力；法规类靠记忆，投入小回报稳；计算题（计数、容斥、成本工期）要会套路 |
| 案例分析 | 可用性战术与故障检测、缓存一致性（Cache-Aside） | 分布式与缓存是近年案例的常客，答题要“机制 + 场景 + 权衡” |
| 论文 | SOA、异构数据集成、软件维护、分布式事务 | 准备“服务化/集成”“可维护性”“分布式一致性”三块通用素材 |
一句话备忘：2024 下半年这一场，综合知识靠“架构风格 + ATAM + 软件工程基础”拿大头，案例盯住可用性故障检测与 Cache-Aside，论文从 SOA、数据集成、软件维护、分布式事务里挑你最熟的一条写；没有可靠答案的题，我不替你编。
七、答案冲突与待核实项
- 考试日期：希赛网写 11 月 10 日，环球网校写的是 11 月 9 日至 12 日的整体窗口期，以官方公告为准。
- 案例分析选做规则：环球网校页面表述为“5 选 2”，与专栏惯用的“必答 + 选做、共 3 题”口径不同，以准考证说明为准。
- 第 54 条（信道容量）：来源转述与香农公式矛盾，字母待核实。
- 第 13、20、21 条：只有来源答案，没有读到完整题面，待核实。
- 第 3、15、16、23、32、35、42、58 条：单一来源，且我对选项措辞有疑虑，已在各条说明。
- 综合知识其余题目、案例分析其余题目与答案：待核实。
- CSDN 与知乎页面无法访问，未完成多源交叉验证。
参考资料
- 博客园：2024 年 11 月架构真题解析（综合知识）——本文综合知识 60 个条目与英文阅读答案的唯一逐题来源。
- 希赛网：2024 下半年系统架构设计师案例分析页——确认考试日期 11 月 10 日与上下午时间安排。
- 环球网校：2024 年下半年系统架构设计师考试时间安排——确认科目题型与时长，及“11 月 9 日至 12 日”的窗口期表述。
- 知乎：2024 下半年软考系统架构设计师真题汇总（考生回忆）、CSDN：2024 下半年案例分析、CSDN：2024 下半年论文——仅在搜索结果摘要中看到案例与论文题目方向，页面本身无法打开，故只采用其摘要中的题目方向。
- GitHub：xxlllq/system_architect——确认仓库收录 2024 年案例分析真题 PDF（未能读取 PDF 内容）。
再次提醒：以上均为第三方整理，可能存在遗漏或错误，请以考试主办方发布及正版真题为准；本文解析与素材为个人整理，不代表官方评分标准。
一起聊聊