案例5 选 3，每题 25 分，共 75 分，合格线 45 分。阅卷按要点给分，不按字数给分。
"关键词命中 = 得分"。别写大段铺垫，直接上术语和结论。综合知识做得越快，案例分析时间越充裕——这是连考最大的红利。
搞清楚题目在考什么能力，才知道该准备什么。按题干问法统计：
| 能力类型 | 占比 | 典型问法 |
|---|---|---|
| 补充填空（把表/图填完） | 39.7% | "将合适的质量属性填入图 1-1 的 (1)(2) 空白处" |
| 设计方案（怎么做） | 29.9% | "逻辑数据模型设计包含哪些任务？应包含哪些实体？" |
| 概念说明（是什么） | 26.2% | "说明时序数据库的含义" |
| 方案选型 + 理由 | 17.8% | "管道-过滤器 vs 仓库，更适合哪个？为什么？" |
| 风险/缺点列举 | 16.8% | "列举该四层架构可能存在的五类不足" |
最大头是补充填空（近 40%）——这类题的答案往往就在题干里，考的是"认得出"，不是"背得出"。
| 维度 | 综合知识（同场前半段） | 案例分析（同场后半段） |
|---|---|---|
| 问法 | "XX 是什么" | "给你一段场景，判断/选择/设计" |
| 答案来源 | 记忆 | 题干 + 知识，一半在材料里 |
| 答题形态 | 选项 | 填空 / 简答 / 表格补全 |
| 准备方式 | 背小册 | 练答题套路 |
案例题不要死记，要记"这类问法该怎么起手"。
5 道大题选 3 道作答，选题本身就是策略。
"三长一短选最短"——题干短的题，说明信息密度低、容易读。
应用（`http://127.0.0.1:8321`）的案例卷里，每个小问下方都有「✅ 对答案自评」按钮——点开就是这道题的采分点清单，你可以边写边勾，实时看命中率。
自评命中率低于 60% 的题，就是你这一类的薄弱点，回去补对应模块。
Web 应用设计是案例第一大板块（19/75 大题），高频三件套：缓存 / 高并发 / 微服务与消息队列。
| 子题型 | 出现次数 | 典型问题 |
|---|---|---|
| Redis 缓存与一致性 | 最高 | 缓存穿透/击穿/雪崩、双写一致性、过期策略 |
| Redis 主从与持久化 | 高 | 主从同步流程、RDB vs AOF |
| 高并发与分布式锁 | 高 | 悲观锁 vs 乐观锁、秒杀、库存扣减 |
| 微服务与消息队列 | 中 | 服务拆分、异步解耦、幂等 |
| 负载均衡 | 中 | 四层 vs 七层、算法选择 |
这一块几乎年年考缓存，Redis 两件事（一致性 + 持久化）必须能默写。
缓存穿透、击穿、雪崩，名字像但成因完全不同，考题最爱让你区分。
| 问题 | 成因 | 解决方案 |
|---|---|---|
| 穿透 | 查不存在的数据，请求全打数据库 | 布隆过滤器、缓存空值 |
| 击穿 | 单个热点 key 过期瞬间大量请求涌入 | 互斥锁重建、逻辑过期 |
| 雪崩 | 大量 key 同时过期或 Redis 宕机 | 过期时间加随机、多级缓存、高可用 |
"穿不存在、击单个、雪一片"——三个字区分开，别答串。
缓存和数据库双写时，怎么保证不脏读。核心是更新顺序和删除策略。
"先库后删"四个字。问"能否强一致"，答"不能，只能最终一致，需要锁或 binlog"。
| 维度 | RDB（快照） | AOF（日志） |
|---|---|---|
| 原理 | 定时把内存全量写成二进制快照 | 记录每条写命令 |
| 恢复速度 | 快 | 慢（要重放） |
| 数据完整性 | 差（两次快照间会丢） | 好（可配置 fsync） |
| 文件体积 | 小（压缩） | 大 |
| 对性能影响 | fork 时短暂卡顿 | 持续写盘开销 |
"RDB 快而全、AOF 细而慢"。生产上两个一起开，不是二选一。
第一次全量同步、之后增量同步，两阶段。
"先 RDB 全量、再命令增量、断线看 offset"。三个动作对应三个阶段。
| 维度 | 悲观锁 | 乐观锁 |
|---|---|---|
| 思想 | 假设一定冲突，先加锁再操作 | 假设很少冲突，提交时校验版本 |
| 实现 | 数据库行锁、分布式锁（Redis/ZK） | 版本号、CAS、时间戳 |
| 并发性能 | 差（串行化） | 好（无阻塞） |
| 失败处理 | 等待或超时 | 重试 |
| 适用 | 写多读少、冲突频繁 | 读多写少、冲突少 |
"悲观先锁、乐观后验"。高并发抢购用乐观锁 + 重试，或用 Redis 扣减。
消息队列解决异步、解耦、削峰三件事，代价是一致性、重复、顺序三件事。
| 收益 | 代价 / 风险 |
|---|---|
| 异步：不阻塞主流程 | 最终一致，不是强一致 |
| 解耦：生产消费互不感知 | 链路变长，排查困难 |
| 削峰：缓冲瞬时流量 | 消息堆积、积压延迟 |
"异步解耦削峰，换来重复和延迟"。问风险必答"重复消费、消息丢失、顺序错乱"。
| 层次 | 工作在哪 | 能做什么 | 代表 |
|---|---|---|---|
| 四层 | 传输层（TCP/UDP） | 按 IP+端口转发，快 | LVS、F5 |
| 七层 | 应用层（HTTP） | 按 URL/Header 路由，灵活 | Nginx、HAProxy |
"四层快、七层灵活"。要按内容路由就七层，要极致性能就四层。
四段式：定位 → 方案 → 实现 → 代价。有"代价"这一句，答案立刻显得专业。
这一块是案例里最"送分"的板块——考的都是必背小册里背过的概念，只是换成了填空和简答。
| 高频点 | 出现 | 问法 |
|---|---|---|
| 质量属性识别 | 14 次 | "依次写出每条需求对应的质量属性" |
| 效用树填空 | 9 次 | "把 (a)~(m) 填入效用树 (1)~(6)" |
| 架构风格选型 | 6 次 | "更适合哪种风格？说明理由" |
| 敏感点/权衡点 | 6 次 | "指出哪些是敏感点、哪些是权衡点" |
这一块的答案基本在必背小册第 1–10 条里，背熟就能拿分。
题干给一串需求，让你判断每条属于哪个质量属性。这是案例第一大送分题。
| 题干关键词 | 答案 |
|---|---|
| "1 分钟内完成" / "响应时间不超过" / "TPS 达到" | 性能 |
| "99.9%" / "故障切换不超过 N 分钟" / "7×24 小时" | 可用性 |
| "加密" / "权限控制" / "防止未授权访问" | 安全性 |
| "不停机升级" / "更换数据库不影响业务" / "模块可替换" | 可修改性 |
| "新手上手时间" / "操作步骤减少" | 易用性 |
| "与第三方系统对接" / "标准协议" | 互操作性 |
| "单点故障不影响" / "数据不丢失" | 可靠性 |
看动词：能算时间的是性能、能算占比的是可用性、涉及权限的是安全性、涉及"改/换"的是可修改性。
给一张效用树图，挖几个空让你填。填空位置通常在第 2 层（质量属性）或第 4 层（场景）。
"根效用、二属性、叶场景"。填空前先定位层号，再决定填什么。
给两个方案让你选，并说明理由。这是最好拿分的开放题——只要理由扣住质量属性就行。
| 题干信号 | 倾向选 |
|---|---|
| 数据要经过多道加工、每步可独立替换 | 管道-过滤器 |
| 多来源数据汇总、围绕中心数据操作 | 仓库 / 黑板 |
| 松耦合、异步、发布订阅 | 事件驱动 |
| 分层职责、上层依赖下层 | 分层 |
| 规则频繁变化、要动态执行 | 解释器 |
"先表态、再扣属性、后踩对方"。理由里必须出现质量属性词，否则不给分。
题干给一堆架构决策，让你分类。判据是影响几个属性、有没有坏结果。
| 类型 | 判据 | 题干信号 |
|---|---|---|
| 敏感点 | 影响一个质量属性 | "对 XX 有显著影响" |
| 权衡点 | 影响多个，且有好有坏 | "提高 A 但降低 B" |
| 风险点 | 可能导致不良后果 | "存在隐患""可能不可接受" |
| 非风险点 | 经分析确认没问题 | "已验证""满足要求" |
"一个=敏感、多个=权衡、可能坏=风险、已确认=非风险"。四句话对应四类。
ATAM 三件套：多属性、效用树、四类点。缺一个理由就不完整。
2025-11 起考 DDD。限界上下文是高频填空点。
"同一个词，在不同上下文里可以有不同含义"——这句话就是限界上下文的定义核心。
又称端口与适配器架构。用端口定义内外交互契约，用适配器隔离技术实现，业务核心不依赖框架。
| 组成 | 职责 | 举例 |
|---|---|---|
| 领域核心 | 业务规则（聚合、实体、值对象、领域服务） | 订单、库存规则 |
| 入站端口 | 定义外部调用核心的用例接口 | 创建订单、确认库存 |
| 出站端口 | 定义核心访问外部的抽象 | 订单仓储、支付网关、消息发布 |
| 适配器 | 把 HTTP/RPC/MQ/DB 转成端口调用 | Controller、Repository 实现 |
"核心在内、适配器在外、依赖由外向内"。三层九个字。
四步：属性 → 场景 → 找点 → 建议。这就是 ATAM 的简化版。
以下概念能默写，这一板块就能拿 15+ 分：
这七条全在必背小册第 1–10、21 条里。案例和选择题在这里是同一套知识，背一遍两处都能用。
这一块的主线是数据流图（DFD）（36 小问里 8 次）和E-R 建模，属于"画图 + 补图 + 找错"型题目。
| 子题型 | 典型问法 |
|---|---|
| DFD 补全 | "在图中补充缺失的数据流 / 加工 / 数据存储" |
| DFD 找错 | "指出图中语法错误并说明错误类型" |
| E-R 建模 | "设计超类实体""指出派生属性""给出主键" |
| 逻辑模型 | "逻辑数据模型设计包含哪些任务" |
这一类题答案高度依赖图，但"错误类型"和"设计任务"是固定知识，可以提前背。
数据流图只有四种元素：外部实体、加工、数据存储、数据流。
| 元素 | 画法 | 作用 |
|---|---|---|
| 外部实体 | 矩形 | 系统外的数据来源或去向 |
| 加工（处理） | 圆角矩形 / 圆 | 对数据做变换 |
| 数据存储 | 开口矩形 / 双横线 | 静态存储的数据 |
| 数据流 | 箭头 | 数据流动方向 |
"黑洞无出、奇迹无入、灰洞不够、父子不平"——四类错误一句话记完。
DFD 按层次细化：顶层图（0 层）→ 0 层图 → 1 层图……
"顶层一个圈，层层往下钻，父子要平衡"。
这两个概念是案例爱考的"名词解释 + 应用"组合。
| 概念 | 定义 | 应用要点 |
|---|---|---|
| 超类实体 | 把多个实体的公共属性抽出来形成的父实体 | 列出公共属性 + 说明子实体继承 |
| 派生属性 | 可由其他属性计算得出，不必单独存储 | 如"单价×数量=金额"中的金额 |
| 弱实体 | 不能独立存在，依赖强实体 | 如"订单明细"依赖"订单" |
"超类抽公共、派生靠计算、弱实体靠别人"。三个词一句话。
经典简答题："逻辑数据模型设计过程包含哪些任务？"
"找实体、定属性、连关系、再规范"四步，加上主外键更完整。
案例考过："如何把软件需求映射到软件架构？"从三个角度答。
| 角度 | 答什么 |
|---|---|
| 描述语言 | 用 ADL / UML 把需求转成架构描述 |
| 非功能需求 | 把质量属性转成质量属性场景，再落到架构决策 |
| 需求与架构的对应 | 建立需求-架构追踪矩阵，逐条验证 |
三角度：语言、场景、追踪。这是标准的三段式答案。
补图题的答案90% 能从题干原文里找到，先通读题干划名词，再往图上套。
这五条是这一板块的"通用弹药"，任何一年都能用上。
嵌入式是案例里最"套路化"的板块——考来考去就是实时性、可靠性、调度、冗余这几件事。
| 高频点 | 出现 | 问法 |
|---|---|---|
| 实时性保障 | 5 次 | "如何保证系统的实时性" |
| 可靠性设计 | 5 次 | "采取哪些可靠性措施" |
| 模块划分 | 5 次 | "系统应划分为哪些模块" |
| 冗余与容错 | — | "如何避免单点故障" |
| 看门狗 / 中断 | — | "看门狗的作用" |
这一块背模板就能拿分，因为问法高度重复。
问"如何保证实时性"，从这六个角度答，答到四个就够。
"RTOS + 优先级 + 短中断 + 预留 + 少阻塞 + 算 WCET"六招。答四条即可。
"冗余、容错、降级、注入、日志"五招。看门狗 = 定时喂狗，不喂就复位。
问"系统划分为哪些模块"，按硬件抽象 → 系统 → 应用三层答。
| 层 | 模块 |
|---|---|
| 硬件层 | 传感器、执行器、通信接口、电源管理 |
| 驱动 / 抽象层 | 设备驱动、BSP、HAL |
| 系统层 | RTOS、文件系统、通信协议栈、存储管理 |
| 应用层 | 业务逻辑、数据处理、人机界面 |
"硬件 → 驱动 → 系统 → 应用"四层。分层答题永远比罗列模块得分高。
| 类型 | 超时后果 | 例子 |
|---|---|---|
| 硬实时 | 灾难性，绝对不允许超时 | 刹车、飞控、心脏起搏器 |
| 软实时 | 体验下降，可接受偶尔超时 | 视频播放、界面刷新 |
| 固实时 | 偶尔超时可容忍，但超太多就失效 | 工业控制 |
"硬实时超时=事故，软实时超时=卡顿"。判断题看到"必须在 X ms 内完成"就是硬实时。
航空机载软件的安全等级标准，分 A~E 五级。
| 等级 | 失效影响 |
|---|---|
| A（灾难级） | 可能导致坠机，要求最严 |
| B（危险级） | 严重危害，机组难以处理 |
| C（较大级） | 增加机组负担 |
| D（较小级） | 轻微不便 |
| E（无影响） | 无安全影响 |
"A 最严、E 无影响"。A 级对应"灾难"，别记反。
嵌入式的两个高频机制。
"中断短、调度抢占、反转继承"三个短句。
四段：分层 → 实时 → 可靠 → 接口。嵌入式案例基本都能套。
这一块两条主线：缓存设计（12 次）和数据一致性（7 次），与 Web 板块有重叠但更偏数据库侧。
| 子题型 | 典型问法 |
|---|---|
| 缓存策略 | "如何设计缓存？用什么淘汰策略？" |
| 读写分离 / 分库分表 | "数据量增长后如何扩展？" |
| 分布式事务 | "如何保证跨库一致性？" |
| 范式与索引 | "判断范式""为什么建这个索引" |
这一块和必背小册模块九（数据库）是同一套知识，只是换成案例问法。
读写分离解决读多写少，代价是主从延迟导致读到旧数据。
"主写从读，写后读主"。被问"延迟怎么办"，答这八个字。
| 方式 | 拆什么 | 解决 |
|---|---|---|
| 垂直分库 | 按业务拆库 | 业务耦合、单库压力 |
| 垂直分表 | 按字段拆表（冷热分离） | 单表字段过多 |
| 水平分表 | 按行拆（取模/范围/哈希） | 单表数据量过大 |
"垂直拆业务、水平拆数据"。问代价必答"JOIN、事务、ID、分页"四样。
| 方案 | 一致性 | 特点 |
|---|---|---|
| 2PC / XA | 强一致 | 两阶段提交，阻塞、性能差 |
| TCC | 最终一致 | Try-Confirm-Cancel，业务侵入大 |
| Saga / 消息最终一致 | 最终一致 | 长事务、补偿，适合微服务 |
"要强一致用 2PC，要高可用用最终一致"。答题先问"能不能接受中间态"。
案例里常以"为什么慢 / 该怎么建索引"出现。
"最左前缀、前导模糊失效"。问"为什么索引没生效"，先答这两条。
| 策略 | 淘汰谁 |
|---|---|
| LRU | 最久未使用 |
| LFU | 使用次数最少 |
| FIFO | 最早进入 |
| TTL / 过期删除 | 到期即删（惰性 + 定期） |
| maxmemory-policy | Redis 可配 allkeys-lru / volatile-lru 等 |
"LRU 看时间、LFU 看次数"。Redis 默认 noeviction，要显式配淘汰策略。
案例常问"如何保证一致性"，先分清强一致 / 最终一致。
"强一致牺牲可用，最终一致牺牲实时"。答题先亮这个取舍。
问"数据库设计过程"，标准四步。
"需求 → 概念 → 逻辑 → 物理"四步，每步的产物要能对上（E-R 图在概念阶段）。
"先索引、再分离、后分片、补缓存"——这个顺序不能反，先上分库分表是过度设计。
案例题有些句式，写上去就能拿"表述分"。
五种句式对应五种问法。不会的题也别空着，用兜底句至少拿 1 分。
上午 08:30–12:30 两科连考共 240 分钟，综合知识最长 150 分钟、最短 120 分钟。核心策略是综合知识尽快交卷，把时间让给案例分析。
| 方案 | 综合知识 | 案例分析 | 适用 |
|---|---|---|---|
| 推荐 | 120 分钟（最短） | 120 分钟 | 综合知识有把握、案例需要时间 |
| 平衡 | 135 分钟 | 105 分钟 | 两科都不稳 |
| 保守 | 150 分钟（最长） | 90 分钟 | 综合知识必须反复检查 |
| 阶段 | 时间 | 做什么 |
|---|---|---|
| 选题 | 8 分钟 | 扫 5 道题的最后一问，定 3 道 |
| 答题 | 每题 34 分钟 × 3 | 按小问顺序，先易后难 |
| 检查 | 10 分钟 | 补漏、检查字数、确认没有空题 |
"综合知识 120 分钟必须交卷"。多花 10 分钟检查综合知识，可能换来案例少答半道题——20 分和 2 分，孰轻孰重很清楚。
这五条与知识无关，但**能实打实多拿 5–8 分**。
| 要背的 | 在哪本 |
|---|---|
| 质量属性、架构风格、评估方法 | 必背小册 1–10 条 |
| 数据库范式、E-R、连接运算 | 必背小册 55–61 条 |
| OS、网络、嵌入式基础 | 必背小册 71–94 条 |
| 答题套路与踩分点 | 本册 |
两册分工：必背小册管"知道"，本册管"答得出"。知识在必背册，套路在这里。
编制说明：本册依据 `quiz/quiz.db` 中 16 套案例真题（75 大题 / 214 小问）与官方解析编制， 重点覆盖占 91% 题量的五大板块（Web 应用设计 19、系统架构设计与评估 15、系统设计与建模 12、 嵌入式系统架构设计 12、数据库系统与缓存设计 10）。
与必背小册的分工：必背小册解决"概念是什么"（选择题 + 案例的概念题）， 本册解决"案例怎么答"（答题骨架 + 踩分点 + 雷区）。两册配合使用，不重复。
使用建议：先通读模块一（得分逻辑）与模块七（通用句式）； 再按你最弱的一类精读对应模块；考前只看每条的 ★ 记忆技巧 与 答题模板。