系统架构设计师案例分析复习笔记

适用：2026 下半年备考；依据已核实的“2022 年审定、2023 年新版大纲”及 2016—2025 年指定真题样本。整理：2026-09-20。 嵌入式专项不复习；保留通用可用性、安全性、云边协同。尚未核实另一份更晚大纲，本文不宣称适配未取得的版本。 本文为知识归纳和作答方法，不是官方标准答案、评分细则或命题预测。未展开真题逐空答案，也不代表你已完成这些知识的学习。

阅读顺序与依据

先读第 1—3 章，建立“质量属性 + Redis + 应用架构”主线；接着读第 4—6 章，补足考纲明确要求的云原生、安全和大数据；第 7—9 章用于备用题与范围补缺。最后用第 10 章自检。

频率按考期样本去重，不是分值比例；同题可含多个标签。详情见统计报告。

考纲映射：第 3 章对应案例考纲 §3、§5，第 4 章对应 §4，第 5 章对应 §8，第 6 章对应 §9，第 9 章对应 §1、§2、§7。质量属性、Redis、建模和新题技术是跨章节基础或真题实考内容，不将它们虚构为考纲独立章节。

1. 质量属性、架构评估与风格【优先掌握】

1.1 从需求中识别质量属性

功能需求回答“做什么”，质量属性回答“做得怎样”，设计约束回答“必须遵守什么限制”。不要把所有数字都归为性能，也不要只凭业务背景判断。

作答方式：先写属性，再引用题设指标或约束作为依据。若题目给定分类表，遵循表中口径，不自行换成另一套质量模型。

开发期通常关注可修改、可维护、可测试、可重用、可移植等；运行期通常关注性能、可用性、安全性、可靠性等。这是考试分类角度，不表示某属性只在一个阶段有意义。

1.2 质量属性场景六要素

刺激源 → 刺激 → 环境 → 制品 → 响应 → 响应度量。

表达模板：在【环境】下，【刺激源】对【制品】产生【刺激】，系统执行【响应】，并达到【响应度量】。

失分点：遗漏刺激源；把“切换备用节点”与“多少秒内完成切换”混为一项；将“提出变更”与“实现变更”混淆。必须读完整句子，而不是固定背某个短语属于哪个要素。

1.3 效用树、风险、敏感点与权衡点

效用树常用层次：效用 → 质量属性 → 属性细化 → 可评价场景。叶子场景按业务重要性和实现难度等排序；两个 H/M/L 的顺序以题目图例为准。

• 风险：可能导致质量目标无法满足的架构决策或其隐患。
• 非风险：经分析，在给定假设与条件下能够满足要求的决策，不是永久无风险。
• 敏感点：对某个质量属性有显著影响的架构参数或特性。
• 权衡点：同时影响多个质量属性的敏感点，需要平衡收益与代价。

答题时写清“哪项决策影响哪个属性、为什么”。不能只写“这里有性能风险”。权衡也不意味着所有影响都必须一好一坏，但常见题目用相互制约体现它。

ATAM 九个活动：介绍 ATAM → 介绍业务驱动 → 展示架构 → 识别架构方法 → 生成效用树 → 分析架构方法 → 头脑风暴并排序场景 → 再分析架构方法 → 展示结果。活动常组织为四组，别把分组数当活动数。

SAAM 最初侧重可修改性；ATAM 关注多质量属性权衡；CBAM 在架构分析中进一步考虑成本与收益。是否需要写流程，以小问要求为准。

1.4 常见质量属性战术

Ping/Echo：监测者发请求，被监测者返回响应，超时怀疑故障。心跳：被监测者周期发送存活信号，长时间未收到则怀疑故障。两者都可能因网络延迟产生误判；资源消耗应结合节点数量、报文频率和部署结构比较，不能无条件断言心跳更省。

可用性可用稳态近似 A = MTTF / (MTTF + MTTR)；题目若使用 MTBF，先确认其定义是否包含修复时间。不要机械套用不同口径的公式。

1.5 架构风格比较

比较模板：“方案 A 通过【机制】满足【题设要求】，优势是【对应指标】，代价是【限制】；方案 B ……；本题优先【目标】，因此选择【方案】。”

“灵活”“高性能”必须解释原因。仓库风格不等于数据仓库分析系统；解释器也不等于所有处理都不需要重启。

2. Redis 与缓存【选做主线】

2.1 数据类型与业务需求对应

ZSet 常见操作：ZADD 写成员及分数；ZRANGE 获取范围；ZSCORE 查成员分数。排名方向、按索引还是分数查询，按题目要求判断。

2.2 三类缓存故障

布隆过滤器：位数组 + 多个哈希函数。某位为 0 可判定不在集合；全为 1 只能判定“可能存在”。标准插入型过滤器在正确使用下无假阴性、有假阳性；普通位数组不能直接安全删除元素。错误删除、未同步新增数据等会破坏业务判断。

2.3 Cache-Aside 与并发一致性

读：读缓存 → 命中返回；未命中 → 查数据库 → 回填缓存 → 返回。

常见写：更新数据库 → 删除对应缓存。理由是避免直接维护两个可变副本的双写顺序冲突；这仍不是强一致保证。

必须能说明的竞态：一个读请求未命中并读到旧数据库值，随后另一个请求更新数据库且删缓存，前一个读请求最后把旧值回填缓存，造成短暂不一致。另一类风险是数据库成功而删除缓存失败。

强一致要求很高时，可将关键读直接落到权威存储，并结合事务/并发控制设计，不要宣称“加一个锁”就解决所有系统一致性问题。

2.4 互斥重建与逻辑过期

互斥重建：未命中 → 尝试获锁 → 获锁后再检查缓存
                    → 仍未命中才回源 → 回填 → 安全释放锁
          未获锁 → 有界等待/重试/降级

逻辑过期：读出缓存值及逻辑过期时间
          未过期 → 返回
          已过期 → 一个线程获锁并异步重建；其他线程返回旧值
          物理上没有缓存值 → 另设初始化/回源路径

互斥方案减少并发回源，但可能阻塞；逻辑过期优先可用性和低延迟，允许旧值。两种方案均要考虑重建失败、锁过期和超时。缓存重建互斥不是数据库事务锁。

2.5 持久化、复制、集群不要混淆

首次全量同步：协商复制信息 → 主库生成快照，同时记录期间增量写 → 从库加载快照 → 应用增量 → 持续复制。不要把快照生成期间的新写操作遗漏。

部分重同步：断线后若复制身份与偏移满足条件、所需历史仍在 backlog 中，可仅补发缺失部分，否则需全量。正常写命令传播与断线后的部分重同步应区分。

AOF 常见刷盘策略为 always、everysec、no；“每秒刷盘约有秒级丢失窗口”是通常描述，不是绝对上限保证。复制不等于备份：误删除也会被复制。

2.6 过期、淘汰、分片、锁

• 过期删除针对设置 TTL 且已到期的键，常见惰性检查与主动周期清理。
• 内存淘汰针对达到内存限制的情况，根据策略淘汰；可涉及 LRU、LFU、随机、TTL 或拒绝写入等。volatile-* 只针对带过期时间的候选键，allkeys-* 面向所有键。
• 普通哈希取模：节点数变化易导致大量重映射。
• 一致性哈希：节点与 key 映射到环，节点变化通常仅影响相邻范围；虚拟节点改善负载均衡，但不能自动消除热点。
• Redis Cluster 使用 16384 个哈希槽，不要把它直接写成一致性哈希环。
• Redis 锁可用带过期时间的原子 SET ... NX PX ...，值保存唯一持有者标识。释放时必须原子比较标识并删除，防止删掉新持有者的锁。
• 锁要考虑租期、续约、业务超时、主从切换、网络分区。严格排他场景还可能需要 fencing token 等机制，不能把单 Redis 锁描述为所有故障下绝对可靠。

数据库锁 vs Redis 锁：数据库方案与事务结合方便，但锁竞争和连接占用较重；Redis 访问快，但需要额外处理租期与失效语义。按一致性、性能、故障行为比较，而不是只答“一个快一个慢”。

3. 分层、SOA、微服务与 DDD【选做主线】

3.1 看架构图，先判断职责

常见请求链是“客户端 → 网关/反向代理 → 应用服务 → 数据访问 → 存储”，但实际系统会有异步消息、缓存旁路和独立静态资源链。根据图中箭头、容器边界和题设职责填图，不凭某个产品名猜固定层。

MVC：Model 管理模型及相关业务数据/行为，View 展示，Controller 处理输入与调度。MVP 由 Presenter 协调视图与模型；MVVM 通过 ViewModel 暴露视图状态和操作，常配合数据绑定。MVC 三角色不等于三台机器，也不与每一种三层架构一一对应。

ORM：在对象模型与关系模型之间建立映射，减少重复持久化代码，提高开发效率；需防止 N+1 查询、过度加载、复杂查询效率差。加数据访问层的目的是隔离持久化细节、集中管理访问，而不是天然提升查询速度。

连接池复用连接并控制并发，但池越大不一定越快；应结合数据库承载能力和超时设计。事务要说明原子性、一致性、隔离性、持久性；数据库 ACID 中的一致性与分布式副本一致性不是同一口径。

3.2 Web 高并发组件

限流控制请求进入速率；熔断在依赖持续异常时暂时停止调用；降级提供简化服务；隔离避免一个故障耗尽共享资源。它们目标不同，可组合使用。

3.3 SOA 与服务通信

SOA 将业务能力组织为可通过契约访问、可组合的服务，强调松耦合与互操作。ESB 提供路由、协议适配、消息转换和服务集成等能力；不要把 ESB 说成所有业务逻辑必须经过的万能中心。

• SOAP：基于 XML 的消息协议。
• WSDL：描述服务接口、操作、消息和绑定等。
• UDDI：服务注册与发现相关规范。
• BPEL：业务流程编排语言。
• REST：架构风格，强调资源、统一接口、无状态、可缓存、分层等约束；不是一种报文格式。

HTTP API 使用 JSON 不自动等于 REST；无状态是服务端不依赖隐式会话上下文理解请求，不是系统没有数据库或业务状态。

3.4 微服务收益与成本

收益：按业务能力拆分、独立部署、独立扩展、团队自治、故障隔离。成本：分布式通信、数据一致性、链路追踪、测试部署与运维复杂度增加。小系统或边界不清晰时，模块化单体可能更合适。

服务治理包括注册发现、配置、网关、超时、重试、熔断限流、可观测性。重试必须有超时预算、退避和幂等，否则故障时可能形成重试风暴。

CAP：发生网络分区时，不能同时满足其严格定义下的一致性与可用性；不是随时任意“三选二”，也不能只写“选 AP 就不需要一致性”。BASE 以基本可用、软状态、最终一致性描述一类设计取向，仍需具体收敛机制。

消费幂等常用业务唯一标识、唯一约束或状态机；去重判断与业务更新要注意原子性。不要只写“MQ 保证消息不重复”。

3.5 DDD 与弱网协同

限界上下文：领域模型适用的明确语义边界，边界内术语、规则与含义保持一致。作用是消除歧义、控制复杂性、支持独立演进，并明确集成关系。上下文不必一一对应数据库或微服务。

• 实体：依靠身份标识区分，状态可以变化。
• 值对象：由属性值定义，通常设计为不可变。
• 聚合：围绕业务一致性边界组织相关对象，外部通过聚合根访问。
• 领域服务：无法自然归属单个实体/值对象的领域行为。
• 应用服务：编排用例、事务和调用；核心规则放在领域模型。
• 防腐层：隔离外部模型，避免外部语义侵入本领域。

弱网题答题链：识别延迟/断连、重复、丢失、冲突 → 本地持久化与关键配置预加载 → 异步同步队列 → 唯一标识与幂等 → 重试和断点续传 → 版本/业务规则处理冲突 → 显示待同步状态。

“最终一致”必须写如何重试、如何去重、如何检测和处理冲突。订单、库存等不能不加判断地用“最后写入覆盖”。

4. 云原生【考纲补强】

4.1 云原生不是把应用搬到云主机

云原生通过服务化、弹性、自动化、可观测等设计，利用云平台能力提升交付与运行效率。常见支撑是容器、微服务、DevOps、持续交付、声明式管理等；采用其中一个技术不等于完成云原生改造。

Serverless 不是没有服务器，也不等于只有 FaaS。服务网格不替代业务正确性设计，网关主要处理入口流量，网格主要治理服务间通信。

4.2 可观测性与弹性

• 指标 Metrics：趋势、容量和告警，例如延迟分位数、错误率、吞吐量。
• 日志 Logs：具体事件及上下文，便于追查。
• 链路 Traces：跨服务请求路径与耗时，定位慢调用和错误传播。
• 三者以请求标识等关联；只增加日志量不能替代可观测设计。

弹性伸缩需考虑负载指标、阈值、冷却时间、启动耗时、最小/最大副本和下游容量。应用扩容而数据库仍是瓶颈时，收益有限。高可用还需要跨故障域部署和恢复验证。

4.3 改造题的作答顺序

现状瓶颈 → 业务边界 → 技术方案 → 数据迁移与兼容 → 灰度验证 → 监控与回滚 → 收益和风险。

持续集成重在频繁集成与自动验证；持续交付使版本保持可发布状态；持续部署将通过验证的变更自动发布生产。蓝绿部署便于切换与回退但占资源；金丝雀发布逐步放量，但需要流量划分和指标判断。数据库不兼容变更会破坏应用回滚，需单独设计。

5. 安全架构【考纲补强】

5.1 从保护目标推导措施

认证回答“你是谁”，授权回答“你能做什么”，审计回答“谁在何时做了什么”。遵循最小权限、默认拒绝、职责分离、纵深防御。

哈希本身不提供机密性，也不自动证明发送者身份；加密本身不一定防篡改。数字签名支持来源验证与完整性，是否能提供可采信的不可否认性还取决于密钥、证书和流程。

5.2 关键安全模型

上下指安全/完整性级别，不是架构图中的楼层。“写”与“读”规则不能反背，也不要忽略模型变体或题目给定条件。

WPDRRC 六环节：预警 Warning、防护 Protect、检测 Detect、响应 Respond、恢复 Restore、反击 Counterattack。三大要素通常概括为人员、策略、技术。考试可写完整环节；实际处置中的反制须限于合法授权的防御范围。

5.3 常见应用安全问题

TLS 保护传输链路，不解决应用授权和数据库静态数据泄露。密码存储宜用带盐的专用密码哈希机制，不用可逆加密当作通用密码存储方案。

5.4 AES 与密钥管理

AES 分组长度固定为 128 位，即 16 字节；密钥长度可为 128/192/256 位。长数据采用安全工作模式处理，不能把每块独立用 ECB 加密后宣称安全。

工程上通常优先成熟库的认证加密，如 AES-GCM：遵守同一密钥下 Nonce 不重复的要求，验证认证标签，妥善管理密钥与随机数。CBC 等需要正确填充，并另行设计完整性认证；不是所有模式都需要块填充。

密钥生命周期：生成 → 安全分发/保存 → 使用权限控制 → 轮换 → 撤销与销毁。避免在代码、日志、配置仓库中暴露密钥。

5.5 安全方案题框架

资产和边界 → 威胁与攻击面 → 分层控制 → 监测审计 → 应急与恢复 → 验证。

必须把措施放到具体位置：网关认证、服务端授权、数据库最小权限、链路 TLS、集中密钥管理等。备份题说明备份范围、频率、隔离、恢复验证与 RPO/RTO；RPO 是可容忍的数据回退时间，RTO 是恢复服务的目标时间。

6. 大数据与数据架构【考纲补强】

6.1 Lambda 与 Kappa

Lambda 的批处理层处理完整历史数据形成批视图，加速层处理尚未进入批视图的近期数据，服务层面向查询。Kappa 不是“无需存储历史”，其重算通常依赖可保留、可重放的事件日志。

流处理还要考虑事件时间与处理时间、乱序、窗口、水位线、状态持久化和恢复。不要仅凭产品名判断架构，一种引擎可能同时支持批和流。

6.2 存储与检索选型

冷热分层：按访问频率、延迟要求与保留周期选择 SSD、磁盘或归档介质；收益是成本与性能匹配，代价是迁移、召回延迟和管理复杂度。

空间数据可用 GeoJSON 等表达，并结合空间索引支持查询；要区分矢量和栅格数据，不把所有 GIS 数据都当普通经纬度字段。

6.3 Elasticsearch 分析器

分析链通常包括字符过滤、分词器、token 过滤。索引时与查询时的分析方式应匹配业务。精确标识通常选择 keyword 类字段；全文文本选择适合语言与检索需求的分析器。

6.4 数据库设计基础

范式旨在减少冗余及更新异常；反规范化以冗余字段、预计算或关系合并换取读性能，代价是额外存储和一致性维护。不要认为范式越高越适合所有读密集业务。

反规范化必须回答“谁更新冗余值、何时更新、失败如何补偿”。触发器便于数据库内集中维护但增加隐式耦合；应用事务可明确控制但所有入口需遵守；异步更新吞吐好但有延迟。

主键唯一标识实体；外键表达引用约束；派生属性可由其他数据计算得到。概念模型、逻辑模型、物理模型分别关注业务概念、逻辑结构、具体存储实现，不能混为一张数据库表设计图。

7. UML、DFD、ER 与 Petri 网【备用方向】

7.1 UML 常见得分点

• 参与者在被建模系统边界外，与系统交互；不只包括人，还可能包括外部系统、设备或触发机制。内部数据库通常不是系统外参与者。
• 用例描述参与者借助系统实现目标的行为，不按菜单按钮数量机械拆分。
• include 表示包含公共行为，箭头由包含者指向被包含用例。
• extend 表示在规定扩展点和条件下增加行为，箭头由扩展用例指向基础用例。
• 泛化箭头指向一般/父元素；不要把任何“先后发生”的用例都画成 include。

多重性写在关联端，表示一个对端对象可关联该端多少实例。0..1、1、0..*、1..* 含义必须区分。

7.2 顺序图与其他行为图

顺序图常见元素：参与者、对象/生命线、执行规格、消息、组合片段。

• 同步消息：调用者通常等待完成。
• 异步消息：发送后无需等待被调用者完成即可继续。
• 返回消息：表示结果返回，常用虚线。
• alt 多分支，opt 条件可选，loop 循环，par 并行，break 满足条件后中断所包围的交互。

顺序图强调消息时序；通信图强调对象链接与协作关系，常用编号表达次序。状态图围绕对象状态及事件转换，活动图围绕工作流和控制流。

对象模型表达静态结构，动态模型表达状态/交互变化，功能模型表达处理与数据变换；三者相互约束，不是三个互不相关的系统。

7.3 DFD 与 ER

DFD 四要素：外部实体、加工、数据流、数据存储。它描述数据如何变换，通常不表达精确执行顺序或控制时序。

检查步骤：外部实体是否完整 → 每项业务是否有加工 → 输入输出是否足够 → 数据存储是否读写闭合 → 是否遗漏报表等输出 → 父子图是否平衡。

平衡原则：父图中某加工的边界输入输出，应与其子图边界输入输出在语义上保持一致；组合数据流可细分，但必须能对应。常见错误是黑洞（只有输入）、奇迹（只有输出）、灰洞（输入不足以产生输出）。

ER 识别实体、属性、联系、基数与参与约束。多对多关系在关系模型中通常用关联表实现。不要把实体、属性和业务动作混放在同一层次。

7.4 Petri 网

• 库所 Place 表示条件或状态；变迁 Transition 表示事件/活动。
• 弧连接库所与变迁，基本网中不是任意同类节点互连。
• Token 表示标识状态；满足输入条件才使能，变迁发生后按弧权消耗/产生 token。
• 可达性：某标识能否由初始标识到达。
• 有界性：库所 token 数是否存在有限上界；安全网通常指 1 有界。
• 活性：从可达状态出发，变迁是否仍可能在后续被使能/发生；不能简化为“当前有一条路能走”。
• 公平性：关注执行中是否无限期饥饿，需要结合采用的公平性定义与执行假设。

并发汇合通常要等各输入条件齐备；选择分支与并行分支不能混淆。没有初始标识或完整图时，不能武断判断全部可达性、活性。

业务流程建模可从流程节点、流程内容、流程权限等维度组织。Petri 网用于形式化动态行为，不等同于普通流程图换一套符号。

8. 知识图谱、异步采集与区块链【近期题补充】

这部分有较新样本支持，但不能称为已经验证的长期高频。只保留应用侧内容，不展开端侧 AI/嵌入式资源池。

8.1 知识图谱问答

知识图谱以实体、关系及属性表达知识，常见构建链为：多源数据 → 清洗 → 模式/本体设计 → 实体与关系抽取 → 融合消歧 → 存储与更新。

问答链：问题解析 → 实体识别和链接 → 意图识别 → 生成检索/查询 → 知识检索 → 组织答案。识别实体是发现名称，实体链接是把名称对应到知识库中具体实体。

图存储便于多跳关系遍历与关联分析；选型要看查询模式、规模、事务和更新要求，不是所有知识图谱都必须用同一类图数据库。图谱有错误、缺失或过期时，答案仍会受影响。

8.2 Scrapy 与异步 I/O

异步 I/O 允许发起 I/O 后继续其他工作，完成后通过事件、回调等处理结果；适合大量等待型任务。它不自动加速 CPU 密集计算，也不等于每个请求新建一个线程。

8.3 区块链

常见六层教学模型：数据层、网络层、共识层、激励层、合约层、应用层。数据层组织区块与加密关联；网络层传播与通信；共识层就账本状态达成一致；激励层安排经济机制；合约层承载可执行规则；应用层提供业务功能。联盟链等实现不一定具备独立的代币激励设计。

智能合约按约定条件自动执行规则，帮助实现流程约束、协作和记录；不保证输入数据真实，也不保证代码无漏洞。上链前的数据录入、核对、审核，以及链下事实来源仍需治理。

“不可篡改”应理解为既定共识与攻击假设下难以单方篡改、可校验追溯，不是任何条件下绝对不能改。敏感原文不宜因为可上链就全部上链，可考虑链下保存、链上存摘要和凭证。

9. 其余考纲基础【覆盖范围，适度掌握】

9.1 系统计划与企业架构

可行性通常从技术、经济、运行/组织及法律等方面论证；题目若给定分类，以其要求为准。系统方案比较写清目标、约束、现状、选项、评价依据、风险与迁移方式。复用旧系统要考虑兼容、数据质量、维护成本和安全风险，不只算采购成本。

企业总体架构可从战略、业务、应用、信息基础设施等层面组织；TOGAF 常见架构域是业务、数据、应用、技术，不把这两套划分强行一一对号。

ADM 常见阶段：预备阶段 → A 架构愿景 → B 业务架构 → C 信息系统架构（数据/应用）→ D 技术架构 → E 机会与解决方案 → F 迁移规划 → G 实施治理 → H 架构变更管理。需求管理贯穿各阶段，过程可迭代。

信息化规划方法：关键成功因素法 CSF 从成功关键因素推导信息需求；战略目标集转化法 SST 把组织战略目标转为信息系统目标；企业系统规划法 BSP 分析业务过程与数据类等，形成信息架构。

9.2 通信与网络基础

网络安全隔离包括 VLAN、子网、访问控制和物理隔离等；VLAN 划分不能替代全部授权与防火墙策略。VPN 用于在非可信网络上建立受保护连接，协议与部署方式要匹配场景。绿色网络可从设备能效、资源整合、按需启停及链路优化考虑，同时满足性能与可靠性要求。

10. 作答方法与复习自检

10.1 四类问题的回答骨架

写“措施 + 机制 + 题设目标”，少写“提升效率、增强安全、提高稳定性”这类没有机制的结论。题目要求三种方案时，列三个机制不同的方案，不用同义词凑数。

给定字数时优先覆盖要求的维度与数量；不要把工程上所有可能方案全部堆上去。知道准确术语就直接写术语，并用题设解释适用性。

10.2 第一轮自检清单

以下只是核对项，未勾选不代表已判定不会，勾选应以你能独立复述或完成练习为准。

• 从需求中区分功能、质量属性和约束。
• 写全六要素，区分刺激、响应、响应度量。
• 读效用树，区分风险、敏感点、权衡点。
• 按性能、灵活性、扩展方式比较主要架构风格。
• 画出 Cache-Aside 读写路径，讲清至少一种并发不一致时序。
• 区分穿透、击穿、雪崩，说明方案代价。
• 区分持久化、复制、Sentinel、Cluster 与备份。
• 说明 Redis 锁的原子获取、安全释放和租期风险。
• 看分层图能解释组件职责，而不是只认产品名称。
• 比较 REST、gRPC、消息通信与服务一致性方案。
• 解释限界上下文，并提出包含幂等和冲突处理的弱网同步方案。
• 比较容器、Mesh、Serverless，说明改造收益与成本。
• 写出安全目标、模型、分层控制与 AES 使用要点。
• 比较 Lambda/Kappa，并说明冷热数据的存储策略。
• 区分 UML、DFD、ER、Petri 网的表达对象和约束。

10.3 配套真题入口

仅列练习定位，不提供逐题答案。题目和图表仍以各文件的版本说明为准。

不要依据固定题号选题。先看各小问是否会答，再从可选题中选择把握最大的题；嵌入式题的编号会变化。

来源与维护说明

1. 高频统计与考纲映射报告：样本、计数和来源限制。
2. 案例分析考纲：确定专题范围；综合知识考纲：跨章节基础。
3. 软件架构参考、软件工程参考、信息系统参考：作为知识整理参考。它们属于培训材料转写，不能视为逐字可靠的官方标准。
4. 2020—2025 题目见前文链接，2016—2019 来源见统计报告；题目来源只能证明历史考查，不能把非官方解析提升为标准答案。
5. 清华大学出版社大纲信息：版本为 2022 年审定、出版社标注 2023 年新版，核验日期 2026-09-20。

本文优先使用通行技术定义，对缓存一致性、CAP、安全加密等保留适用条件。文中结构图和表达骨架是自制知识示意，不是真题原图。若之后取得不同新版的正式大纲，应先核实适用考期，再调整范围；不要仅因教材重印就认定改纲。

版权声明: 本文首发于 指尖魔法屋-系统架构设计师案例分析复习笔记：高频考点与新版考纲（https://blog.thinkmoon.cn/post/1042-notes-system-architect-case-analysis/） 转载或引用必须申明原指尖魔法屋来源及源地址！