系统架构设计师常见高频考点总结之案例题

1. 仓库风格 vs 管道-过滤器风格

在软考系统架构设计师的案例分析中，将"数据仓储（以数据为中心）风格"与"管道-过滤器风格"放在"集成开发环境（IDE）"场景下进行对比，是非常经典的必考题型（在2012年和2016年的下午案例分析中均作为核心考点出现过）。

维度一：四大核心机制对比

（参考2016年案例题）不要背长句，直接建立左右对照的强映射关系。考试时看到左边的特征，直接填右边的词：

比较维度	管道-过滤器 (单向流水线)	数据仓储 (共享大白板)
交互方式	顺序 / 循环	星型交互（中心结点辐射）
数据结构	数据流	文件 / 模型 （核心考词：语法树）
控制结构	数据驱动	业务功能驱动
扩展方法	接口适配	模型适配

维度二：IDE 为什么必选"数据仓储"？

（专攻简答默写题）抛弃书本上的长篇大论，你只需要记住 IDE 的 "三大刚需"，然后套用"白板赢了流水线"的逻辑：

1. 刚需一：高频互动（交互方式）

• 大白话逻辑： 程序员写代码是一边写、一边查错、一边断点调试的，动作极度碎片化且来回反复。

• 答题得分点： 管道风格不支持反复交互；数据仓储很好地支持了"交互式"的数据处理。

2. 刚需二：随意插拔插件（扩展性）

• 大白话逻辑： IDE 里各种代码检查工具、格式化工具经常换，如果用流水线，抽掉一个环节整条线就断了。

• 答题得分点： 管道风格处理逻辑僵化；数据仓储以"数据格式"解耦了各个工具，灵活定义功能顺序，易于配置和替换。

3. 刚需三：格式极其复杂（数据管理）

• 大白话逻辑： IDE 里有纯文本脚本、有可视化的图、还有复杂的底层语法树。流水线只能跑单一格式。

• 答题得分点： 管道风格支持的格式有限；数据仓储的中心存储器能包容"多种复杂数据类型"，并强力支持"数据格式转换"。

2. 解释器架构 vs 面向对象架构

|--------------|--------------------|----------------------------------------------------------------------------------------------------|
| 对比维度 | 优劣结论 | 核心理由与话术 |
| 1. 灵活性与可修改性 | 解释器 > 面向对象(解释器更优) | 解释器架构：将业务规则定义为独立的脚本或配置文件。规则变更时，无需修改源码、无需重新编译部署，更新文件即可即时生效。 面向对象架构：业务逻辑固化在代码中，变更需要修改类代码并重新发布，维护成本高。 |
| 2. 个性化与自定义能力 | 解释器 > 面向对象(解释器更优) | 解释器架构：支持最终用户或业务人员通过编写简单规则（如"满100减20"）定义逻辑，轻松实现业务的"千人千面"。 面向对象架构：逻辑由开发人员编写，非技术人员无法介入，难以实现灵活的个性化定制。 |
| 3. 系统性能 | 解释器 < 面向对象(解释器较差) | 解释器架构：需要在运行时进行词法分析、语法分析和动态解释，存在额外的计算开销，执行速度较慢。 面向对象架构：代码是预编译好的（或直接执行机器码/字节码），执行效率更高。 |

"解释器"就是"外挂"： 外挂（解释器）改起来真快（灵活性高），玩家（业务人员）自己就能拽（个性化强），就是跑起来有点怪（性能差）。

"面向对象"是"原装"： 原装（面向对象）固化在代码里（灵活性差），改个口味要等你（个性化弱），好在速度杠杠的（性能好）。

3. 主程序-子程序vs管道-过滤器

"将两种架构风格放入表格中进行优劣（+/-）对比"是一种非常经典且极具实战指导意义的题型。以下是该对比表格的完整内容及详细的剖析：

1. 架构方案对比表

评价要素	共享数据的主程序-子程序	管道-过滤器
算法变更	- （差）	+ （优）
功能变更	- （差）	+ （优）
数据表示变更	- （差）	- （差）
性能	+ （优）	- （差）

2. 详细要素解析（考场答题依据）

在应对此类填表对比题时，您可以记住一个核心底层逻辑：

• 主程序-子程序 代表了 "紧耦合" ：好处是性能高（+） ，坏处是改起来特别麻烦，不管是改算法、改功能还是改数据格式都是（-）。
• 管道-过滤器 代表了 "松耦合、流程化" ：好处是改算法、拼装新功能特别灵活（+） ，坏处是性能有损耗（-） ，并且一旦改了数据格式，整个流水线都要跟着改，也是（-）。

4.分别解释可靠性中，可靠度和失效率其含义

• 可靠度： 系统在规定的条件下、规定的时间内不发生失效的概率。
• 失效率： 又称风险函数或条件失效强度，是指运行至此刻系统未出现失效的情况下，单位时间系统出现失效的概率。

5. 请说明系统可靠性的定义及包含的4个子特性，并简要指出提高系统可靠性一般采用哪些技术？

• 定义： 系统在规定的时间内及规定的环境条件下，完成规定功能的能力，就是系统无故障运行的概率。
• 4个子特性： 成熟性、容错性、易恢复性、可靠性的依从性。
• 提高可靠性的技术： 冗余技术、软件容错技术（如N版本程序设计、恢复块方法）、双机容错技术（双机热备或集群系统）

6. 说明软件的错误、缺陷、故障和失效的定义

• 软件错误： 是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。
• 软件缺陷： 是存在于软件(文档、数据、程序)之中的那些不希望或不可接受的偏差。
• 软件故障： 是指软件运行过程中出现的一种不希望或不可接受的内部状态。
• 软件失效： 是指软件运行时产生的一种不希望或不可接受的外部行为结果。

7. 解释动态冗余和 N 版本程序设计技术

• 动态冗余： 又称为主动冗余，它是通过故障检测、故障定位及故障恢复等手段达到容错的目的。其主要方式是多重模块待机储备，当系统检测到某工作模块出现错误时，就用一个备用的模块来替代它并重新运行。
• N版本程序设计： 是一种静态的故障屏蔽技术，其设计思想是用 N 个具有相同功能的程序同时执行一项计算，结果通过多数表决来选择。这 N 个版本的程序必须由不同的人独立设计，使用不同的方法、设计语言、开发环境和工具来实现。

8. 请说明什么是数据持久层，使用数据持久层能够为项目开发带来哪些好处？

• 概念： 数据持久层是根据分层思想，通过建立逻辑数据操作接口，采取一定的对象/关系映射策略，隐藏数据库访问代码细节，向业务开发人员提供透明的对象持久化操作机制。
• 带来的好处：
  1. 分离业务逻辑层和数据层，降低两者之间的耦合。
  2. 通过对象/关系映射向业务逻辑提供面向对象的数据访问。
  3. 简化开发工作，隐藏数据库链接、数据读写命令和事务管理细节，让开发人员更关注业务逻辑。
  4. 程序代码重用性/移植性强，更换数据库时只需更改配置文件。

9. 什么是 SQL 注入攻击，并列举出两种抵御 SQL 注入攻击的方式

• 概念： SQL 注入攻击是黑客对数据库进行攻击的常用手段之一。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据（利用未对用户输入进行非法字符转义处理的漏洞）。
• 抵御方式： （任选其二即可）1. 使用正则表达式检查； 2. 使用参数化的过滤性语句； 3. 检查用户输入的合法性； 4. 用户相关数据加密处理； 5. 存储过程来执行所有的查询。

10. Redis 缓存技术

1. 缓存架构：Cache-Aside (旁路缓存)

• 读策略：先读缓存 → 命中返回；未命中读DB → 写入缓存 → 返回。

• 写策略 ：先更新数据库 → 后删除缓存（不是更新缓存）。

• 并发一致性问题：多线程下可能出现脏数据。

• 解决：延时双删、分布式锁、设置过期时间。

2. 缓存过期策略

缓存中一般存储当前的热点数据，Redis 为每个 KEY 值都设置了过期时间，并默认采用"定期删除+惰性删除"的策略来清除非热点数据。 请简要描述该策略的"失效场景"，并给出至少三种"内存淘汰机制"来解决内存越来越高的问题。

"定期删除+惰性删除"的失效场景

如果"定期删除"没有扫描并删除到该过期的KEY，同时后续系统也没有及时去请求该KEY（也就是说"惰性删除"也没有被触发），这样Redis默认的过期删除策略就失效了，最终会导致Redis的内存使用率越来越高。

常见的内存淘汰机制（任写三种即可满分）

当过期策略失效、内存不足时，Redis 会启动内存淘汰机制。

1. 从已设置过期时间的数据集中，淘汰最近最少使用的数据 (对应 volatile-lru)。
2. 从已设置过期时间的数据集中，淘汰将要过期的数据 (对应 volatile-ttl)。
3. 从已设置过期时间的数据集中，任意选择数据淘汰 (对应 volatile-random)。
4. 从所有数据集中，淘汰最近最少使用的数据 (对应 allkeys-lru)。
5. 从所有数据集中，任意选择数据淘汰 (对应 allkeys-random)。

3. 数据类型应用

数据类型应用 ：String用于常规计数，List用于列表，Set用于去重和交集（如共同好友），Hash用于存储部分变更数据，Zset用于带权重的排行榜 。

4.持久化对比

维度	RDB (快照)	AOF (日志追加)
数据安全性	较低。由于是间隔备份，如果宕机，会丢失最后一次快照后的所有数据。	较高。可以配置为每秒同步（everysec）或每次写入同步（always），数据丢失通常在秒级。
重启恢复速度	快。RDB 文件是压缩后的二进制全量数据，恢复时直接加载到内存。	慢。需要逐条执行日志中的命令，数据量大时加载非常耗时。
文件体积	小。二进制压缩格式，存储紧凑。	大。记录了所有的操作指令，即使数据没变文件也会不断增长（虽有 AOF 重写机制）。
性能损耗	周期性高损耗。Fork 子进程进行磁盘 IO，在大数据集下 fork 可能会导致秒级的服务停顿。	持续性轻微损耗。写操作需要同步到磁盘，IO 压力分散在平时，但对吞吐量有一定影响。

5. 分布式存储和切片

数据量太大，单台存不下，怎么切分到多台机器上

1. Redis 分布式存储的 2 种常见方案：

• 主从方案（Master-Slave）（也可加上 Sentinel 哨兵模式）

• Cluster 集群方案

2. Redis 集群切片（Sharding）的常见方式：

• 客户端切片 ：在应用层（客户端）通过对 Key 进行 Hash 计算，直接将数据映射并路由到对应的不同 Redis 服务器上，它的典型代表是 ShardedJedis。

• 服务端/数据分片（Slot机制）：对数据根据 Key 散列到不同的 Hash槽（Slot）上，不同的 Slot 分配并对应到不同的 Redis 服务器节点上（如 Redis Cluster 的 16384 个槽位）

• 代理切片： 客户端不直接连接 Redis 节点，而是连接一个"中间件代理（Proxy）"。客户端把请求发送给代理，代理解析请求，计算 Key 的 Hash 值，然后路由到后端的某个具体的 Redis 节点。拿回数据后，代理再返回给客户端，如Twemproxy、Codis。

6. Redis vs MemCache

比维度	MemCache	Redis
数据类型	只支持简单的 Key/Value 结构	支持丰富的数据结构（String, List, Set, Hash, ZSet 等）
持久化	数据全在内存，掉电即丢（不支持持久化）	支持 RDB 和 AOF 持久化操作
线程模型	采用多线程机制	核心业务逻辑是单线程（这是高频考点）
分布式/集群	原生不支持集群（不支持分布式存储），通常靠客户端实现（如一致性哈希）	支持多种方式，如主从（Master-Slave）、哨兵（Sentinel）和原生 Cluster 集群

备考建议

用自己的话表达相同的意思是可以得分的，但前提是您的话里必须包含"核心关键字（采分点）"

软考案例分析的简答题通常采用"按关键字踩分 "的机制，在复习这类"送分题"时，不要去背诵整段完整的句子，而是去提炼并背诵其中的"核心词汇"。在考场上，再用自己的话把这些核心词汇串联成通顺的句子即可。这样既大幅降低了记忆负担，又能确保不漏掉任何得分点。