案例分析：题型拆解与答题模板

先说结论：案例分析是三科里最“看得见”能提分的一科。综合知识靠量，论文靠写，案例靠套路 + 关键词。阅卷老师没时间读你的散文，他手里有一张评分点清单，你的答案里“命中一个点”就得一份分。所以这篇我不讲大道理，只做三件事：把近几年真题拆成题型；每类给一个能背的答题框架；再用一道我自己改编的示例题示范“完整作答长什么样”。

声明两件事。第一，我整理的题型分布来自我实际打开读过的公开真题回忆与备考文章（文末有清单），不是官方统计，官方从不公布考点频次；第二，示例题是我照着题型自己编的，不是原题，也不复制任何机构的题干和答案文字，你把它当作“作答格式演示”即可。考试形式、时间、教材版本这些会变的东西，一律以中国计算机技术职业资格网（ruankao.org.cn）和当地考试院的最新公告为准。

一、先把考试形态搞清楚

我读到的多篇 2025–2026 年的公开资料（培训机构的报考指南、考生总结）口径基本一致：系统架构设计师目前是机考（计算机化考试），科目连考、分批次进行；综合知识 75 题（每题 1 分），案例分析共 5 道大题，第 1 题必答，其余 4 题任选 2 题，实际作答 3 题，每题 25 分，共 75 分；论文 4 选 1，120 分钟。每科满分 75，合格线 45，三科都过才算过，成绩不跨期保留。这些以培训机构和考生文章为准，我没法在官方页面上逐条核对，所以你报名前请自己再看一眼公告。

时间怎么分？综合和案例是上午连考 240 分钟，其中综合知识最短需答 120 分钟（据资料）、最长 150 分钟，案例分析官方标称 90 分钟。换句话说，如果你综合知识 100 分钟就做完并且检查过，剩下的时间可以让案例多喘口气。我的建议是：选择题 100 分钟内收工，给案例留 120–130 分钟，每题 35–40 分钟，中间不留“下一科再补”的幻想。

二、近几年真题都考了什么：一张分布图

我把能读到的几套真题回忆按题目主题归了类。注意，样本很小（只覆盖我确实读过的 2024 下半年、2025 上半年、2025 下半年，以及 2024 上半年的搜索摘要），不足以做频率统计，但“题型是固定的几大类，只是每年换个业务壳”这个规律很明显。

看完这张表你应该能感觉到，题目大致落在七类：

1. 架构风格与架构评估（质量属性、ATAM）：几乎每年都有，多为必答题。
2. 软件设计与建模（UML、DDD、Petri 网、设计模式）。
3. 数据库与数据架构（分库分表、读写分离、NoSQL 选型、事务）。
4. 可靠性与安全（故障树、冗余、容错、认证授权、加密）。
5. 分布式与缓存（Redis、一致性、分布式锁、限流降级）。
6. 大数据与新技术（知识图谱、Lambda/Kappa、AI 平台、区块链、边缘计算）。
7. 嵌入式与实时系统（RTOS、ROS、构件化、可靠性）。

下面这张图把“七类题 + 选题决策”画成一张脑图，考前默画一遍你就知道自己哪一块是空白。

三、通用答题套路：先学“说话方式”

案例题的通病是答非所问：题目问“为什么”，你写“是什么”。评分老师对着标准答案划勾，所以我把作答规则浓缩成五条：

1. 先看问，再看材料。先扫问题，知道自己要在材料里找什么（术语、指标、组件名），再读题干。这样读一遍材料就够。
2. 问什么答什么，答案分点编号。“(1)…(2)…(3)…”。每点一句话，先给结论再补半句理由。
3. 用教材原词。“可用性”不要写成“不容易挂”，“单点故障”别写成“一个机器坏了”。评分点是关键词。
4. 宁多勿漏，但别偏题。问“列举 3 点”就给 4 点，最后一点错了也不倒扣（通常不倒扣，但以实际阅卷为准）；问“说明理由”就要有因果。
5. 结合题干场景。拿到分数的点往往是“教材概念 + 题干里的名词”的组合，比如“订单服务读多写少，因此适合加读缓存”。

再给一个通用的“小题型”对照，遇到就套：

四、类型 1：架构风格与质量属性评估

1. 常见问法

给一段系统描述，让你“指出每个场景对应的质量属性”“写出质量属性效用树”“找敏感点、权衡点、风险点”“说明该系统适合哪种架构风格并给出理由”。这一类在我读到的资料里几乎次次出现，甚至有考生总结“第一道架构风格题较易得分”，需要说明这是考生个人说法。

2. 答题框架

先把六个质量属性场景要素背下来：刺激源、刺激、环境、制品、响应、响应度量。然后是常考的质量属性清单，我分成“运行时”和“开发时”：

ATAM 的流程建议记住九步：介绍 ATAM、介绍业务驱动、介绍架构、识别架构方法、生成质量属性效用树、分析架构方法、集体讨论并排序场景、再次分析、汇报结果。敏感点：某个组件或参数的微小变化会显著影响某质量属性；权衡点：同一个决策同时影响多个质量属性且方向相反；风险点：可能导致问题的决策；非风险点：确认没问题的决策。

3. 完整作答示例（改编）

示例题 A（自编）：某在线票务系统在开票瞬间并发暴涨。需求包括：①开票期间 1 万并发请求下，下单接口 95% 请求在 2 秒内返回；②支付服务宕机时，用户仍能浏览与选座；③新增一种会员折扣规则应在 2 人日内完成上线；④运维需要在 5 分钟内定位到出错服务。请（1）指出四条需求分别对应的质量属性；（2）针对每条各给出一种架构策略；（3）指出其中的一个权衡点。

参考作答：

（1）① 性能；② 可用性（也可写“容错性”）；③ 可修改性；④ 可测试性 / 可运维性（可观测性）。

（2）① 性能：热点数据（座位图、场次信息）放入分布式缓存；下单请求经消息队列削峰；接口限流，防止过载。② 可用性：对支付服务做熔断和降级，浏览、选座链路与支付解耦，支付失败给出“稍后支付”兜底；核心服务多副本部署。③ 可修改性：把折扣规则抽象为可配置的策略（策略模式 + 规则引擎），新增规则只增加实现类或配置，不改主流程。④ 可测试性：接入统一日志与链路追踪，服务间传递 trace id，配套监控告警，快速定位故障服务。

（3）权衡点示例：引入异步消息队列削峰可以提升性能与可用性，但订单状态变为“最终一致”，一致性和实时性下降，同时增加系统复杂度，可能影响可测试性。这就是一个权衡点，需要在架构评估里记录并制定补偿措施（订单状态查询、超时回滚）。

这份作答的得分逻辑：每小问都有“属性名 + 策略 + 与场景的联系”，字数不多但命中了教材词。如果你把它写成“系统要很快、要很稳、要很灵活”，一分都拿不到。

五、类型 2：软件设计与建模（UML、DDD、设计模式、Petri 网）

1. 常见问法

画/补全用例图、类图、活动图、顺序图、状态图；识别 DDD 里的限界上下文、聚合、实体、值对象；用 Petri 网描述并发流程；判断设计模式类型。2025 年下半年的回忆里就同时出现了 Petri 网和限界上下文，说明“建模”这一块有向 DDD 和形式化方法扩展的趋势。

2. 答题框架

• UML 图关系口诀：关联（实线）、聚合（空心菱形，整体部分可分离）、组合（实心菱形，生命周期一致）、泛化（空心三角实线）、实现（空心三角虚线）、依赖（虚线箭头）。
• 用例图：参与者写“人/外部系统”，用例写“动宾短语”；include 是必须调用，extend 是条件扩展。
• DDD 词汇：限界上下文是模型的边界，同一个词在不同上下文含义可以不同；聚合是一致性边界，聚合根是外部访问的唯一入口；实体有唯一标识，值对象靠属性相等；领域事件用于上下文之间解耦。
• Petri 网：库所（圆，表示状态/条件）、变迁（方框，表示事件/动作）、托肯（token，表示资源）、弧。变迁使能的条件是输入库所都有足够托肯，触发后消耗输入并在输出库所产生托肯。价值：能形式化描述并发、同步、互斥，并可用于死锁、有界性分析。
• 设计模式：创建型（工厂、抽象工厂、单例、建造者、原型）、结构型（适配器、桥接、组合、装饰、外观、享元、代理）、行为型（策略、观察者、状态、命令、责任链、模板方法、迭代器、中介者、访问者、备忘录、解释器）。

3. 完整作答示例（改编）

示例题 B（自编）：电商平台的“订单”“库存”“物流”三个团队各自用“商品”一词，但订单团队关心价格与数量，库存团队关心仓位与批次，物流团队关心体积与重量。（1）这在 DDD 中体现了什么概念？（2）如何划分并集成三者？（3）“订单”聚合内部有订单头、订单行、收货地址，请说明聚合根与一致性规则。

参考作答：

（1）体现的是限界上下文：同一术语在不同上下文中有不同语义与模型，统一语言只在上下文内部有效，不强求全局一个“商品”模型。

（2）划分为订单、库存、物流三个限界上下文，各自维护自己的“商品”视图（订单里是下单商品快照，库存里是库存单元 SKU，物流里是包裹内物品）。集成方式：上下文之间通过领域事件（如“订单已支付”“库存已锁定”）异步通信；必要时使用防腐层（Anti-Corruption Layer）做模型翻译，避免下游被上游模型污染；上下文映射关系可采用客户-供应商或开放主机服务，视团队关系而定。

（3）聚合根是订单（订单头）；订单行和收货地址通过聚合根访问和修改，外部不能直接持有订单行的引用；聚合内保证事务一致性（如订单总额 = 各订单行金额之和，行数变化时同步刷新），聚合之间只保证最终一致。聚合应尽量小，避免大事务与并发冲突。

六、类型 3：数据库与数据架构

1. 常见问法

读写分离、分库分表的方案选型；SQL 与 NoSQL 的选择；索引与慢查询优化；事务 ACID 与 CAP/BASE；分布式事务；ER 图与范式。2024 上半年据检索摘要出现过分布式锁相关的数据库问题，2025 上半年则是 Redis 的持久化，可见“数据”一词在案例里已经不限于关系库。

2. 答题框架

我给这类题准备的是“四层递进法”：SQL 与索引 → 缓存 → 读写分离 → 分库分表，从成本最低的手段开始，逐层升级，永远不要一上来就写“分库分表”。

• 索引：最左前缀、覆盖索引、避免在索引列上做函数运算、区分度低的列不建索引；缺点是写入变慢、占空间。
• 读写分离：主库写，从库读；问题是主从延迟，导致读到旧数据，措施是关键读走主库、延迟感知路由。
• 分库分表：垂直拆分（按业务）、水平拆分（按分片键，如哈希、范围）；带来跨库 join、分布式事务、全局 ID、扩容迁移的问题。
• NoSQL 分类：键值（Redis）、文档（MongoDB）、列族（HBase、Cassandra）、图（Neo4j）。选择关键词：数据模型、一致性要求、读写比、扩展方式。
• CAP：分区容错不可避免，所以在 C 与 A 之间取舍；BASE 是基本可用、软状态、最终一致。
• 分布式事务：2PC/3PC、TCC、本地消息表（可靠消息最终一致）、Saga。写题时给出“适用场景”和“代价”。

3. 完整作答示例（改编）

示例题 C（自编）：某内容社区的“帖子”表已达 8 亿行，查询延迟高，高峰期主库 CPU 打满；业务以“按用户查看帖子列表”和“按帖子 ID 查详情”为主，写入量中等。（1）给出分层优化方案；（2）若选择水平分表，分片键怎么选？带来哪些问题？（3）主从延迟导致“刚发的帖子刷新看不到”，怎么办？

参考作答：

（1）自下而上：① SQL 与索引层，给“用户 ID + 创建时间”建联合索引，列表查询用覆盖索引，禁用 select *；深分页改为基于游标（上一页最后一条的时间/ID）。② 缓存层，热帖详情与用户最新列表放 Redis，设置过期时间，防止缓存穿透（布隆过滤器/空值缓存）、击穿（互斥锁/逻辑过期）、雪崩（过期时间加随机值）。③ 读写分离，读走从库，写走主库。④ 数据量仍然增长时，水平分库分表；冷热分离，历史帖子归档。

（2）分片键选“用户 ID”（多数查询是按用户看列表，能落在单分片）；帖子 ID 采用雪花算法，并把用户 ID 的分片基因编码进帖子 ID，使按帖子 ID 查详情也能定位分片。问题：跨分片查询（如全站热榜）需要额外的聚合或独立的搜索/排行服务；跨库事务；扩容时数据迁移与再平衡；全局唯一 ID 生成。

（3）措施：发帖后的短时间内，作者本人的读取强制走主库（或读写会话粘性，记录写入时间戳，窗口期内读主库）；也可以写成功后由应用直接把新帖写入缓存；同时监控主从延迟，延迟超过阈值时自动切读主库或摘除该从库。

七、类型 4：可靠性与安全

1. 常见问法

串并联系统可靠度计算；冗余、容错、故障树；认证授权模型；加密与签名；常见攻击（SQL 注入、XSS、CSRF）与防护；安全架构（纵深防御、零信任）。2024 下半年出现的“故障树分析”与“形式化验证 vs 测试”属于安全关键系统的方法论，回答要点在于概念区分而不是公式计算。

2. 答题框架

• 可靠度计算：串联 R = R1×R2×…；并联 R = 1-(1-R1)(1-R2)…；多数表决系统 (TMR) 用组合概率。公式可背可推。
• 可靠性设计手段：冗余（硬件、软件、信息、时间）；容错（错误检测→错误恢复→错误屏蔽）；故障隔离；降级。软件冗余中，恢复块与 N 版本程序设计要分清：恢复块是顺序执行并做验收测试，N 版本是并行执行并表决。
• 故障树分析（FTA）：自顶向下，从顶事件出发，用与门、或门分解为基本事件，找最小割集，用于识别单点故障与薄弱环节。相比之下，FMEA 是自底向上分析每个部件的失效模式与影响。
• 形式化验证 vs 测试：测试只能证明“有错”，不能证明“无错”，覆盖有限；形式化方法用数学模型证明性质成立，可提供更强保证，但成本高、依赖建模正确、状态爆炸。安全关键系统常二者结合。
• 安全三要素：机密性、完整性、可用性；再加上不可否认性、可审计性。加密：对称（AES，快、密钥分发难）与非对称（RSA/ECC，慢、便于分发）；混合使用：非对称交换会话密钥，对称加密数据；数字签名用于完整性与不可否认。
• Web 攻击：SQL 注入用参数化查询；XSS 输出转义与 CSP；CSRF 用 token 与 SameSite；越权用后端鉴权、最小权限。

3. 完整作答示例（改编）

示例题 D（自编）：某医院预约平台由“网关、预约服务、号源服务”串联组成，可靠度分别为 0.99、0.98、0.97。（1）计算整体可靠度；（2）将号源服务改为两个相同实例并联，可靠度如何变化；（3）列举三条提升可用性的架构措施；（4）该平台需要在患者隐私上做防护，列出三点。

参考作答：

（1）串联：0.99 × 0.98 × 0.97 ≈ 0.941。（2）号源服务并联后：1-(1-0.97)² = 1-0.0009 = 0.9991；整体 0.99 × 0.98 × 0.9991 ≈ 0.969。（3）网关与预约服务也做多实例 + 负载均衡；对号源服务调用设置超时、熔断、降级（如展示缓存号源）；数据库主从 + 自动故障转移；关键链路做多可用区部署。（4）敏感字段（身份证、病历）加密存储和加密传输；按角色与最小权限控制访问，并记录审计日志；对展示数据脱敏（手机号中间四位打码）。

注意：并联计算里“相同实例”默认相互独立，现实里共享数据库会让它们不独立，答题时可以补一句“并联假设各实例故障相互独立”，是加分的严谨。

八、类型 5：分布式与缓存

1. 常见问法

缓存读写策略（Cache-Aside、Read/Write-Through、Write-Behind）；缓存穿透击穿雪崩；缓存与数据库一致性；Redis 持久化（RDB、AOF）与主从复制、哨兵、集群；分布式锁；限流、熔断、降级；消息队列的可靠性与幂等。这是近三年出现频次很高的一类，2024 下半年考 Cache-Aside，2025 上半年考 Redis 复制与持久化，2026 年据一篇检索摘要，考试中还有电商缓存方案，这一条我未能核实原文，仅供参考。

2. 答题框架

3. 完整作答示例（改编）

示例题 E（自编）：某商城使用 Cache-Aside 缓存商品库存展示。运营反馈：修改库存后，偶尔页面仍显示旧值很长时间。（1）分析出现该问题的一种并发场景；（2）给出三种改进措施；（3）Redis 宕机重启后缓存为空，可能带来什么风险，如何预防？

参考作答：

（1）场景：读请求 A 未命中缓存，从数据库读到旧值 v1；此时写请求 B 更新数据库为 v2 并删除缓存；随后 A 把 v1 写回缓存。缓存里留下的是旧值，直到过期。（2）措施：① 缓存设置合理过期时间兜底；② 延迟双删：更新数据库后删缓存，延迟几百毫秒再删一次，覆盖 A 的回填；③ 通过订阅数据库 binlog（如 Canal）异步删除或更新缓存，保证删除操作最终发生，并且失败可重试；④ 对强一致场景，读写走同一分片并串行化，或直接读库。（3）风险：缓存冷启动，大量请求落到数据库，形成“缓存雪崩”。预防：Redis 使用主从 + 哨兵/集群，避免单点；开启 RDB/AOF 持久化以便重启恢复；启动前预热热点数据；网关限流与数据库前的熔断降级。

九、类型 6：大数据与新技术

1. 常见问法

Lambda/Kappa 架构；批处理与流处理；数据仓库/数据湖/湖仓一体；知识图谱；机器学习平台架构；云端 AI 与边缘 AI；区块链原理；云原生（容器、K8s、服务网格）；Serverless。2025 上半年一次出现了知识图谱、边缘 AI、区块链三个新技术型题目，说明这一块的“素材”越来越杂，好在评分点仍是概念性的。

2. 答题框架

• Lambda：批处理层（全量、准确、高延迟）、速度层（增量、低延迟、近似）、服务层（合并视图查询）。缺点：两套代码，维护成本高；Kappa 只保留流处理，用重放日志实现重算。
• 数据仓库 vs 数据湖：仓库结构化、写入前建模（schema-on-write）；湖存原始数据、读取时定义结构（schema-on-read）。湖仓一体试图兼得。
• 知识图谱构建：数据获取（爬虫、抽取）→ 知识抽取（实体、关系、属性）→ 知识融合（实体对齐、消歧）→ 知识存储（图数据库）→ 知识应用（问答、推荐）。分层通常为数据层与模式层。
• 边缘 AI vs 云端 AI：边缘的优势是低延迟、节省带宽、隐私更好、可离线；劣势是算力和存储受限、模型需要压缩（量化、剪枝、蒸馏）、运维分散。云端反之：算力强、易迭代、集中管理，但延迟受网络影响，数据上传有隐私风险。常见混合：云边协同。
• 区块链：分布式账本、哈希链、共识机制（PoW、PoS、PBFT）、非对称加密与数字签名、智能合约；特点：去中心化、不可篡改、可追溯；代价：性能低、存储膨胀、隐私与合规问题。
• 爬虫与异步 IO：异步 IO 通过事件循环在等待 IO 时切换任务，用少量线程处理大量并发连接，适合 IO 密集场景；Scrapy 基于 Twisted 事件驱动。

3. 完整作答示例（改编）

示例题 F（自编）：某连锁零售企业要建设实时经营看板，同时要保证月度报表的精确。团队考虑采用 Lambda 架构。（1）说明三层的职责；（2）说明看板与月报分别对应哪一层；（3）指出该架构的主要问题及替代方案；（4）门店摄像头做客流识别，请比较模型放在云端与门店边缘的利弊。

参考作答：

（1）批处理层：对全量历史数据周期性计算，结果精确，延迟高，产出批视图；速度层：只处理最新增量数据，延迟低，产出实时视图，通常是近似或短期结果；服务层：对批视图与实时视图进行合并，对外提供统一查询。（2）实时看板由速度层（加服务层合并）支撑；月度精确报表由批处理层产出。（3）问题：同一业务逻辑需要在批与流两套引擎中实现和维护，容易不一致；运维复杂。替代：Kappa 架构，只用流处理引擎，需要重算时从日志（如 Kafka）重放；或采用支持流批一体的引擎与湖仓一体存储。（4）云端：算力充足，模型更新方便，便于集中管理；但视频上传占带宽，延迟高，且涉及顾客隐私合规。边缘：本地推理延迟低、带宽省、原始视频不出店，隐私更好，断网也能工作；但设备算力有限，需要模型压缩，设备多，升级运维成本高。建议云边协同：边缘做推理与脱敏，只上传结构化结果，云端负责训练与模型下发。

十、类型 7：嵌入式与实时系统

1. 常见问法

嵌入式系统特点；实时操作系统（RTOS）的任务调度；中断与任务优先级；构件化、分层架构；ROS 的通信机制；软硬件协同；可靠性与低功耗。2024 下半年 ROS（机器人操作系统）的版本演进出现过，2025 下半年出现嵌入式系统设计，说明嵌入式作为选做题长期存在。这一类如果你没做过嵌入式，可以放弃，但记住“框架题”也不难拿基础分。

2. 答题框架

• 嵌入式特点：专用性强、资源受限（CPU、内存、功耗）、实时性、可靠性要求高、软硬件紧耦合、生命周期长。
• 实时系统：硬实时（错过截止时间即失败，如安全气囊）、软实时（偶尔延迟可接受，如视频播放）。调度算法：速率单调（RMS，周期短优先级高）、最早截止时间优先（EDF）。优先级反转：低优先级任务持有高优先级任务需要的资源，可用优先级继承、优先级天花板缓解。
• 分层架构：硬件层、驱动层（BSP）、操作系统层、中间件层、应用层，好处是可移植与可维护。
• ROS 的变化（考生回忆里出现，我按公开常识概括）：ROS 1 依赖中心化的 master 节点，单点故障；ROS 2 基于 DDS 的去中心化发现和通信，支持 QoS 策略、实时性更好、多平台支持更广（含嵌入式和 Windows）、安全性增强。

3. 完整作答示例（改编）

示例题 G（自编）：某工业控制器需要在 10 ms 周期内完成传感采集，同时响应低频的上位机配置。（1）该系统属于哪类实时系统；（2）为什么要设计任务优先级；（3）出现“优先级反转”怎么办；（4）给出四层软件架构。

参考作答：

（1）硬实时系统：控制周期内未完成采集会影响生产安全与精度。（2）采集任务有严格截止时间，应赋予高优先级，通过抢占式调度保证及时执行；配置通信任务为低优先级，不影响控制环路。（3）优先级继承：持有资源的低优先级任务临时继承等待者的高优先级；或使用优先级天花板协议；尽量缩短临界区，避免在临界区内做阻塞调用。（4）硬件层 → 驱动/BSP 层 → 实时操作系统层 → 应用层（采集任务、控制任务、通信任务）。

十一、5 选 3：选题策略与时间表

先确认一件事：第 1 题必答，后 4 题你只要选 2 题，也就是你只需要提前把 7 类里的 4 类练熟，不是全部。我的推荐组合：

1. 必答：质量属性 / 架构评估 / 架构风格。这块必须扎实，因为躲不掉。
2. 第一梯队选做：数据库与缓存（含 Redis、分布式），你有后端经验的话，这类题“说人话”就能得分。
3. 第二梯队：软件设计与建模（UML/DDD），只要背图例，答案很规整。
4. 备胎：大数据/新技术与嵌入式，只在你确实熟悉时选。

有考生分享说，自己曾在大数据题上失分（一位考生 2023 年底考试案例分析得 36 分，主要栽在没系统复习的大数据主题，第二次备考后通过，这是他自己文章里的说法），另一位在第二次备考时觉得除了爬虫框架 Scrapy 的题以外都算送分题。结论：不要指望押中，要保证任何一类都能拿基础分。

如果你综合知识提前交完，把富余时间加到必答题和难题上，不要在早交卷上“凑数”。机考有个好处：改起来方便，但也有坏处：屏幕小、看不见整题。建议把评分点先打在草稿纸（如果允许，以考场规定为准）上，再输入。

十二、把每一类都做成“最小可用答案卡”

我自己复习的时候，做了一种“答案卡”：每类题一张，正面写框架，背面写三条易错点。你也可以照做：

下面再补一道“混合题”示范，因为真题往往一个场景里同时问三个类型的问题：

示例题 H（自编）：某网约车公司要重构派单系统，现有单体应用，高峰期派单接口超时，部署频繁互相影响。（1）为什么考虑微服务，需要付出什么代价；（2）设计一条派单链路的缓存与消息方案；（3）如何保证服务的可用性。

参考作答：（1）原因：单体各模块共享进程与数据库，部署耦合、故障扩散、扩展粒度粗；微服务可独立部署与伸缩、技术栈自由、团队自治。代价：分布式复杂性（网络延迟、部分失败）、数据一致性困难、运维与监控复杂、服务治理成本，需要配套 CI/CD、注册中心、配置中心、链路追踪。（2）司机位置与订单状态存 Redis（GEO 索引可支持附近司机查询），设置短过期；订单创建后发消息到队列，派单服务异步消费，队列削峰；消息消费需要幂等（订单号去重），失败进入重试与死信队列。（3）派单服务多实例 + 负载均衡；网关限流；调用下游（计价、风控）设置超时、熔断、降级（风控不可用时走默认规则或延迟校验）；数据库主从，缓存集群；灰度发布与快速回滚；监控告警与容量预案。

十三、我给自己定的 4 周案例专项计划

1. 第 1 周：框架周。把上面七张答案卡默写出来，不看书能写 80%。再刷 2024 至 2025 年的真题，只做“质量属性”和“架构风格”。
2. 第 2 周：数据与分布式周。集中做数据库、缓存、消息队列、分布式事务，每天 2 道题，写完对照评分点，用红笔补漏词。
3. 第 3 周：新技术与嵌入式周。每类只求“说得出五个要点”，不求深。新技术素材去读官方文档摘要。
4. 第 4 周：计时模拟。整套案例 130 分钟，机考环境输入，最后复盘：哪一类耗时最多、哪一类失分最多。

顺便说一句，有考生总结备考要“真题反复刷”，有人说要刷到 15 遍以上（这是一位通过者的个人说法），我的理解是：不是为了背答案，而是为了熟悉“题干如何转成评分点”这个翻译过程。因为真题每年换壳，但壳下面的骨架不变。

十四、常见失分原因（来自考生分享的共性，加上我的理解）

• 时间分配失衡：必答题写得过细，最后一题只写了两行。
• 只写概念不写场景：看起来“很对”，但没有对应题干，拿不到分。
• 被陌生技术吓到：遇到没见过的框架就放弃。其实题目问的往往是通用原理（异步 IO、分片、缓存），可以“教材概念 + 合理推断”。
• 机考输入的问题：有考生在论文科目遇到键盘故障，被迫换机器重写；案例里同理，要在开考前测试键盘和输入法，遇到问题立刻举手。
• 空题：宁可写得不完美，也别空着。

十五、附：知识框架速查图与口诀

最后放一张“分层优化思路”的图，用于数据库/缓存类题目的答案结构。答题时脑子里过一遍这张图，你的答案自然就有层次。

一句话备忘：案例分析不是写作文，是“把题干翻译成教材关键词”——必答题练熟质量属性，选做题只练熟四类，答案分点编号、每点带一个原词和一个场景词，每题 30–40 分钟，卡住三分钟就换题。

十六、易混概念对照：案例里最爱“考区别”

案例题很喜欢让你“比较”或“区分”，我把常被混淆的几组放在一起，考前扫一遍：

这些对照有一个共同的答题方法：用“维度 + 对比句”。例如比较同步与异步，先写“耦合度：同步调用方与被调方强耦合，异步通过消息中间件解耦”，再写“一致性”“复杂度”。每一个维度一句话，阅卷时一眼就能看到评分点。

再补一条关于“方案设计类”题目的写法，也是我觉得最容易吃亏的地方：不要只写方案名，要写方案的适用条件和代价。比如你写“使用 Redis 缓存”，只能得一半分；写“读多写少、热点集中的商品详情适合使用 Redis 缓存，并通过过期时间与删除策略保证最终一致，代价是增加一层组件与一致性风险”，评分点、场景词、代价都齐了。阅卷老师看到“代价”，就知道你不是背模板而是真懂。

十七、几点真实性说明

为了对得起“最新、真实”这四个字，我把没法百分百确认的东西列在这里：

• 考试形式（机考、5 选 3、时长）来自培训机构的报考指南和考生文章，我没有在官方站点上找到逐条对应的说明页，请以 ruankao.org.cn 与省级考试机构的最新公告为准。
• 2026 年下半年的具体考期，培训机构页面称为 10 月 24–27 日，但页面之间对上半年的考期表述也不完全一致（5 月 23 日或 5 月 23–26 日），所以请以报名平台公布的准考证日期为准。
• 教材版本：公开资料普遍写“第 2 版”，我没有查到新版教材成为考试依据的官方通知。
• 各期真题的主题，是我从考生回忆整理页面与培训机构页面读到的概括，可能有回忆偏差，也不是原题。
• 示例题 A 至 H 都是我自编的，答案是我写的示范，仅用于展示作答格式；标准评分点以官方阅卷为准。

参考资料

• 博客园：2025 下半年软考系统架构设计师题目回忆版——用于了解 2025 下半年案例（嵌入式、Petri 网、限界上下文）与论文题的大致方向。
• 希赛网：2025 上半年系统架构设计师案例分析真题及答案——用于了解 2025 上半年五道案例的主题（质量属性与解释器风格、Redis、知识图谱、边缘 AI、区块链）。
• 博客园：2024 年 11 月架构真题解析——用于了解 2024 下半年案例主题（质量属性、Cache-Aside、ROS、Web 分词、故障树与形式化验证）。
• 环球网校：软考系统架构设计师考试内容与频次（2026 版）——用于核对考试形式为机考、案例 1 必答加 4 选 2、合格线 45 分。
• 环球网校：2026 年上半年系统架构设计师考试时间与批次——用于核对科目时长与题量分值。
• 阿里云开发者社区：系统架构师考试经验分享（一次性通过）——一位考生对案例选题、时间和论文手速的个人体验。
• GitHub：hakusai22/System_Architect 二战备考记录——一位考生第一次案例失分、第二次通过的自述，用于案例失分原因的参考。
• 墨天轮：软考高级系统架构设计师，我的通关之路——一位考生对案例中陌生框架题的体验与备考周期建议。
• Peter 的技术小屋：2026 备考全攻略——用于对照题型分类（架构评估、数据库、微服务、消息缓存、安全、嵌入式、大数据等）。
• 阿里云开发者社区：系统架构设计师备考全攻略——用于对照综合知识占比与案例常考类型。