2026年上半年软考高级系统架构设计师案例分析回忆版

1. 字母与质量属性对应：

2. 需求 d 的质量属性场景六要素：

• 刺激源（Source）：未授权用户（外部非授权访问者或试图越权的内部用户）。
• 刺激（Stimulus）：发起越界访问或试图修改规则。
• 环境（Environment）：系统正常运行期间。
• 制品（Artifact）：系统的访问控制 / 规则管理 / 审计模块。
• 响应（Response）：立即拒绝请求，并将事件记录到安全审计日志。
• 响应度量（Response Measure）：拒绝行为为“立即”完成，审计日志在 1 秒内生成。

选择：管道—过滤器风格（Pipe-and-Filter）。

1. 实时性匹配：入侵检测的输入是连续的网络流量与主机日志，要求流式、低延迟处理；管道—过滤器以“数据来一段处理一段”的方式工作，契合流式场景。批处理需先攒齐一批再处理，无法满足“立即拒绝 + 1 秒内审计”的实时性要求。
2. 流程阶段独立：系统流程“采集 → 预处理 → 特征提取 → 规则 / 模型推理 → 告警产生 → 告警输出”天然是多阶段流水线，每阶段职责单一，与管道—过滤器模型一致。
3. 可扩展性强：新增检测算法或特征提取器只需新增 / 替换某一过滤器，对其他阶段无影响；批处理风格阶段耦合较紧，扩展成本高。
4. 可并发可分布：每个过滤器可独立部署、独立扩容，支持横向扩展应对流量峰值；单个过滤器故障不会拖垮全链路，便于降级与重试。

基于管道—过滤器风格，系统主要构件如下：

数据流：原始数据 → [采集] → [预处理] → [特征提取] → [规则 / 模型推理] → [告警产生] → [告警输出]，全链路通过消息队列管道解耦。

1. 时序数据与时序数据库：

时序数据（Time-Series Data）：以时间戳为主键、按时间顺序产生的数据。特点是写多读少、单调追加写、按时间窗口聚合查询、数据量巨大。本系统中环境传感器（温湿度、光照）、水电表、人体感应器、跌倒检测等持续产生高频时序点。

为什么使用时序数据库：

• 高吞吐写入：百万级设备的高频上报远超传统关系库的写入能力，TDengine 针对“按时间分区 + 列式存储 + 高压缩比”做了优化；
• 存储成本低：列式存储 + 时序压缩算法可达 10×~100× 压缩比，大幅降低长周期保存成本；
• 聚合查询高效：内建降采样、滑动窗口、插值等时序专用算子，秒级返回历史曲线；
• 生命周期管理：内建数据保留策略（自动过期、冷热分层），运维成本低；
• 关系型不适合：MySQL 等行式存储在百万级 IoT 写入下索引膨胀、查询慢，且不支持时序专用算子。

2. 四层架构主要功能：

本系统选择 QoS 2 的理由：

1. 系统涉及老人跌倒告警、一键急救呼叫、机器人送药指令等关键消息——丢失会延误救治、危及生命；
2. 同时这些消息不允许重复——重复呼叫医护、重复送药、重复急救指令都会造成混乱或医疗事故；
3. QoS 0 不保证送达、QoS 1 可能重复，均无法同时满足“不丢 + 不重”，必须使用 QoS 2；
4. 代价是 QoS 2 的四步握手会带来更高时延与 Broker 负载——非关键消息（如环境采样）可降级为 QoS 0/1，关键消息走 QoS 2，分级配置兼顾性能与可靠性。

• 感知层：通过智能门禁控制器、生物识别终端、周界传感器、摄像头等终端设备采集物理世界的原始数据与控制信号，并接收上层指令完成本地动作（开门、报警、播放语音）。
• 边缘层：在靠近数据源的位置部署边缘网关与本地计算节点，完成数据清洗、协议转换、结构化、轻量推理、本地缓存，将原始数据转换为结构化数据上送 AI 决策层；同时承担断网兜底与低延迟响应职责，降低云端压力。
• AI 决策层：以计算中心 + AI 模型 + 视觉分析引擎 + 规则分析引擎为核心，对边缘上送的结构化数据进行深度推理、行为分析、异常检测、综合决策，通过 API / 消息把决策结果下发给应用层或边缘层。
• 应用层：承载 APP 应用、显示大屏、第三方系统集成，将 AI 决策结果可视化、业务化，并完成与公安、消防、物业等跨系统的数据交换。

合计 11 个构件。

1. 跨层调用受限、灵活性差：分层架构强调严格逐层调用，应用层无法直接访问感知层数据；对极致实时性（毫秒级控制）的场景，逐层穿透带来不可接受的延迟。
2. 端到端时延累加：感知 → 边缘 → AI → 应用四跳，每跳带来网络 / 序列化 / 排队开销，长尾时延难控；AI 决策层若部署在云端，时延更不可控。
3. 边缘层与 AI 决策层职责边界模糊：轻量推理放边缘还是放云端难以一刀切，容易出现“边缘做太少 → 云压力大”或“边缘做太多 → 资源吃紧”的两难。
4. 网络依赖与可用性问题：云端协同强依赖网络，断网时若边缘兜底不足，应用层整体降级；跨层数据同步在弱网下一致性难以保证。
5. 横切关注点难以处理：安全、监控、运维、配置下发等横切能力需要在四层中重复实现，维护成本高，易出现配置漂移。
6. 边缘节点资源受限：边缘网关算力、存储、能耗有限，复杂 AI 模型部署受限，模型更新与热部署工程链路复杂。
7. 数据一致性与状态同步复杂：设备影子、缓存、规则版本在感知 / 边缘 / 云之间需协同，一致性难保障。
8. 演进与扩展性受限：新增一种业务往往需要四层联动改造，发布上线成本高。

1. 用户冷启动（User Cold Start）：

指新注册用户或长期不活跃用户在系统中缺乏历史行为数据（无浏览、无点击、无评分、无测评结果）的情形。导致：

• 无法构建该用户的兴趣 / 能力画像；
• 协同过滤算法找不到相似邻居；
• 基于行为的特征大量缺失；
• 只能给出热门推荐 / 默认推荐等粗粒度结果，正确率自然偏低。

应对：基于注册资料、年级、目标技能、入门测评做画像冷启动；混合内容推荐；引导式入门测评快速积累显式反馈。

2. 另外两种冷启动：

• 物品冷启动（Item Cold Start）：新加入的物品 / 课程没有被任何用户交互过，系统缺乏关于该物品的协同信号，难以将其推荐给合适的用户。应对：基于内容特征建模（标签、知识点、难度等）、引入运营冷启动流量。
• 系统冷启动（System Cold Start）：整个推荐系统刚上线或新业务线启动时，用户与物品的交互数据都很稀少，模型无法训练或效果极差。应对：先用规则 / 热门 / 编辑推荐过渡，逐步积累数据后切换到模型推荐。

1. 路径推理（算法侧）原因：

1. 缺乏前置依赖建模：算法主要基于相似度 / 相关性（协同过滤、内容相似），未显式建模知识点之间的前置依赖图（Prerequisite Graph），推荐时只看“相关”不看“先后”。
2. 目标导向偏差：算法以“目标技能 / 高考点”为锚，倾向推荐与目标接近的高级内容，忽视了从学员当前水平到目标之间需要补齐的基础链路。
3. 未引入能力评估闭环：未结合学员当前知识点掌握度（IRT / 知识追踪 BKT / DKT），无法判断学员能否承接下一个知识点。
4. 多样性优化与难度递进缺失：只优化点击率 / 完成率，未把“难度梯度合理”作为目标函数的一部分。

改进：引入知识图谱与前置依赖关系，结合知识追踪模型构建“能力—难度”匹配，在排序阶段加入难度递进约束。

2. 数据侧原因：

1. 样本分布偏倚：训练数据中中高级学员的行为样本远多于基础薄弱学员（基础薄弱学员留存率本身低），模型学到的特征偏向中高级学员。
2. 能力标签缺失或粗糙：缺乏对学员当前知识点掌握度的细粒度评估数据，无法区分“基础薄弱”与“中等水平”。
3. 隐式反馈噪声：基础薄弱学员的点击 / 浏览未必代表“听懂了”，反馈信号噪声大，模型容易把“高难度内容被点击”误认为“该用户能接受高难度内容”。
4. 课程难度标签不规范：难度标签由运营人工打，标准不统一，导致模型对“难度”理解失真。

改进：增加入门测评显式数据、标准化课程难度标签、引入显式的能力—难度匹配特征、对训练样本做重采样或加权以纠正偏倚。

悲观锁按行为方式（读 / 写）可分为两类：

1. 共享锁（Shared Lock，S 锁 / 读锁）

• 机制：事务持有 S 锁后，其他事务可继续加 S 锁读，但不能加 X 锁写；允许多读、禁止读写并发与写写并发。
• 典型场景：报表查询、对账等需要一致性读但允许并发读的场景。
• 设计方案：
  • 数据库：SELECT ... LOCK IN SHARE MODE（MySQL InnoDB）；
  • 业务层：快照读 + 共享锁组合，保证读取一致性。

2. 排他锁（Exclusive Lock，X 锁 / 写锁）

• 机制：事务持有 X 锁后，其他事务既不能加 S 锁也不能加 X 锁，完全独占；保证写写、读写串行化。
• 典型场景：账户扣款、库存扣减、订单状态变更等强一致写场景。
• 设计方案：
  • 数据库：SELECT ... FOR UPDATE（MySQL InnoDB）配合事务边界；
  • 分布式：Redis SET NX EX / Redisson 红锁、Zookeeper 临时顺序节点、etcd lease；
  • 设计要点：行锁优于表锁、按业务主键加锁；固定多资源加锁顺序避免死锁；分布式锁必须设置 TTL 与自动续约，防止持锁者宕机；可重入支持同一线程对同一资源多次加锁。

1. 乐观锁的实现方案：

(a) 应用层实现：

• 版本号机制（Version）：实体表加 version INT 字段；更新时 UPDATE t SET col=?, version=version+1 WHERE id=? AND version=?，影响行数为 0 即冲突；
• 时间戳机制（Timestamp）：用 updated_at 作为版本，逻辑同上；
• 业务字段 CAS：将原值带入 WHERE 条件，如库存扣减 UPDATE stock SET num=num-1 WHERE id=? AND num=?；
• 冲突重试 + 退避：应用层捕获冲突 → 指数退避 + 限重试次数；
• ABA 防护：版本号单调递增天然防 ABA。

(b) DBMS 层实现：

• MVCC（多版本并发控制）：InnoDB 通过隐藏列 DB_TRX_ID / DB_ROLL_PTR 与 undo log 实现快照读，读不加锁，写时通过当前读判断版本；
• 可重复读 / 串行化隔离级别：在事务提交时 DBMS 检测写冲突；
• CAS 原语：PostgreSQL xmin、SQL Server rowversion 等提供原生版本字段；
• ORM 框架集成：JPA @Version、Hibernate Optimistic Locking、MyBatis-Plus @Version 自动注入 version 条件。

2. 悲观锁 vs 乐观锁对比：

本题秒杀场景选型：

• 库存扣减：写竞争极高、强一致要求高 → 悲观锁（数据库行锁 + 事务 + Redis 分布式锁防超卖）；
• 商品详情读取：读多写少 → 乐观锁 / 缓存 + 版本号；
• 订单创建：使用乐观锁 + 唯一索引防重复下单；
• 兜底：乐观锁冲突重试限定次数与退避，超阈值降级到悲观锁或返回“商品繁忙”业务错误。

1. 缓存穿透（Cache Penetration）的优化

• 问题：查询不存在的数据，每次请求都打穿到 DB，恶意请求可拖垮 DB。
• 手段与实现：
  • 布隆过滤器（Bloom Filter）：缓存前置一层 Bloom，过滤一定不存在的 key（Redis 可用 RedisBloom 模块实现）；
  • 缓存空值：对查询为空的 key 也缓存一个短 TTL 的空对象（SET key NULL EX 60）。
• 场景：大量“查询不存在 key”的业务（非法 ID 爬虫攻击、按用户输入查询）。

2. 缓存击穿（Cache Breakdown）的优化

• 问题：热点 key 过期瞬间，大量并发请求同时落到 DB。
• 手段与实现：
  • 互斥锁（Mutex / SET NX）：未命中时只允许一个请求查 DB 并回填，其余等待（SET key val NX EX 10）；
  • 逻辑过期 / 永不过期 + 异步刷新：value 中带逻辑过期字段，物理 TTL 设为 -1，后台线程异步刷新；
  • 热点 key 预热：上线 / 活动前主动预加载到缓存。
• 场景：单一热点 key 高并发访问（秒杀商品详情、首页配置）。

3. 缓存雪崩（Cache Avalanche）的优化

• 问题：大量 key 在同一时刻集中过期，或 Redis 整体故障，请求全部打到 DB。
• 手段与实现：
  • 过期时间随机化：EXPIRE key (base ± random)，把过期时间打散；
  • 多级缓存：Caffeine 本地缓存 + Redis + DB；
  • 熔断降级与限流：Redis 故障时熔断降级到本地缓存 / 默认值，对 DB 加限流（Sentinel / Hystrix）；
  • Redis 高可用：主从 + 哨兵 / Cluster，避免单点故障。
• 场景：大规模缓存批量预热、定时全量刷新、Redis 主节点故障。