系统架构设计师 2023 年下半年真题与答案解析

这一场在系统架构师的历史上有点特殊：2023 年 11 月 4 日，它是这门考试第一次机考，也是教材改版（第 2 版）之后的第一次考试，综合知识从以前的 75 分钟 45 题改成了 150 分钟 75 题。题多了、范围宽了，很多考生考完的第一反应是“超纲了”。所以这篇我要做的事很明确：把公开网页上真实读到的回忆版答案整理出来，逐题写自己的解析，再把案例与论文讲透；凡是来源说不清的、明显自相矛盾的，我都会老老实实标“存疑”或“答案待核实”，不替你编答案。

版权与使用说明：真题版权归考试主办方所有。本文对每道题只做“题意概括 + 答案要点”，并附我自己写的解析，不整页搬运原卷。本场的公开资料几乎都是考后网友回忆，题干常常只有几个关键词，答案也常是“内容”而不是字母；请以官方发布及正版真题为准。文中所有答案都来自我真实打开读过的页面，来源见文末。

一、场次概况：日期、形式与本文覆盖范围

关于“第一批次”：希赛网页面称“第一批次考试”。机考时代可能分批次组织，不同批次试卷内容可能不同；我读到的回忆版几个来源内容高度一致，应当属于同一批次，但是否存在其他批次、内容是否有差异，我无法核实，这也是本文的一个局限。

二、综合知识：回忆版答案速对与逐题解析

综合知识这一科，网上流传最广的是一份“考后有小伙伴凭记忆整理”的清单：按题号列出各题的考点和答案要点。我在 CSDN 的三篇文章里读到了完全相同的这份清单（DS_Watson、ducanwang、moshowgame 三个博主，后两位在文中明确写“答案仅供参考，不一定正确”），说明这是同一个源头被多次转载，并非三个独立来源，所以我把整份清单的可信度都按“单一来源”处理，并用自己的知识逐题核对，核对后觉得有问题的，单独标“存疑”。

再强调一次这份清单的特点：题号是考场题号（回忆顺序可能与真实顺序略有出入），但多数题只记了考点和答案内容，没有题干全文，也没有选项字母。所以下面的速对表写的是“答案内容”，并不是 A/B/C/D。少数几道题，博主附了更完整的回忆原题（ABSD、架构需求、关系范式、嵌入式、内核等），我会在解析里说明。

2.1 答案速对表

“可信度”一栏：一致＝与教材/通用知识核对无冲突；存疑＝回忆内容与我的核对有冲突或语义不清；待核实＝来源只给了题材没有答案。

统计（我按上表人工数的，不是官方统计）：速对表覆盖考场题号 1–75；标“一致”的条目约占七成，标“存疑”或“待核实”的约占三成，具体见下方 2.3 与第六节。题号 70 的排序题、第 47 题等没有可用信息。

2.2 逐题解析（按知识块折叠）

下面把 70 多道题按知识块分成六组，每组一个折叠块，里面是逐题的题意、答案和我自己写的解析。点开看，不想看的折起来刷下一组。

SELECT dept, AVG(salary) AS avg_sal
FROM emp
WHERE status = 'active'          -- 先过滤行
GROUP BY dept                    -- 再分组
HAVING AVG(salary) > 10000;      -- 最后过滤组

2.3 综合知识小结：有多少题是真正“确认”的

• 回忆清单覆盖了 75 题中的大部分条目，但都是单一链条来源，且只是回忆，我标“一致”的只表示“与教材/通用知识无冲突”，不等于官方答案。
• 我标“存疑”的共 7 组（第 1–2 题字母、第 20、31、53–54、55、58–59、61 题），遇到原题务必自己再核。
• 本场 75 题的完整题干我并未读到，全部是回忆版要点，这里不假装有原题全文。

三、案例分析：能还原到什么程度

案例这一科，我读到的是 DS_Watson 的回忆整理（文中注明试题一、二部分取自某培训老师的押题，并标了“非原题原图”的部分）、moshowgame 的考点归纳和博客园 zhaotianff 的总结。三者对“必答题是大数据架构”一致；对后四题的具体考点不完全一致，下面逐题写。

一处冲突：博客园 zhaotianff 的总结里提到“其他题目包括嵌入式、微服务”，而 DS_Watson 的清单里是数据库、Hibernate 与数字孪生。我的判断是：机考分批次，不同批次试题可能不同，或者某位博主对考点的记忆有差异，无法判定谁对，本文以 DS_Watson 的清单为主并标出这个分歧。

3.1 第 1 题：Lambda 与 Kappa 大数据架构（必答，25 分）

题干概括：某视频网站是某电视台的互联网门户入口，独家转播某奥运会，积累了海量用户数据。奥运期间需要在当日概览（秒级刷新在线人数、浏览量、停留时间、播放次数等千万级实时指标，传统分布式架构靠重新计算，做不到几秒内出结果）和赛事回顾（自定义时间段的历史最高在线人数、逐日走势、排行等海量统计，数据不常更新，要求以不可变方式存储历史数据）两个层面分析增量数据。

问题 1（8 分）：对比填表

参考答案（来源 DS_Watson，另一篇数据知道专栏公开片段给出同样的结果）：(1) 2；(2) 1；(3) 高；(4) 低；(5) 必要时进行全量计算，计算开销相对较小；(6) 满足实时性；(7) 大；(8) 弱。

自写解析：Lambda 把“准确但慢”的批处理和“快但可能不精确”的流处理并行，在服务层合并，所以要维护两套代码与两套引擎（比如 Hadoop/Spark 批 + Storm/Spark Streaming 流），同一个业务逻辑要写两遍，这是它最大的痛点。Kappa 用“可重放的日志 + 一套流计算”取消批处理层：需要修正历史数据时，启动一个新版本的流作业，从日志起点重新消费，追上后切换视图。Kappa 的前提是消息队列能长期保留数据、流引擎能高吞吐回放。

问题 2（9 分）：补全架构图

题目给了 (a)–(n) 十四项技术/层次词（Nginx、HBase、Spark Streaming、Spark、MapReduce、ETL、MemSQL、HDFS、Sqoop、Flume、数据存储层、Kafka、业务逻辑层、数据采集层），要填图中的 9 个空。博主给的答案：(1) d；(2) e；(3) k；(4) g；(5) h；(6) i；(7) j；(8) f；(9) n。由于图没有还原，我不对每个空做逐一对应解释（我无法确认空位次序），只给这张图的分层逻辑，方便你遇到同类题时自己推：

问题 3（8 分）：三个层次与架构判断

Lambda 的三层：(1) 批处理层；(2) 加速层（速度层）；(3) 服务层。结论：该系统的大数据平台是基于 Lambda 架构搭建的——既有处理历史全量的离线计算，又有秒级刷新的实时计算，并在展现层合并两类视图。这与题干中“历史数据不可变存储”“当日秒级刷新”两点呼应。

回链：大数据与分布式架构在《综合知识精讲（下）》；案例答题模板见《案例分析：题型拆解与答题模板》。

3.2 第 2 题：SysML 需求图与 UML 用例图

题意（回忆，背景不详）：背景是一个信息系统，有两种获取需求的方案：UML 的用例图、SysML 的需求图。博主标注“背景与问题无关，不影响作答”，且第 2 问的图“非原题原图，老师自己出的”。三问大致是：(1) 给出需求图与用例图的定义并说明区别；(2) 给出需求图的七种关系及其定义，并把选项填到混合动力 SUV 需求图的 5 个空；(3) 用例图填空（据反馈很简单）。

问题 1 自写答案：

• 需求图（Requirement Diagram）：SysML 特有的图，用来表述文本化的需求、需求之间的关系，以及需求与其他模型元素（设计、测试等）的关系（满足、验证等）。它让“需求”成为模型里的一等公民，可追踪。
• 用例图（Use Case Diagram）：从用户（参与者）的角度描述系统提供的功能及与外部的交互，粒度是“功能目标”。
• 区别：需求图关注“系统必须满足什么（含功能与非功能需求）以及需求如何被追踪、被满足、被验证”；用例图关注“谁用系统做什么”。博主的答案里写“需求图偏系统功能流程，用例图偏用户体验”的说法我不太赞同——需求图并不描述流程，这一点请以教材定义为准。

问题 2：需求图的七种关系（来源答案，我用自己的话改写）：

填图部分的参考答案：(1)–(5) 分别填 B、C、D、E、F（功能需求、性能要求：环保、性能要求：表现、性能要求：排放、性能要求：燃油经济）。图没有还原，我不做逐空解释。这题的得分关键是把七种关系“关系名 + 一句话定义 + 例子”背下来。

3.3 第 3 题：数据库主从复制、读写分离与 Redis（只有题材）

回忆只有“数据库主从复制、读写分离架构；Redis 缓存”，moshowgame 的归纳里多了“Redis 数据丢失”。我没有读到具体设问与答案，所以答案待核实。我写一下这几个点的考法，属于知识讲解，不是原题答案：

• 主从复制：主库写、从库读，通过 binlog 异步（或半同步）复制；带来读扩展与备份能力，代价是复制延迟导致的读不一致。
• 读写分离：应用层或中间件（如 ShardingSphere、ProxySQL）按 SQL 类型路由；强一致读走主库。
• Redis 数据丢失的原因与对策：内存数据库断电即失；对策是开启 RDB 快照 + AOF 日志（混合持久化），配置 主从 + 哨兵/Cluster 保证高可用；缓存要防穿透（布隆过滤器/空值缓存）、击穿（互斥锁/逻辑过期）、雪崩（过期时间打散、多级缓存）。

3.4 第 4 题：Hibernate、数据持久层与 JWT

回忆给出：Hibernate 体系架构图（应用程序持久化对象、Hibernate 配置与映射、数据库），以及 JWT 的优缺点。设问与答案我只读到 JWT 这一块，博主的整理如下（我用自己的话改写并补充）：

JWT 由三部分组成：Header.Payload.Signature，用点号连接，前两段 Base64URL 编码。Hibernate 是 Java 的 ORM 框架，核心概念：Configuration → SessionFactory → Session → Transaction，映射文件或注解把对象属性映射到表列。持久层的价值是把业务代码与 SQL 解耦，代价是复杂查询和性能调优需要理解底层 SQL。本题具体设问我没读到，答案待核实。

3.5 第 5 题：数字孪生（只有题材）

回忆只有“数字孪生概念、技术选择、架构图填空”。数字孪生的常见分层（教材口径）：数据采集与物联网层、数据互动层、模型构建层、仿真分析层、共性应用层，2024 上半年综合知识里就有“描述、诊断、预测、决策”对应哪一层（答案：共性应用层）的题。具体设问待核实。

四、论文：四道题的考查方向与写作方案

四道题的题目方向，DS_Watson（题干概述）、博客园一篇考后总结与希赛论文页可以互相印证：

一处命名差异：希赛论文页把第 1 题写成“论软件可靠性”（该页只列出这一个题目），DS_Watson 写“可靠性分析与评价方法”，题目原文措辞无法核实，以考场原题为准；二者考查的内容是同一方向。我也没有找到官方标准范文，下面的写作方案是我自己整理的，不是评分标准。

论文通用骨架与评分点，见《论文写作：套路、模板与素材库》，以及《2025 年下半年真题》里我整理的自查清单。

4.1 论软件可靠性：分析与评价方法

概念：软件可靠性是指在规定的条件下、规定的时间内，软件不引起系统失效的概率。常用指标：失效率、MTTF、MTBF、MTTR、可用性 A = MTTF/(MTTF+MTTR)。

评价方法（回忆资料里的模型分类，我用自己的话整理）：可靠性模型大致有十类，代表如下。

（上表“代表”一栏，除回忆资料中明确出现的几个名字外，都是我补充的常见文献命名，仅供写作时参考，请自行核对后再用。）

提高可靠性的手段：需求阶段确定可靠性目标；设计阶段用容错技术（N 版本程序设计、恢复块、检查点与回滚、看门狗）、冗余与降级；编码阶段遵循规范、做静态分析；测试阶段基于运行剖面做统计测试、做故障注入；运行阶段监控、灰度发布、快速回滚；管理上引入净室软件工程等方法。

提纲示例：摘要（项目、角色、采用的评价方法与成效）→ 可靠性概念与指标 → 所用模型及选择理由（如用 NHPP 做测试阶段的缺陷预测）→ 项目中的实施过程（数据收集、模型拟合、结果与决策：何时可以发布）→ 遇到的问题（数据不足、模型假设不成立）与对策 → 效果（缺陷密度、MTBF 提升）→ 总结。

4.2 论面向对象分析建模及应用

题干核心（回忆）：软件系统建模帮助理解系统、抽取业务过程、管理复杂性，并方便人员沟通，是连接需求分析与系统实现的桥梁；要求论述面向对象建模的用例模型与分析模型、UML 图，并结合项目说明如何应用。

要点：

• 用例模型：识别参与者 → 合并需求获得用例 → 细化用例描述（事件流、前置/后置条件、扩展点、非功能需求、优先级）→ 调整用例模型（包含、扩展、泛化关系）。
• 分析模型：定义概念类 → 识别类之间的关系（关联、聚合、组合、泛化、依赖、实现）→ 为类添加职责。
• UML 图：用例图、类图、对象图、序列图、通信图、状态图、活动图、包图、构件图、部署图。可按“静态结构 vs 动态行为”划分。
• 价值与取舍：在敏捷团队里建模要轻量，用于沟通而非文档堆砌；领域复杂时可引入 DDD 的限界上下文。

提纲示例：摘要 → 面向对象建模概述（为什么建模、建模步骤）→ 项目背景与我的角色 → 用例建模过程（参与者与用例清单示例）→ 分析建模（核心类与协作，举 1–2 张图的文字描述）→ 难点（需求变更、类职责划分、模型与代码同步）与对策 → 效果 → 总结。

4.3 论多源数据集成及其应用

题干核心（回忆）：多源数据指不同来源、格式、标准的数据，供企业共享；集成技术主要有联邦式、基于中间件模型、数据仓库三类；要求简要分析各自侧重点与适用场景，并描述项目中如何建立多源数据集成应用。

实施过程：数据源盘点与质量评估 → 统一元数据与主数据（编码、口径）→ 选择集成方式并设计架构（采集/ETL/存储/服务）→ 数据治理（质量、血缘、权限）→ 应用（报表、画像、API）→ 运营。难点：数据口径不一致、主键冲突与重复、实时性要求、敏感数据脱敏。提纲：摘要 → 三种技术对比 → 项目背景（如集团客户 360 视图）→ 架构与流程 → 难点对策 → 效果 → 总结。

4.4 论边云协同

题干核心（回忆）：云计算擅长全局、非实时、长周期的大数据处理；边缘计算更适合局部、实时、短周期数据的处理与分析，既靠近执行单元，又是云端所需高价值数据的采集与初步处理单元。云端通过大数据分析优化出的规则或模型可以下发到边缘侧。要求论述边云协同的主要内容，并结合项目说明应用。

回忆资料中列出六种协同，我用自己的话整理：

难点与对策：弱网或断网下边缘自治（本地缓存、断点续传）；模型下发与版本一致性（灰度、回滚）；边缘设备异构与安全（设备认证、固件签名、最小权限）；数据上云的带宽与成本（边缘过滤、聚合）。提纲：摘要 → 边云协同概述与六种协同 → 项目背景（如智慧工厂质检、车路协同）→ 架构设计（端-边-云三层，数据与模型双向流动）→ 难点对策 → 效果（时延、带宽节省、准确率）→ 总结。

4.5 摘要示例（自写，仅供练手）

2022 年 6 月，我参与了某制造企业“智能质检平台”的建设，担任系统架构师，负责整体架构设计与关键技术选型。平台需要在产线现场毫秒级判定产品缺陷，同时利用全厂数据持续优化检测模型。本文结合该项目，论述了边云协同的应用：在边缘侧部署推理服务与本地缓存，实现低时延检测与断网自治；在云端集中训练并通过灰度方式下发模型，并以统一的设备与应用管理实现资源协同与应用管理协同。系统上线后，单件检测时延明显下降，上云带宽大幅减少，模型迭代周期缩短，验证了方案的有效性。

这段摘要的数字我故意没写死，你自己写时请替换为真实项目的量化结果。论文最忌编造与项目不符的数据。

五、本场考点热度总结

复习建议：这一场给我的最大感受是“构件、架构评估、架构风格”三大块几乎都是“送分送在教材里”；而新教材增加的“新技术”内容（M2M、NPU、数字孪生、区块链、边云协同）在广度上需要补。案例的大数据、SysML，都是“教材里有定义、但考你表格和关系”的类型，背表格比背概念有效。

一句话备忘：2023 下半年这场是“机考 + 新教材”的第一战：综合知识吃透构件、ABSD、质量属性、范式；案例盯 Lambda/Kappa 对比表与 SysML 七种关系；论文备“可靠性 / 建模 / 数据集成 / 边云协同”四条线；凡是来源说不清的地方，我都没替你编。

六、答案冲突与待核实项

• 综合知识清单来自同一源头的三次转载，非三个独立来源；已标“存疑”的：第 1–2 题字母、第 20 题（通道）、第 31 题、第 53–54 题（领域输出应为领域设计）、第 55 题（管道并行）、第 58–59 题、第 61 题（构件外部可见状态）。
• 第 17、18、23、27–28、37、38、41、47、56、70 题：来源信息不足，答案待核实。
• 案例第 2–5 题的完整设问、第 3、5 题答案：未读到，待核实；案例后四题考点在不同博主之间有分歧（数据库与 Hibernate 与数字孪生 vs. 嵌入式与微服务），无法判定。
• 第 1 题问题 2 的 9 个空只有来源给出的字母，我无法对照原图核实。
• 论文第 1 题的原文措辞（论软件可靠性 / 可靠性分析与评价方法）：来源措辞不同，以原题为准。
• 考试可能分批次，我只读到“第一批次”的回忆，其他批次可能内容不同。

参考资料

• CSDN DS_Watson：软考-2023 年 11 月系统架构设计师真题回忆——综合知识 75 题答案要点、案例五题线索与大数据案例完整答案、论文四题概述。
• CSDN ducanwang：2023 年 11 月架构设计师上午真题及答案——与上一篇内容一致的综合知识清单（转载链条的另一个节点）。
• CSDN moshowgame：2023 年高级软考系统架构师考题参考——同一清单的另一转载，并给出案例考点归纳，并注明“答案仅供参考，不一定正确”。
• CSDN 数据知道：【系统架构设计师-2023 年真题】案例分析——免费可读片段给出案例第 1 题问题 1 的答案，用来交叉核对；全文为付费内容，我只用了公开部分。
• 博客园 zhaotianff：2023 年系统架构设计师考试总结——考试日期 11 月 4 日、首次机考与新教材、考点线索。
• 希赛网：2023 下半年系统架构设计师第一批次考试真题及考情——“第一批次”表述，页面正文为图片。
• 希赛网：2023 下半年系统架构设计师论文真题——论文第 1 题“论软件可靠性”，日期 11 月 4 日。

再次提醒：以上均为第三方回忆整理，可能存在遗漏或错误，请以考试主办方发布及正版真题为准；本文的解析与素材为个人整理，不代表官方评分标准。