霍格沃茨图书馆 · 魔法架构典籍

🦉 猫头鹰提示：点击任意书籍的「🔍 翻找」或右下角「🔮 魔法探测」，会有魔法奇遇降临：可能是智慧问答、英文缩写解码（如 CAP / EVM / CMMI）、智者对话、咒语补全，或是一道知识口令。参与方式各不相同——有的要选答案、有的选回复、有的只需点一下。它们只是趣味彩蛋，不影响备考；出现概率可由管理员在后台调节。

📖 卷一 · 计算机基础 · 计算题全解与易错辨析

Cache 映射 / 流水线 / 存储编址 / 页面置换 / 磁盘调度 / 死锁

专题 1 · Cache 地址计算与三种映射方式

地址字段拆分（必考计算）

主存地址 = Tag（标记）| Index（行号/组号）| Offset（块内地址）
Offset = log₂(块大小) Index = log₂(Cache 行数) [直接映射/组相联为组数] Tag = 地址总位数 - Offset - Index

自测卷第 2 题：块 32B（Offset=5），64 行（Index=6），地址 32 位 → Tag = 32-5-6 = 21 位。这类题套公式即可，但要留意三种映射下 Index 的含义不同（全相联没有 Index 字段）。

映射方式	主存块可放入位置	Index 字段	冲突率	硬件成本	命中率
直接映射	唯一固定行（块号 mod 行数）	有（行数 log）	最高（抖动严重）	最低（1 个比较器）	最低
全相联	任意行	无（Tag 占满）	无冲突	最高（全部并行比较）	最高
组相联	指定组内任意行	有（组数 log）	中等	中等（组内并行比较）	较高

记忆口诀：直接映射"一对一"、全相联"随便放"、组相联"先分组再随便放"。n 路组相联 = 每组 n 行。计算时先判断映射方式，全相联的 Tag = 地址位数 - Offset。

变形考法

给你 Cache 总容量 + 块大小 + 映射方式，求 Cache 行数 → 行数 = 容量 ÷ 块大小
给你 Tag/Index/Offset 位数，反推 Cache 容量 → 容量 = 2^Index × 2^Offset（直接映射）
组相联：Cache 容量 ÷ (块大小 × 路数) = 组数，Index = log₂(组数)

专题 2 · 流水线时间计算与三类冒险

吞吐率 / 加速比 / 效率

总时间 = (k + n - 1) × Δt　　k=段数，n=指令数，Δt=时钟周期
吞吐率 TP = n ÷ 总时间　　实际吞吐率（n→∞）≈ 1/Δt
加速比 S = 串行时间 ÷ 流水时间 = (n·k·Δt) ÷ ((k+n-1)·Δt) = n·k/(k+n-1)
效率 E = 加速比 ÷ k（即流水线设备利用率）

自测卷第 1 题：5 段、每段 2ns、20 条指令 → (5+20-1)×2 = 48ns。注意区分"总时间"与"第一条指令完成时间"（k×Δt）。

三类冒险（Hazard）及解决

冒险类型	成因	典型场景	解决技术
结构冒险	硬件资源冲突（同时要用同一部件）	取指与访存同时用存储器	资源重复（指令/数据分离 Cache）、流水线停顿
数据冒险	后指令需要前指令尚未写回的结果	ADD R1,R2,R3 后紧跟 SUB R4,R1,R5	数据旁路/转发（Forwarding）、编译调度、插入气泡
控制冒险	分支指令改变 PC，取错后续指令	条件跳转指令	分支预测（静态/动态）、延迟槽、尽早计算转移地址

高频陷阱：题目问"解决数据相关最常用的技术"→ 选数据旁路/转发，不要选分支预测（那是解决控制相关的）。这是自测卷考点，也是每年真题的高频辨析点。

专题 3 · 存储编址与容量计算

自测卷第 3 题：按字编址、字长 32 位、地址 24 位 → 2²⁴ 个字 × 4B/字 = 2²⁶ B = 64MB。核心是分清按字节编址还是按字编址。

编址方式	地址数	每地址容量	总容量
按字节编址	2^地址位数	1 字节	2^地址位数字节
按字编址	2^地址位数	字长/8 字节	2^地址位数 × 字长/8 字节

单位换算：1KB=2¹⁰B，1MB=2²⁰B，1GB=2³⁰B。快速算法：2ⁿ 字节 → n÷10 得 KB 级、n÷20 得 MB 级。例：2²⁶B = 2⁶ × 2²⁰B = 64MB。

海明码校验位

2^r ≥ k + r + 1　　k=信息位，r=校验位

自测卷：信息位 8 位 → r=4 时 16 ≥ 8+4+1=13 成立，r=3 时 8 ≥ 12 不成立 → 至少 4 位。校验位放在 2⁰、2¹、2²、2³… 位置上（第 1、2、4、8 位）。

专题 4 · 页面置换与磁盘调度

四种置换算法对比

算法	淘汰对象	Belady 异常	实现开销	性能
OPT（最佳）	未来最久不使用	无	不可实现（理论上限）	最优
FIFO	最早进入的页	有	极低（队列）	差
LRU	最久未使用	无	较高（需记录时间/栈）	接近 OPT
Clock/NRU	访问位为 0 的页	无	低（近似 LRU）	较好

Belady 异常：只有 FIFO 会出现"物理块增加、缺页率反而上升"的反常现象。LRU 和 OPT 属于栈式算法，绝不会出现。这是选择题最爱考的一句话判断。

LRU 手算要点（自测卷第 7 题复盘）

关键：每次淘汰最久没有被访问过的页（看"上次访问时间"，不是"进入时间"）。命中也要更新时间戳，这是最容易漏的一步。12 次访问中只有第 8 次（访问 1）和第 9 次（访问 2）命中，其余 10 次缺页。

磁盘调度算法对比

算法	规则	是否到磁盘端点	特点
FCFS	按请求先后	—	公平但效率低
SSTF	选距当前最近的请求	—	效率高但可能"饥饿"
SCAN（电梯）	沿一个方向服务到底，到达最大请求处即反向	只需到最大请求柱面	无饥饿
C-SCAN	单向扫描，到端点直接返回起点重新扫	需走到磁盘端点	响应更均匀

自测卷第 28 题易错点：SCAN 只需服务到最大请求柱面（183）即可折返，不必走到 199 端点，所以是 130+169=299。若误算成走到 199，会得到 331。题目给这两个选项就是为了区分你是否掌握这个细节。

专题 5 · 死锁四条件与四种处理策略

四个必要条件（缺一不可，同时满足才可能死锁）

互斥：资源一次只能被一个进程占有
占有并等待：已持有资源的进程又申请新资源，且不释放已持有的
不可剥夺（不抢占）：资源不能被强行从进程手中夺走
循环等待：存在进程—资源的环形等待链

四种处理策略与破坏的条件

策略	做法	破坏的条件	代价
预防	资源一次性分配（运行前申请全部资源）	占有并等待	资源浪费严重
预防	有序资源分配法（给资源编号，按序申请）	循环等待	限制申请灵活性（最常用）
预防	可剥夺资源（申请不到则释放已持有）	不可剥夺	实现复杂
避免	银行家算法（动态检查是否处于安全状态）	不破坏条件，运行时判断	需预知最大需求
检测	资源分配图化简，发现死锁	—	需配合解除
解除	剥夺资源 / 撤销进程 / 进程回退	—	损失工作

答题要点：题目问"破坏循环等待条件"→ 答有序资源分配法（按序申请）。问"避免死锁"→ 答银行家算法。两者不要混：预防是破坏条件，避免是运行时检测安全状态。

📖 卷二 · 数据库 · 范式判定、事务并发与分布式数据

候选键求法 / 范式逐级判定 / 隔离级别 / 封锁协议 / CAP 与 BASE

专题 6 · 候选键求法与范式判定（标准化流程）

候选键求法三步走

把属性按在函数依赖 F 中的出现位置分为四类：L（只在左边）、R（只在右边）、LR（左右都出现）、N（两边都不出现）
规则：N 类和 L 类属性必在候选键中；R 类必不在；LR 类需尝试组合
从 L∪N 出发，求属性闭包，若闭包 = 全部属性 U，则它是候选键；否则逐个加入 LR 类属性再求闭包

自测卷：F={A→B, B→C, C→D, D→A}，四个属性都在左右两边出现（都是 LR 类）。由于 A→B→C→D→A 构成闭环，任取一个属性其闭包都等于 U，故 A、B、C、D 全是候选键。

范式逐级判定（递进关系，必须逐级满足）

范式	要求	消除的问题	判定口诀
1NF	属性不可再分（原子值）	重复组、多值字段	字段不能再拆
2NF	1NF + 非主属性完全依赖于候选键	部分函数依赖	不能只依赖主键的一部分
3NF	2NF + 非主属性不传递依赖于候选键	传递函数依赖	不能"拐弯"依赖
BCNF	3NF + 每个决定因素都含候选键	主属性对键的部分/传递依赖	箭头左边必须是候选键

自测卷第 10 题关键：R(A,B,C)，候选键 A，有 A→B、A→C、B→C。因为 B、C 都完全依赖候选键 A（不存在"只依赖 A 的一部分"，因为 A 是单属性），所以满足 2NF；但有 A→B→C 传递依赖，不满足 3NF。答案 = 2NF。很多人会误判成 1NF——注意单属性候选键天然无部分依赖！

判定口诀：先看有没有部分依赖（→ 决定能否到 2NF），再看有没有传递依赖（→ 决定能否到 3NF），最后看决定因素是不是候选键（→ 决定能否到 BCNF）。

专题 7 · 事务 ACID、隔离级别与三类读问题

ACID 四大特性

特性	含义	实现机制
原子性 A	要么全做要么全不做	Undo Log（回滚日志）
一致性 C	事务前后数据满足完整性约束	由 A、I、D 共同保证 + 应用层
隔离性 I	并发事务之间互不干扰	锁机制 + MVCC
持久性 D	提交后结果永久保存	Redo Log（重做日志）

三类读问题与隔离级别对照（必考）

隔离级别	脏读	不可重复读	幻读	实现
READ UNCOMMITTED	✗ 未解决	✗ 未解决	✗ 未解决	无锁，直接读
READ COMMITTED	✓ 解决	✗ 未解决	✗ 未解决	MVCC 每次快照
REPEATABLE READ	✓ 解决	✓ 解决	✗ 未解决	MVCC 事务级快照
SERIALIZABLE	✓ 解决	✓ 解决	✓ 解决	加表锁串行执行

三种读问题辨析：
脏读 = 读到了别人没提交的数据（对方可能回滚）
不可重复读 = 同一条记录两次读值不同（被别人 UPDATE 并提交了）
幻读 = 同一条件两次读行数不同（被别人 INSERT/DELETE 了，多了或少了"幻影行"）
口诀：脏读看提交与否，不可重复读看值变没变，幻读看行数变没变。

MySQL 特例：InnoDB 默认 RR（可重复读），通过 MVCC + next-key 间隙锁实际上已经避免了幻读。但考试按标准 SQL 理论答——RR 仍存在幻读可能。

封锁协议与两段锁

协议	内容	解决的问题
一级封锁协议	修改前加 X 锁，事务结束释放	丢失修改
二级封锁协议	一级 + 读前加 S 锁，读完即释放	丢失修改 + 脏读
三级封锁协议	一级 + 读前加 S 锁，事务结束释放	脏读 + 不可重复读
两段锁协议 2PL	增长阶段加锁、收缩阶段解锁	保证可串行化，但不防死锁

专题 8 · 分布式数据：CAP、BASE、2PC 与 NoSQL

CAP 定理

C一致性（所有节点同一时刻数据一致）、A可用性（每次请求都能得到响应）、P分区容错性（网络分区时系统仍能运行）。分布式系统必须保证 P（网络故障不可避免），故实际是在 C 与 A 之间二选一。

取舍	含义	典型系统	场景
CP	分区时拒绝请求以保证一致	ZooKeeper、etcd、HBase	金融、配置中心
AP	分区时继续服务但可能不一致	Cassandra、CouchDB、Eureka	社交、内容分发
CA	理论存在，分布式下无意义	传统单机 RDBMS	—

BASE 理论（对 CAP 中 AP 的延伸）

BA Basically Available 基本可用：允许损失部分可用性（响应变慢、功能降级）
S Soft State 软状态：允许数据存在中间状态（副本间短暂不一致）
E Eventually Consistent 最终一致性：不保证实时一致，但保证一段时间后达到一致

2PC 与 3PC

协议	阶段	优点	缺点
2PC	①Prepare（投票）②Commit/Abort（执行）	简单、强一致	同步阻塞、协调者单点故障、提交阶段掉电导致数据不一致
3PC	①CanCommit ②PreCommit ③DoCommit	引入超时机制，降低阻塞	仍可能不一致，少用

NoSQL 四大类型（必考配对）

类型	数据模型	代表产品	典型场景
键值 KV	Key-Value	Redis、Memcached	缓存、会话、计数器
文档型	JSON/BSON 文档	MongoDB、CouchDB	内容管理、用户画像
列族	列族存储	HBase、Cassandra	海量日志、时序数据
图数据库	节点 + 边	Neo4j、JanusGraph	社交网络、推荐、风控

📖 卷三 · 网络 · 子网划分速算、TCP 状态机与 HTTP

CIDR 快速计算 / 三次握手四次挥手 / 拥塞控制 / 状态码

专题 9 · 子网划分速算法（不用背二进制）

核心三要素速算

块大小（增量）= 256 - 掩码最后一个非 255 字节值或块大小 = 2^(8 - 子网位)
网络地址 = 该块内最小的地址（是块大小的整数倍）
广播地址 = 网络地址 + 块大小 - 1
可用主机数 = 2^主机位数 - 2（减网络地址和广播地址）

自测卷第 15 题：172.16.10.33/27 → 掩码 255.255.255.224，块大小 = 256-224 = 32。33 落在 32~63 块 → 网络地址 172.16.10.32，广播地址 172.16.10.63，可用主机 33~62 共 30 台。

常用前缀速查表（建议背下来）

前缀	掩码末字节	块大小	可用主机	前缀	掩码末字节	块大小	可用主机
/24	0	256	254	/28	240	16	14
/25	128	128	126	/29	248	8	6
/26	192	64	62	/30	252	4	2
/27	224	32	30	/32	255	1	主机路由

反向解题：要 N 个子网 → 借位数 r 满足 2^r ≥ N；每子网要 M 台主机 → 主机位 h 满足 2^h - 2 ≥ M。自测卷那道"5 个子网、每网 25 台"：借 3 位（8≥5）、留 5 位（30≥25），C 类 /24 借 3 位 = /27（255.255.255.224）。

专题 10 · TCP 三次握手、四次挥手与拥塞控制

三次握手（建立连接）

步骤	方向	报文标志	状态变化
第 1 次	客户端 → 服务端	SYN=1, seq=x	客户端 SYN-SENT
第 2 次	服务端 → 客户端	SYN=1, ACK=1, seq=y, ack=x+1	服务端 SYN-RCVD
第 3 次	客户端 → 服务端	ACK=1, ack=y+1	双方 ESTABLISHED

为什么必须三次？两次握手时，若客户端的失效连接请求延迟到达，服务端会误建连接并白白等待；三次握手让客户端有机会确认，避免历史重复连接造成资源浪费。

四次挥手（关闭连接）

FIN(客户端) → ACK(服务端) → [服务端传完剩余数据] → FIN(服务端) → ACK(客户端)。为什么四次？因为 TCP 是全双工，收到对方 FIN 只说明对方不再发数据，自己可能还有数据要发，所以 ACK 和 FIN 分开发。客户端发完最后的 ACK 后进入 TIME_WAIT（等 2MSL，约 1~4 分钟），确保最后 ACK 能送达且旧报文消散。

拥塞控制四阶段

阶段	cwnd 增长方式	触发条件
慢启动	每 RTT 翻倍（指数增长）	连接建立或超时重传后
拥塞避免	每 RTT +1（线性增长）	cwnd ≥ ssthresh
快重传	收到 3 个重复 ACK 立即重传，不等超时	收到 3 个重复 ACK
快恢复	ssthresh = cwnd/2，cwnd = ssthresh，进入拥塞避免	快重传之后

易错：超时重传 vs 快重传的处理不同。超时重传 → ssthresh=cwnd/2，cwnd 重置为 1，重新慢启动（惩罚重）。快重传/快恢复 → cwnd 降到 ssthresh，直接进拥塞避免（惩罚轻，因为收到重复 ACK 说明网络还能传）。

专题 11 · HTTP/HTTPS 与状态码速查

状态码分类（只需记这几类）

类别	含义	必记状态码
2xx	成功	200 OK、201 Created、204 No Content
3xx	重定向	301 永久重定向（浏览器缓存）、302 临时重定向、304 Not Modified（缓存命中）
4xx	客户端错误	400 请求语法错、401 未认证、403 禁止访问、404 资源不存在、405 方法不允许
5xx	服务端错误	500 服务器内部错误、502 网关错误（上游返回无效）、503 服务不可用、504 网关超时

301 vs 302 记忆：301 = 永久搬家（以后直接去新地址，浏览器会缓存）；302 = 临时出门（每次还得先问原地址）。502 vs 504：502 是网关收到了上游的无效响应；504 是网关等上游等到超时没回应。

HTTPS = HTTP + TLS，握手时两种加密的分工

握手阶段用非对称加密（RSA 或 ECDHE）安全协商出会话密钥 → 之后应用数据全部用对称加密（如 AES-GCM）传输。原因：非对称加密计算慢、不适合大量数据；对称加密快但需要安全分发密钥，两者结合取长补短。

常考细节：数字证书由 CA 签发，把"公钥"与"持有者身份"绑定，解决"我怎么知道这个公钥真的是对方的"这一信任问题。验证方用CA 的公钥验证证书签名。

📖 卷四 · 软件工程 · 开发模型、CMMI、测试与维护

模型选型对照 / 成熟度等级 / 覆盖准则 / 维护分类

专题 12 · 开发模型选型与 CMMI 等级

六大开发模型对比（题目给场景，你选模型）

模型	核心特征	适用场景	主要缺点
瀑布	线性、阶段评审、文档驱动	需求明确稳定、技术成熟	后期改需求代价大
V 模型	开发与测试阶段一一对应	强调验证确认、高可靠系统	同瀑布，灵活性差
原型	快速构建可视化原型确认需求	需求不明确	原型质量差易被误用
增量	分批交付可运行增量	需求可分段、需快速见成果	需良好架构设计
螺旋	每轮含风险分析的四象限循环	大型复杂高风险项目	需专业风险评估、成本高
敏捷	短迭代、拥抱变化、个体互动优先	需求变化快、小团队	文档轻、不适合大型团队

选型口诀：需求不明确 → 原型；需求易变 → 敏捷/迭代；大型高风险 → 螺旋（靠"风险分析"四字识别）；需求明确稳定 → 瀑布；高可靠需严格验证 → V 模型。

CMMI 五级（记住每一级的关键词）

级别	名称	关键词
1	初始级	无序、靠个人英雄、不可预测
2	已管理级	项目级可重复、有基本项目管理
3	已定义级	组织级标准过程、过程已文档化
4	量化管理级	量化管理、统计技术控制过程
5	优化级	持续改进、缺陷预防、技术创新

另一种考查形式是 CMM（软件能力成熟度），同为五级，名称一致。注意 CMMI 是"能力成熟度模型集成"，涵盖软件、系统工程、集成产品开发等多个领域。

专题 13 · 测试覆盖准则与软件维护分类

白盒测试覆盖强度排序（由弱到强，必背）

语句覆盖 < 判定覆盖 < 条件覆盖 < 判定/条件覆盖 < 条件组合覆盖 < 路径覆盖

覆盖准则	要求	说明
语句覆盖	每条语句至少执行一次	最弱，可能漏掉分支
判定覆盖	每个判定的真/假分支各执行一次	又称分支覆盖
条件覆盖	每个条件的真/假值各取一次	可能不满足判定覆盖
条件组合覆盖	各条件真假值的所有组合都出现	覆盖强，用例数增长快
路径覆盖	覆盖所有可能的执行路径	最强，含循环时不可行

黑盒测试方法

等价类划分、边界值分析（最常用，关注边界及边界附近值）、错误推测法、因果图、判定表、正交试验、场景法。

软件维护四分类（必考，记住占比）

类型	触发原因	举例	工作量占比
改正性	修复已发现的缺陷	修 Bug	约 20%
适应性	适应运行环境变化	适配新操作系统、新数据库版本	约 25%
完善性	增强功能或改进性能	业务规则变化、加新功能、优化性能	约 50%（最高）
预防性	为未来可维护性做准备	重构、更新文档	约 5%

自测卷第 20 题解析："用户业务规则变化"→ 属于完善性维护（功能/性能的增强改进），不是适应性。适应性特指技术环境（操作系统、硬件、数据库、法规）变化。这是最常见的混淆点。

📖 卷五 · 架构风格 · 五大风格对比与 SOA/微服务演进

风格特征与选型 / 4+1 视图 / 中间件与集成层次

专题 14 · 五大经典架构风格对比（案例题高频）

风格	构件/连接件	核心特征	典型应用	主要优点	主要缺点
管道-过滤器	过滤器 / 管道	数据流驱动，每步独立增量处理	编译器、UNIX shell、图像处理流水线	可重用、易组合、支持并发	不适合交互式、数据需统一格式
分层（层次）	层 / 层间协议	上层调用下层、逐级抽象	OSI 七层、三层架构	易维护、支持逐层抽象	性能损耗、层级难划分
数据仓库/黑板	知识源 / 黑板（共享数据）	中央数据驱动，知识源自主响应	语音识别、专家系统、信号处理	适合无确定性算法、易扩展知识源	难测试、控制流不清晰
C2 / 事件驱动	构件 / 事件	隐式调用、异步通知	GUI、消息队列、EDA	松耦合、易扩展	难追踪、无法控制执行顺序
解释器	解释器引擎 / 程序	解释执行伪代码、可动态修改	虚拟机、规则引擎、脚本语言	灵活、跨平台	性能低、复杂度高

案例题识别口诀：
出现"编译/词法语法分析/数据一步步加工" → 管道-过滤器
出现"语音识别/专家系统/无确定解/多个知识源协作/黑板" → 数据仓库（黑板）
出现"GUI/按钮点击/异步通知/松耦合" → 事件驱动（隐式调用）
出现"规则引擎/脚本/跨平台执行" → 解释器
出现"实时控制/闭环/反馈调节" → 闭环控制（过程控制）

4+1 视图模型（记住每个视图的"关注点 + 使用者"）

视图	关注点	使用者	常用 UML 图
逻辑视图	功能需求分解	最终用户	类图、对象图、状态图
开发视图	软件模块组织与管理	程序员、开发经理	组件图、包图
进程视图	并发性、性能、可扩展性	系统集成人员	活动图、顺序图、协作图
物理视图	硬件拓扑、部署与通信	系统工程师	部署图
场景视图（+1）	用例串联并验证前四个视图	所有利益相关者	用例图

专题 15 · 单体 → SOA → 微服务：演进与选型

维度	单体架构	SOA	微服务
服务粒度	整体一个应用	较粗（按业务子系统）	细粒度（单一职责）
通信方式	进程内函数调用	ESB 集中总线（SOAP/WS）	轻量级（REST/gRPC）
数据管理	共享单一数据库	常共享数据库	每服务独立数据库（数据自治）
部署	整体打包部署	模块化部署	独立部署、独立扩缩容
治理	集中	集中式治理（ESB 强管控）	去中心化治理
优点	简单、易开发测试部署	集成异构系统、服务复用	弹性好、技术异构、故障隔离
缺点	耦合高、难扩展、故障扩散	ESB 易成瓶颈和单点	分布式复杂度高、运维成本高

ESB 的定位（自测卷第 32 题）：ESB 是集成基础设施，负责消息路由、协议转换、数据格式转换、服务编排、监控。它不承载业务逻辑——一旦把业务逻辑写进 ESB，ESB 就会膨胀成新的单体，这是 SOA 实施中最常见的失败模式。

EAI 集成的四个层次（由低到高）

层次	集成对象	做法	耦合度
表示集成（界面）	用户界面	统一门户、界面拼装	黑盒，最低成本
数据集成	数据	ETL、数据仓库、数据同步	中
控制集成（功能/API）	应用逻辑	调用对方 API、RPC、消息队列	较高
业务流程集成	业务流程	BPM 跨系统流程编排	最高，最灵活

📖 卷六 · 设计模式 · 23 种速查与易混辨析

三类分组记忆 / 8 组易混模式对比 / 案例题答题结构

专题 16 · 23 种模式速查表（按意图一句话记忆）

创建型 5 种（解决"如何创建对象"）

模式	一句话意图	典型场景
工厂方法	子类决定创建哪种产品	日志工厂、数据库驱动
抽象工厂	创建一族相关产品	跨平台 UI 控件族
单例	保证全局唯一实例	线程池、配置管理器
建造者	分步骤构建复杂对象	SQL 构建、复杂配置对象
原型	通过克隆创建新对象	创建成本高的对象

结构型 7 种（解决"类或对象如何组合"）

模式	一句话意图	典型场景
适配器	转换接口使不兼容者能协作	旧接口适配新系统
桥接	抽象与实现独立变化	跨平台图形/多数据库驱动
组合	树形结构表示"部分-整体"	文件系统、菜单树
装饰器	动态叠加职责	Java I/O 流、中间件拦截
外观	为子系统提供统一入口	API 网关、SDK 封装
享元	共享细粒度对象省内存	字符池、连接池
代理	为对象提供代理以控制访问	RPC stub、延迟加载、权限控制

行为型 11 种（解决"对象间如何交互与职责分配"）

模式	一句话意图	典型场景
策略	封装可互换的算法族	支付方式、排序算法选择
观察者	一对多依赖，状态变化自动通知	事件监听、消息订阅、MVC
命令	把请求封装成对象	撤销/重做、任务队列、日志
状态	状态改变时行为随之改变	订单状态机、TCP 状态
职责链	请求沿链传递直到被处理	审批流、过滤器链
迭代器	顺序访问聚合元素而不暴露结构	集合遍历
中介者	用中介对象封装对象间交互	聊天室、GUI 控件协调
备忘录	捕获并恢复对象内部状态	存档、快照、事务回滚
模板方法	定义算法骨架，子类实现步骤	框架钩子、流程模板
访问者	在不改类的前提下增加新操作	报表生成、AST 遍历
解释器	定义文法并解释执行	表达式解析、规则引擎

分类记忆口诀：创建型"工厂建造单例原型"；结构型"适配桥接组合装饰，外观享元代理"；行为型"策略观察命令状态，职责迭代中介备忘，模板访问解释"。共 5 + 7 + 11 = 23。

专题 17 · 八组易混模式辨析（考试就考这几个）

易混组	关键区别	一句话判别
工厂方法 vs 抽象工厂	工厂方法产一个产品；抽象工厂产一族产品	题目有"一族/成套/风格一致"→ 抽象工厂
适配器 vs 桥接	适配器是事后补救（接口已不兼容）；桥接是事前设计（抽象与实现都未定）	旧系统对接 → 适配器；多维度扩展 → 桥接
装饰器 vs 代理	装饰器增强功能（可层层叠加）；代理控制访问（通常一层）	加功能 → 装饰器；加权限/延迟 → 代理
装饰器 vs 适配器	装饰器不改接口；适配器改变接口	接口变没变是分水岭
策略 vs 状态	策略由客户端主动选算法；状态由内部状态自动转换	算法间无关联 → 策略；状态间有转换规则 → 状态
策略 vs 命令	策略关注"怎么做"（算法）；命令关注"做什么"（请求封装）	要撤销/排队/日志 → 命令
观察者 vs 中介者	观察者是一对多广播；中介者是多对多收敛到一个中介	星型集中协调 → 中介者
外观 vs 中介者	外观是单向简化调用；中介者是双向协调同事对象	只对外提供简单入口 → 外观

观察者推/拉模式（自测卷第 40 题）：推模式=主题把变更数据作为参数直接推给观察者（简单但可能推多余数据）；拉模式=主题只发通知，观察者持有主题引用按需自取（灵活但增加耦合）。考场上看题目说"observer 是否能自主决定取哪些数据"来判断。

案例题设计模式答题结构（照着写就有分）

① 点明模式名（中文名 + 英文，如"观察者模式（Observer）"）
② 说明选择理由（结合场景：因为需求是"一个对象变化要通知多个对象"，符合观察者的一对多依赖特征）
③ 画出/描述类图角色（抽象主题、具体主题、抽象观察者、具体观察者各自职责与关系）
④ 说明带来的好处（解耦、符合开闭原则、易于扩展新观察者）

📖 卷七 · 质量属性与架构评估 · 战术速查与 ATAM

六大属性战术表 / 效用树 / 敏感点·权衡点·风险点

专题 18 · 六大质量属性与战术速查表

质量属性是非功能性需求。案例题常要求：给出某属性的场景描述（六要素）+ 对应战术。下面这张表是核心得分点，建议整体记忆。

质量属性	含义	核心战术（记住 3~4 个）
性能	系统响应能力（响应时间/吞吐量）	资源需求：减少计算、降低通信开销资源管理：引入缓存、引入并发、增加资源资源仲裁：调度策略（优先级/FIFO）
可用性	系统正常工作时间比例	故障检测：心跳、ping/echo、异常检测故障恢复：冗余备件、故障转移、回滚、状态再同步故障预防：进程监视器、事务、移除服务
可靠性	无故障持续运行能力	容错：N 版本程序设计、恢复块、冗余检错：校验和、心跳降级：功能降级、限流
安全性	抵抗未授权使用与攻击	抵抗攻击：认证、授权、加密、限制暴露检测攻击：IDS 入侵检测恢复：审计追踪、冗余恢复
可修改性	修改系统的难易程度	局部化修改：维持语义一致性、泛化模块防连锁反应：信息隐藏、限制暴露、使用中介延迟绑定：配置文件、运行时注册、多态
可测试性	验证系统正确性的难易	记录/回放、接口与实现分离、依赖注入、提供测试接口

战术归属速判：看到"缓存/并发/多加服务器" → 性能；看到"心跳/主备切换/故障转移/冗余" → 可用性；看到"认证/授权/加密/IDS" → 安全性；看到"接口抽象/信息隐藏/配置化" → 可修改性；看到"日志记录/回放/测试桩" → 可测试性。

可靠性量化指标

MTBF（平均无故障时间） = 总运行时间 ÷ 故障次数
MTTR（平均修复时间） = 总修复时间 ÷ 故障次数
可用度 A = MTBF ÷ (MTBF + MTTR)
可靠性 R(t) = e^(-λt)，λ = 1/MTBF（失效率）
串联系统可靠性 = R₁×R₂×…×Rₙ　　并联系统可靠性 = 1 - (1-R₁)(1-R₂)…

串并联易错：串联系统元件越多越不可靠（相乘变小）；并联（冗余）系统元件越多越可靠（1 减去全部失效概率）。并联冗余 = 提高可靠性的经典手段。

专题 19 · ATAM / SAAM 与敏感点·权衡点·风险点

三个概念一次分清（必考辨析）

概念	定义	举例
敏感点	影响某一个质量属性的架构决策	"缓存大小"影响性能
权衡点	同时影响多个质量属性（且此消彼长）的决策	"缓存大小"既影响性能又影响内存成本
风险点	可能带来负面后果的架构决策	"依赖单一第三方支付接口"
非风险点	经分析认为不会带来问题的决策	—

判别口诀：影响一个属性 = 敏感点；影响多个属性 = 权衡点；有负面后果 = 风险点。同一个决策可能既是权衡点又是风险点，看题目问的角度。

ATAM 评估的九个步骤

1 呈现 ATAM 方法 → 2 呈现商业动机 → 3 呈现架构 → 4 识别架构方法
→ 5 生成质量效用树 → 6 分析架构方法（找敏感点/权衡点/风险点）
→ 7 集体讨论并确定场景优先级 → 8 再次分析架构方法 → 9 呈现评估结果

质量效用树结构（案例题常要求画/描述）

层次为：质量属性 → 子属性（求精） → 具体场景，并为每个场景标注重要性（H/M/L）与实现难度（H/M/L）。例：

性能 → 响应时间 → "大促峰值 QPS 10 万时，页面响应 < 2 秒" → (重要性 H, 难度 M)
可用性 → 持续运行 → "7×24 不间断，故障恢复 < 30 秒" → (重要性 H, 难度 H)
可修改性 → 扩展性 → "2 周内接入新支付渠道" → (重要性 M, 难度 L)

ATAM vs SAAM

方法	关注范围	核心工具	特点
SAAM	最早的方法，主要关注可修改性	场景 + 体系结构描述	简单、易上手
ATAM	多个质量属性的权衡	质量效用树 + 敏感点/权衡点分析	在 SAAM 基础上发展，更系统

📖 卷八 · 信息安全与新技术 · 加密体系、云原生与大数据

三类加密算法 / 数字签名与信封 / 云三层 / 容器 / 大数据架构

专题 20 · 加密体系：对称、非对称、Hash 与数字签名

类型	密钥特点	速度	典型算法	主要用途
对称加密	加解密同一密钥	快	DES、3DES、AES、RC4、SM4	大量数据加密传输
非对称加密	公钥加密、私钥解密（成对）	慢（约慢千倍）	RSA、ECC、ElGamal、SM2	密钥交换、数字签名
Hash（摘要）	无密钥，不可逆	快	MD5、SHA-1/256、SM3	完整性校验、密码存储

MD5 与 SHA 属于 Hash（摘要算法），不是加密算法！它不可逆、无密钥，只能用于完整性校验，不能用来加密数据。这是选择题里最常见的陷阱选项。

数字签名 vs 数字信封（极易混淆，务必分清）

技术	解决的问题	发送方操作	接收方操作	用谁的密钥
数字签名	身份认证 + 不可抵赖 + 完整性	用自己的私钥加密消息摘要	用发送方公钥解密验证	私钥签、公钥验
数字信封	密钥安全分发（保密传输）	用接收方公钥加密会话密钥	用自己的私钥解出会话密钥	公钥封、私钥拆

口诀：签名用自己私钥（证明"是我发的"）；信封用对方公钥（保证"只有你能看"）。一个管"身份认证"，一个管"保密传输"，方向正好相反。

PKI 体系组成

CA（认证中心）：签发、管理、吊销数字证书的核心机构
RA（注册机构）：受理用户申请、审核身份，转交 CA 签发
证书库：存放和发布证书，供查询下载
CRL（证书吊销列表）/ OCSP：查询证书是否已被吊销

专题 21 · 云计算三层、容器化与 K8s 核心概念

IaaS / PaaS / SaaS 分工（记住"谁管什么"）

层次	提供内容	用户需管理	典型产品
IaaS 基础设施	虚拟机、存储、网络	OS、中间件、运行时、数据、应用	阿里云 ECS、AWS EC2
PaaS 平台	+ 操作系统、数据库、中间件、运行时	应用和数据	Heroku、阿里云 ACK、GAE
SaaS 软件	+ 完整应用	只用不管	钉钉、Office 365、Salesforce

判别口诀：给你"裸机/虚拟机" = IaaS；给你"能跑代码的平台（含数据库、运行时）" = PaaS；给你"能直接用的软件" = SaaS。越往上用户管得越少。

容器 vs 虚拟机

维度	容器（Docker）	虚拟机（VM）
隔离层次	共享宿主机内核，namespace + cgroup 隔离	Hypervisor 虚拟硬件，每实例独立 Guest OS
启动速度	秒级	分钟级
资源占用	小（MB 级镜像）	大（GB 级）
隔离性	较弱（共享内核）	强
适用场景	微服务、CI/CD、弹性伸缩	强隔离、多 OS 内核需求

Kubernetes 核心对象

对象	作用
Pod	最小调度单元，含 1~N 个共享网络的容器
Service	为一组 Pod 提供固定 ClusterIP + DNS 名并负载均衡（解决 Pod IP 易变问题）
Deployment	声明 Pod 副本数，支持滚动更新与回滚
ConfigMap / Secret	配置与敏感信息（Secret 为 base64 编码，非强加密）
HPA	根据 CPU/内存等指标自动扩缩副本数

专题 22 · 大数据架构、UML 关系与知识产权

Lambda vs Kappa 架构

架构	组成	优点	缺点
Lambda	批处理层（全量、高延迟、高精度）+ 速度层（增量、低延迟、近似）+ 服务层合并	兼顾准确性与实时性	需维护两套代码，运维复杂
Kappa	只有流处理层，历史数据通过重放消息日志来重算	架构简单、一套代码	对流引擎重放与状态能力要求高

UML 关系与符号（案例题画图必用）

关系	符号	语义	举例
泛化（继承）	实线 + 空心三角	is-a	学生 is-a 人
实现	虚线 + 空心三角	类实现接口	类 implements 接口
关联	实线箭头	结构上的引用关系	教师 - 课程
聚合	实线 + 空心菱形 ◇	整体-部分，部分可独立存在	球队 - 球员
组合	实线 + 实心菱形 ◆	整体-部分，同生共死	房子 - 房间
依赖	虚线箭头	临时使用关系	人 - 空气

聚合 vs 组合（自测卷第 24 题）：看"整体没了，部分还在不在"。空心菱形（聚合）= 部分能独立存活（球队解散，球员还在）；实心菱形（组合）= 部分随整体消亡（房子拆了，房间也没了）。

use case 的 include 与 extend

关系	方向	执行时机	举例
include（包含）	基用例 → 被包含用例	必须执行	"下单" <<include>> "身份验证"
extend（扩展）	扩展用例 → 基用例	条件满足才执行	"使用优惠券" <<extend>> "支付"

知识产权与标准化（送分题，必须拿）

考点	要点
软件著作权（自然人）	保护期 = 终生 + 死亡后 50 年（截止第 50 年 12 月 31 日）
软件著作权（法人）	保护期 = 首次发表后 50 年；开发完成起 50 年内未发表则不再保护
著作权归属	职务作品：一般著作权归作者，单位有优先使用权；主要利用单位物质技术条件的，作者仅享有署名权
标准分级	四级：国家标准 → 行业标准 → 地方标准 → 团体标准和企业标准
强制性/推荐性	强制性标准必须执行；推荐性标准（GB/T）自愿采用

霍格沃茨图书馆 · 八大知识书架 22 个专题 · 覆盖 66 道自测题的全部知识网

"Per aspera ad astra." — 循此苦旅，以达星辰。

📚 霍格沃茨图书馆