MX-2026-mock-01-案例分析

2026年上半年 系统架构设计师 - 案例分析模拟题（一）

模拟时间：150分钟 题型：必答1题 + 选答2题（共5题，从第2~5题中选答2题） 总分：75分 基于2023-2025年真题风格与考点分布编制

---

试题一（必答，25分）：质量属性与架构风格

场景描述

某智慧城市集团计划开发一套"城市智慧交通管控平台"，用于对城市道路交通流量进行实时监控、信号灯智能调度和交通事故预警。该平台需要接入全市数千个路口的摄像头和传感器数据，对交通流量进行实时分析和预测，并根据分析结果动态调整交通信号灯配时。

系统需求描述如下：

• a. 系统应能在接收到交通事故报警后3秒内自动识别事故位置并推送预警信息给附近交警
• b. 平台需要接入不同厂商的摄像头、雷达、地磁传感器等多种设备，并支持未来新增设备类型的无缝接入
• c. 所有交通监控数据和车辆轨迹数据应加密存储，未经授权的人员和系统不得访问
• d. 系统应支持同时处理至少5000个路口的实时数据流，数据延迟不超过2秒
• e. 管理界面应提供可视化的大屏监控面板，支持地图缩放、图层切换和数据钻取
• f. 系统应能在7×24小时不间断运行，当单个节点发生故障时，不影响其他节点的正常工作
• g. 当主数据库发生故障时，应在30秒内自动切换到备用数据库，保证数据服务不中断
• h. 系统应提供完善的操作日志和系统审计功能，便于故障追溯和安全审计
• i. 支持根据城市规模和业务需求的变化，在5天内完成新区域或新功能的上线部署
• j. 系统应支持自定义交通规则和信号灯配时策略，交通管理人员可以根据实际需要灵活配置
• k. 提供多语言界面和中英文操作文档，方便不同语言背景的管理人员使用

公司架构师李工认为该平台适合采用**管道-过滤器（Pipe-Filter）架构风格，资深架构师王工认为应当采用数据仓储（Data Repository）**架构风格。最终项目组采用了王工的建议。

问题1（12分）

请从质量属性的角度分析需求(a)~(k)，将每个需求对应的质量属性填入下表。

| 需求 | 质量属性 | |------|---------| | a | (1) | | b | (2) | | c | (3) | | d | (4) | | e | (5) | | f | (6) | | g | (7) | | h | (8) | | i | (9) | | j | (10) | | k | (11) |

问题2（8分）

请从交互方式、数据构造、控制构造和扩展措施4个维度，对管道-过滤器和数据仓储两种架构风格进行比较，填写下表。

| 比较维度 | 管道-过滤器 | 数据仓储 | |----------|------------|---------| | 交互方式 | (1) | (2) | | 数据构造 | (3) | (4) | | 控制构造 | (5) | (6) | | 扩展措施 | (7) | (8) |

问题3（5分）

在分布式系统中，为了监控系统各节点的运行状态，可以采用Ping/Echo和**心跳（Heartbeat）**两种模式。请从节约系统资源的角度，分析心跳模式相对于Ping/Echo模式的优势。

---

试题二（选答，25分）：层次式架构设计

场景描述

某软件公司正在开发一套"在线教育培训平台"，采用B/S架构，面向高校学生和企业员工提供在线课程学习、考试测评和学习进度管理等服务。系统采用经典的分层架构设计，分为表现层、业务逻辑层和数据访问层。

表现层采用MVC模式实现。用户通过浏览器访问系统，Controller接收用户请求后调用业务逻辑层的Service进行处理，Service处理完毕后返回数据给Controller，Controller选择合适的View进行页面渲染。系统前端使用Vue.js框架，通过RESTful API与后端交互。

业务逻辑层封装了核心业务规则，包括课程管理、用户管理、考试管理、学习记录管理等模块。该层采用了工厂模式（Factory Pattern）创建各类Service对象，采用策略模式（Strategy Pattern）实现不同考试类型的评分策略（如选择题自动评分、主观题关键词匹配评分等）。

数据访问层采用DAO模式，通过MyBatis框架实现与MySQL数据库的交互。为了提高数据库操作效率，该层使用了对象池技术管理数据库连接。

系统运行一段时间后，开发团队发现部分请求的响应时间较长。经过分析，发现存在以下问题：某些API请求需要依次调用多个Service，每个Service内部又调用多个DAO方法，导致大量的数据库连接获取和释放操作；部分查询操作涉及多表关联，SQL语句复杂且重复编写。

问题1（10分）

请根据上述描述，补充完成该系统的分层架构图（文字描述即可），标注出各层之间的交互方式和调用关系。具体要求：

(1) 写出表现层中MVC各组件的职责和交互流程； (2) 写出业务逻辑层中工厂模式和策略模式的作用； (3) 写出数据访问层中DAO模式的核心思想。

问题2（8分）

针对系统响应时间较长的问题，开发团队考虑在业务逻辑层引入外观模式（Facade Pattern），并使用缓存机制来优化性能。

(1) 请说明外观模式如何解决多次Service调用的问题，画出（或描述）引入外观模式前后的调用关系变化。

(2) 在分层架构中，缓存应该放在哪一层？请说明理由。如果放在业务逻辑层和数据访问层之间，是否存在"污水池反模式"（Architecture Sinkhole）的风险？如何判断？

问题3（7分）

该系统需要支持从当前的三层B/S架构平滑迁移到微服务架构。请回答：

(1) 微服务架构与三层架构在服务拆分粒度上有什么本质区别？ (2) 在迁移过程中，数据层应如何调整？为什么微服务架构通常要求每个服务拥有独立的数据库？

---

试题三（选答，25分）：数据库与缓存架构

场景描述

某电商平台在"双十一"促销活动中面临巨大的并发访问压力。系统日均订单量约50万单，促销期间峰值QPS可达10万。系统采用MySQL作为主数据库，Redis作为缓存层，整体架构遵循Cache-Aside（旁路缓存）模式。

系统当前的缓存读写流程如下：

• 读流程：先查Redis缓存，命中则直接返回；未命中则查MySQL数据库，将结果写入Redis缓存后返回。
• 写流程：先更新MySQL数据库，再删除Redis中对应的缓存数据。

在促销高峰期，系统出现了以下问题：

问题一（缓存穿透）：大量恶意请求查询不存在的商品ID（如ID为负数或超长字符串），这些请求每次都穿透到MySQL数据库，导致数据库压力骤增。

问题二（缓存击穿）：某个热门商品（如秒杀商品）的缓存刚好过期，瞬间大量并发请求同时到达，全部穿透到数据库查询同一条记录。

问题三（数据不一致）：在高并发场景下，线程A执行读操作（查缓存未命中→查数据库→准备写缓存），与此同时线程B执行写操作（更新数据库→删除缓存），导致线程A将旧数据写入了缓存，出现数据不一致。

此外，为了进一步提高系统的读性能，系统还引入了读写分离方案：主库（Master）负责写操作，从库（Slave）负责读操作，主从之间通过binlog进行数据同步。

问题1（10分）

请分别给出缓存穿透、缓存击穿和缓存雪崩三种问题的定义、产生原因，以及至少两种解决方案。

问题2（8分）

针对问题三中的数据不一致场景，请给出至少三种解决方案，并比较各自的优缺点。

问题3（7分）

关于读写分离方案，请回答：

(1) 请描述主从复制的基本原理（基于binlog）。 (2) 读写分离场景下，主从同步存在延迟，可能出现"写后读不一致"的问题。请给出至少两种解决方案。

---

试题四（选答，25分）：嵌入式系统设计

场景描述

某公司为某汽车制造商开发一套车载智能辅助驾驶系统（ADAS），该系统基于嵌入式实时操作系统（RTOS）运行，需要实时处理来自多个传感器的数据并进行驾驶辅助决策。

系统包含以下核心任务：

| 任务名称 | 执行周期 | 执行时间 | 优先级 | |---------|---------|---------|--------| | 刹车控制任务 | 10ms | 2ms | 最高 | | 转向控制任务 | 20ms | 4ms | 高 | | 摄像头图像采集 | 33ms | 8ms | 中 | | 雷达数据处理 | 50ms | 10ms | 中 | | 仪表盘显示更新 | 100ms | 15ms | 低 | | 日志记录任务 | 500ms | 20ms | 最低 |

系统采用可抢占的优先级调度算法。此外，系统还涉及中断处理：当车辆发生碰撞预警时，碰撞传感器会产生硬件中断，中断服务程序（ISR）需要在1ms内完成碰撞检测并触发刹车控制任务。

系统在道路测试中发现以下问题：

• 问题一：在传感器数据量突然增大时，仪表盘显示更新出现明显卡顿。
• 问题二：某次测试中，日志记录任务因写入Flash存储时发生错误，导致整个系统死锁。
• 问题三：在高负载情况下，刹车控制任务的响应时间偶尔超过5ms，不满足安全要求。

问题1（10分）

请使用速率单调调度（RMS）算法分析上述任务集是否可调度（CPU利用率是否满足可调度条件）。

(1) 计算每个任务的CPU利用率。 (2) 计算系统总CPU利用率。 (3) 使用RMS可调度条件（n个任务的可调度上限为 $n(2^{1/n}-1)$）判断系统是否可调度。

问题2（8分）

针对测试中发现的三个问题，请分别分析原因并给出解决方案：

(1) 仪表盘显示卡顿的原因及解决方案（从调度策略角度分析）。 (2) 日志记录任务导致系统死锁的原因及解决方案。 (3) 刹车控制任务响应时间超限的原因及解决方案（从中断处理和任务调度角度分析）。

问题3（7分）

(1) 请说明嵌入式实时系统中**看门狗（Watchdog）**机制的工作原理及其在提高系统可靠性方面的作用。 (2) 除了看门狗之外，请列举至少三种嵌入式系统常用的容错设计方法。

---

试题五（选答，25分）：大数据架构设计

场景描述

某大型连锁零售企业计划建设一套统一的数据分析平台，用于整合线上电商和线下门店的销售数据、用户行为数据、供应链数据和库存数据，实现精准营销、库存优化和经营决策支持。

数据规模与特征：

• 每日新增订单数据约2000万条，用户行为日志约5亿条
• 数据来源包括：MySQL业务数据库（订单、商品、用户）、Kafka消息队列（实时点击流）、第三方API（天气、竞品价格）
• 数据类型涵盖结构化数据（订单、商品信息）、半结构化数据（JSON日志）、非结构化数据（商品图片、用户评论）

业务需求：

• 实时需求：用户下单后5秒内更新推荐列表；库存变动后10秒内通知补货系统
• 离线需求：每日凌晨生成全量销售报表、用户画像和经营分析报告
• 历史需求：支持查询过去3年的销售趋势数据，用于年度经营分析

技术团队提出了两种架构方案：

方案一（Lambda架构）：

• 批处理层：使用Hive/Spark对全量历史数据进行离线计算，每日生成批处理视图
• 速度层：使用Flink对实时数据进行流式计算，生成实时视图
• 服务层：合并批处理视图和实时视图，对外提供统一查询接口

方案二（Kappa架构）：

• 所有数据通过Kafka统一接入，由Flink进行实时流处理
• 需要重算历史数据时，通过Kafka的消息回放功能重新消费历史数据
• 只维护一套流处理代码，降低系统复杂度

问题1（10分）

请从处理层组成、代码维护复杂度、容错能力、数据一致性保证、历史数据重算能力、适用场景六个维度，对Lambda架构和Kappa架构进行比较。

问题2（8分）

针对该企业的业务需求，请分析：

(1) 该企业的数据具有哪些大数据5V特征？请逐一说明。 (2) 该企业同时存在实时需求、离线需求和历史需求，你认为应该选择Lambda架构还是Kappa架构？请结合具体需求给出选择理由。

问题3（7分)

在Lambda架构中，批处理层通常采用数据仓库的分层设计。请回答：

(1) 请说明数据仓库的四层架构（ODS → DWD → DWS → ADS）中，每一层的职责和作用。 (2) 该企业的销售数据分析场景中，适合使用哪种OLAP操作来实现"查看某地区各门店上个月的销售额，并与上月进行对比"的需求？请说明该OLAP操作的含义。

---

---

参考答案与评分标准

---

试题一 参考答案

问题1答案（12分，每空1分）

| 需求 | 质量属性 | |------|---------| | a | (1) 性能（响应时间：3秒内识别并推送） | | b | (2) 可修改性（可扩展性：支持新增设备类型无缝接入） | | c | (3) 安全性（加密存储、访问控制） | | d | (4) 性能（吞吐量：5000路口并发，延迟不超过2秒） | | e | (5) 易用性（可视化大屏、地图交互） | | f | (6) 可用性（容错性：单节点故障不影响其他节点） | | g | (7) 可用性（可恢复性：30秒自动切换备用数据库） | | h | (8) 可用性（可维护性：操作日志、审计功能） | | i | (9) 可修改性（可扩展性：5天内完成新功能部署） | | j | (10) 可修改性（可配置性：灵活配置交通规则和配时策略） | | k | (11) 易用性（多语言界面和操作文档） |

评分标准：每空1分，共12分。写出大类质量属性即可得分，括号内子属性不要求。

问题2答案（8分，每空2分）

| 比较维度 | 管道-过滤器 | 数据仓储 | |----------|------------|---------| | 交互方式 | (1) 顺序交互，前一个过滤器的输出作为后一个过滤器的输入 | (2) 星型交互，各构件通过共享的中央数据存储进行交互 | | 数据构造 | (3) 基于数据流结构，增量式数据传递 | (4) 基于中央数据库的数据结构（如表、视图等） | | 控制构造 | (5) 数据驱动，由数据流的到达触发处理 | (6) 面向应用，由业务功能需求驱动控制 | | 扩展措施 | (7) 通过增加或替换过滤器扩展功能，通过接口适配新组件 | (8) 通过在数据库中增加新数据/新表、增加新构件访问共享数据来扩展 |

评分标准：每个维度2分，需同时答出两种风格的比较，意思相近即可得分。

问题3答案（5分）

心跳模式相对于Ping/Echo模式的优势：

1. 减少探测方的资源开销（2分）：Ping/Echo模式由探测方主动发起每个探测请求，需要维护所有被监控节点的状态和定时器；心跳模式由被监控方自主发送心跳包，探测方只需被动接收，大幅降低了探测方的CPU和网络开销。

2. 网络资源利用率更高（1分）：心跳模式中被监控方可以自主控制心跳发送频率，在节点数量众多时，相比Ping/Echo的逐一轮询方式，网络带宽消耗更低。

3. 可扩展性更好（1分）：当监控节点数量增加时，Ping/Echo模式的探测开销线性增长；心跳模式的探测方开销基本不变，具有更好的水平扩展性。

4. 故障发现更及时（1分）：心跳模式中每个节点独立发送心跳，不存在轮询间隔导致的故障发现延迟问题。

评分标准：答出上述任意要点即可，总分5分。重点在于"节约资源"角度的分析。

---

试题二 参考答案

问题1答案（10分）

(1) MVC各组件职责和交互流程（4分）：

• Model（模型）：封装业务数据和业务逻辑，一个模型可以为多个视图提供数据（1分）
• View（视图）：负责用户界面的展示，接收用户输入但不做业务处理（1分）
• Controller（控制器）：接收用户请求，调用业务逻辑层的Service进行处理，根据处理结果选择合适的View进行渲染（1分）
• 交互流程：用户请求 → Controller → Service（业务逻辑层） → DAO（数据访问层） → 数据库，返回数据后 Controller 选择 View 渲染页面（1分）

(2) 工厂模式和策略模式的作用（3分）：

• 工厂模式（1.5分）：封装Service对象的创建逻辑，调用方无需知道具体Service类的创建细节。当需要新增或替换Service实现时，只需修改工厂类，不影响调用代码，提高了系统的可扩展性和可维护性。
• 策略模式（1.5分）：将不同考试类型的评分算法封装为独立的策略类，通过统一的策略接口调用。运行时可以动态切换评分策略，避免了大量if-else判断，符合开闭原则。

(3) DAO模式的核心思想（3分）：

DAO（Data Access Object）模式的核心思想是将数据访问操作从业务逻辑中分离出来（1分）。DAO组件封装了与数据库交互的所有细节（SQL语句、连接管理、结果映射等）（1分），业务逻辑层通过DAO接口进行数据操作，不直接依赖具体的数据库实现，从而实现了业务逻辑与数据持久化的解耦（1分）。

问题2答案（8分）

(1) 外观模式的作用（4分）：

引入前：客户端需要依次调用多个Service，每次调用都涉及数据库连接的获取和释放，性能开销大。

引入后：创建一个Facade类，将多个Service的调用封装为一个统一的业务方法（如createOrderFacade()），客户端只需调用Facade的一个方法即可完成所有操作（2分）。

优势：

• 减少了客户端与多个Service之间的交互次数（1分）
• Facade内部可以优化Service的调用顺序和数据库连接的使用，减少连接获取/释放次数（1分）

(2) 缓存层级与污水池反模式（4分）：

缓存应该放在业务逻辑层与数据访问层之间（或数据访问层内部），因为缓存的核心目的是减少对数据库的访问次数，放在这一层可以最大程度地复用缓存数据（2分）。

污水池反模式判断：如果超过20%的请求只是简单地穿过某层而不做任何实质性处理，则存在污水池反模式（1分）。在本系统中，如果缓存层仅做缓存读写而没有任何业务逻辑处理，且大部分读请求直接命中缓存后返回（不进入数据访问层），则缓存层不构成污水池反模式；但如果缓存命中率极低，大部分请求仍穿透到数据访问层，则需要评估是否应合并缓存层与数据访问层（1分）。

问题3答案（7分）

(1) 微服务与三层架构的区别（3分）：

• 三层架构：按技术职责纵向分层（表现层、业务层、数据层），每层内部包含所有业务功能，是一个完整的单体应用（1分）
• 微服务架构：按业务域横向拆分为多个独立服务，每个服务内部可能都有自己的三层结构（表现、业务、数据），服务之间通过API或消息队列通信（1分）
• 本质区别：三层架构关注"层与层之间的分离"，微服务架构关注"业务功能之间的分离"，微服务的拆分粒度更细、独立性更强（1分）

(2) 数据层调整（4分）：

微服务架构要求每个服务拥有独立的数据库（数据库隔离原则）（1分），原因包括：

• 数据自治：每个服务独立管理自己的数据 schema，互不干扰，避免一个服务的表结构变更影响其他服务（1分）
• 独立部署：服务可以独立部署和扩展，共享数据库会导致部署时需要协调数据迁移（1分）
• 技术选型自由：不同服务可以根据数据特征选择最适合的数据库类型（如订单用MySQL，推荐用Redis，图谱用Neo4j）（1分）

---

试题三 参考答案

问题1答案（10分）

缓存穿透（3.5分）：

• 定义：客户端请求的数据在缓存和数据库中都不存在，每次请求都会穿透到数据库（1分）
• 原因：恶意攻击或业务逻辑漏洞导致查询不存在的数据（1分）
• 解决方案（1.5分，任答两点）：
  1. 缓存空值/缺省值：将不存在的key缓存为null值，设置较短过期时间
  2. 布隆过滤器（Bloom Filter）：在缓存前加一层布隆过滤器，快速判断key是否可能存在
  3. 参数校验：在请求入口对参数进行合法性校验（如ID范围、格式检查）

缓存击穿（3.5分）：

• 定义：某个热点key在过期的瞬间，大量并发请求同时到达，全部穿透到数据库查询同一条记录（1分）
• 原因：热点key过期 + 大量并发请求同时到达（1分）
• 解决方案（1.5分，任答两点）：
  1. 互斥锁（SETNX）：只允许一个线程查数据库并重建缓存，其他线程等待
  2. 热点数据永不过期：对热点key不设置过期时间，由后台任务定期刷新
  3. 逻辑过期：缓存中存储逻辑过期时间，过期后异步刷新，不阻塞读请求

缓存雪崩（3分）：

• 定义：大量缓存key在同一时间失效（或缓存服务宕机），导致大量请求同时穿透到数据库，数据库压力骤增甚至崩溃（1分）
• 原因：缓存key设置了相同的过期时间，或缓存服务器整体故障（1分）
• 解决方案（1分，任答两点）：
  1. 过期时间加随机值：给每个key的过期时间加上一个随机偏移量，避免同时过期
  2. 多级缓存：使用本地缓存 + 分布式缓存的多级缓存架构
  3. 缓存高可用：使用Redis Sentinel或Cluster保证缓存服务可用性
  4. 限流降级：当数据库压力过大时，启动限流或降级策略

问题2答案（8分）

方案一：延迟双删（3分）

• 流程：先删除缓存 → 更新数据库 → 延迟N毫秒 → 再次删除缓存
• 优点：大幅降低了数据不一致的时间窗口
• 缺点：延迟时间难以精确设定（太短可能来不及同步，太长影响性能）；增加了写操作的延迟；如果第二次删除失败仍可能不一致

方案二：监听binlog异步更新缓存（3分）

• 流程：通过监听MySQL的binlog，将数据变更事件发送到消息队列，消费者根据变更事件更新或删除缓存
• 优点：对业务代码零侵入；最终一致性保证较好；解耦了数据库和缓存
• 缺点：引入额外组件（如Canal + Kafka），系统复杂度增加；存在消息处理延迟，属于最终一致性方案

方案三：分布式读写锁（2分）

• 流程：读操作和写操作通过分布式锁互斥，确保同一时刻只有一个操作在执行
• 优点：强一致性保证
• 缺点：锁粒度大，严重影响并发性能；实现复杂度高；不适用于高并发场景

评分标准：每个方案答出流程/方法得1.5分，优缺点分析得1.5分（方案三因较简单，流程1分+优缺点1分）。总分8分。

问题3答案（7分）

(1) 主从复制基本原理（4分）：

• MySQL主库将所有数据变更操作记录到binlog（二进制日志）中（1分）
• 从库的IO线程连接主库，请求读取binlog并将获取到的binlog事件写入本地的relay log（中继日志）（1分）
• 从库的SQL线程读取relay log，重放（replay）其中的SQL语句，使从库数据与主库保持一致（1分）
• 整个过程是异步复制，从库存在一定的时间延迟（1分）

(2) 写后读不一致解决方案（3分，任答两点给满分）：

1. 强制读主库：写操作完成后的一段时间内（如500ms），将读请求路由到主库而非从库
2. 半同步复制：主库在事务提交前等待至少一个从库确认接收binlog，减少主从延迟
3. 缓存方案：写操作后将最新数据写入缓存，读请求优先读缓存，避免读从库读到旧数据
4. 版本号/时间戳方案：读请求携带写操作的时间戳或版本号，从库根据版本号判断是否已同步

---

试题四 参考答案

问题1答案（10分）

(1) 各任务CPU利用率计算（5分）：

| 任务 | 执行周期T | 执行时间C | CPU利用率 C/T | |------|----------|----------|-------------| | 刹车控制 | 10ms | 2ms | 2/10 = 0.2 | | 转向控制 | 20ms | 4ms | 4/20 = 0.2 | | 摄像头采集 | 33ms | 8ms | 8/33 ≈ 0.242 | | 雷达数据处理 | 50ms | 10ms | 10/50 = 0.2 | | 仪表盘显示 | 100ms | 15ms | 15/100 = 0.15 | | 日志记录 | 500ms | 20ms | 20/500 = 0.04 |

(2) 系统总CPU利用率（2分）：

U = 0.2 + 0.2 + 0.242 + 0.2 + 0.15 + 0.04 = 1.032（103.2%）

(3) 可调度性判断（3分）：

RMS可调度上限公式：$U_{limit}=n(2^{1/n}-1)$

当n=6时：$U_{limit}=6\times (2^{1/6}-1)=6\times (1.1225-1)=6\times 0.1225=0.735$（即73.5%）

系统实际CPU利用率U = 103.2% > 73.5%，超出RMS可调度上限，该任务集不可调度。

评分标准：每个任务利用率计算正确得0.5分（共3分），总利用率计算正确得2分，RMS上限公式和判断各得1.5分（共3分），总分10分。注：摄像头采集周期33ms的利用率计算取约等于即可。

问题2答案（8分）

(1) 仪表盘显示卡顿（2.5分）：

• 原因：仪表盘显示更新任务优先级最低，在高负载时被高优先级任务（刹车控制、转向控制、传感器处理）抢占，导致无法及时获得CPU执行时间（1分）
• 解决方案：
  • 将仪表盘更新任务拆分为高优先级的关键数据显示（如车速、告警）和低优先级的辅助信息显示（1分）
  • 或降低高优先级任务的执行频率/执行时间，为低优先级任务预留一定的CPU时间（0.5分）

(2) 日志记录导致系统死锁（2.5分）：

• 原因：日志记录任务在写入Flash存储时发生错误（可能Flash驱动层使用了互斥锁或信号量），错误处理路径中未正确释放锁资源，导致其他需要该锁的任务被永久阻塞（1分）
• 解决方案：
  • 为所有锁操作添加超时机制，防止无限等待（0.5分）
  • 在日志记录任务中加入看门狗监控，检测任务长时间阻塞后自动复位（0.5分）
  • 对Flash写入操作增加错误重试和降级策略（如写入失败时暂存到内存缓冲区）（0.5分）

(3) 刹车控制任务响应时间超限（3分）：

• 原因：在中断处理过程中，如果碰撞传感器中断到达时CPU正在执行某个高优先级任务且该任务的临界区（关中断区间）过长，或者存在中断嵌套过深导致中断延迟增大，刹车控制任务的响应时间就会超过安全要求（1分）
• 解决方案：
  • 缩短临界区：尽量减少关中断的时间，将非关键的临界区操作改用互斥锁（1分）
  • 中断分级处理：将碰撞传感器中断设为最高优先级，确保不被其他中断抢占（0.5分）
  • 双缓冲机制：传感器数据采用双缓冲区设计，中断服务程序仅做数据拷贝和任务唤醒，将复杂的数据处理交给任务完成（0.5分）

问题3答案（7分）

(1) 看门狗机制（4分）：

• 工作原理：看门狗是一个独立的硬件定时器电路。系统正常运行时，软件需要定期（喂狗）向看门狗定时器发送复位信号，重置定时器的计数值；如果系统发生故障导致软件无法按时喂狗，看门狗定时器溢出后会产生复位信号，强制重启整个系统（2分）
• 作用：
  • 检测系统死机或程序跑飞等软件故障（1分）
  • 在无人干预的情况下自动恢复系统运行，提高系统的可靠性和安全性（1分）

(2) 其他容错设计方法（3分，任答三种）：

1. N版本程序设计（N-Version Programming）：由不同团队独立开发同一功能的N个版本，运行时通过表决机制选择结果，防止单一版本的缺陷导致系统故障
2. 冗余设计（Redundancy）：关键硬件部件采用双机热备或三模冗余（TMR），故障时自动切换
3. 异常检测与恢复：通过硬件看门狗、软件异常检测（如栈溢出检测、内存校验）及时发现异常并执行恢复流程
4. 回滚恢复（Rollback Recovery）：定期保存系统检查点（Checkpoint），故障时回滚到最近的检查点状态继续运行
5. 安全攸关分区：将安全关键功能和非安全关键功能运行在不同的内存空间或处理器核心上，通过内存保护单元（MPU）隔离，防止非关键功能的故障影响关键功能

---

试题五 参考答案

问题1答案（10分）

| 比较维度 | Lambda架构 | Kappa架构 | |----------|-----------|----------| | 处理层组成 | 批处理层 + 速度层（实时层） + 服务层，三层结构 | 仅实时处理层 + 服务层，无独立批处理层 | | 代码维护复杂度 | 高，需要同时维护批处理和实时两套处理代码 | 低，只需维护一套流处理代码 | | 容错能力 | 强，批处理层可以定期重算全量数据，修正实时层的错误 | 依赖消息队列的数据保留和回放能力，容错性不如Lambda | | 数据一致性 | 通过服务层合并批处理视图和实时视图来保证一致性 | 实时处理直接产出最终结果，一致性由流处理引擎保证 | | 历史数据重算 | 天然支持，批处理层存储全量数据可随时重算 | 需要消息队列支持数据回放（如Kafka保留足够长的历史消息） | | 适用场景 | 需要同时满足实时和离线分析、对数据准确性要求极高的场景 | 实时性要求高、历史重算需求少、希望降低系统复杂度的场景 |

评分标准：每个维度答出两种架构的对比得1.5分（共9分），整体表述清晰得1分，总分10分。

问题2答案（8分）

(1) 大数据5V特征（3分）：

1. Volume（大量）：每日2000万订单 + 5亿行为日志，数据量巨大（0.5分）
2. Velocity（高速）：实时点击流数据持续产生，需要秒级处理响应（0.5分）
3. Variety（多样）：涵盖结构化（订单数据）、半结构化（JSON日志）、非结构化（图片、评论）多种数据类型（0.5分）
4. Value（价值）：单条数据价值密度低（如一条点击日志），但聚合分析后总体价值高（精准营销、库存优化）（0.5分）
5. Veracity（真实性）：数据来源多样（线上/线下/第三方），数据质量参差不齐，需要清洗和治理（1分）

(2) 架构选择（5分）：

建议选择Lambda架构（2分），理由如下：

1. 同时满足三类需求：Lambda架构同时包含批处理层和实时层，天然支持实时需求（Flink速度层）、离线需求（Hive/Spark批处理层）和历史需求（批处理层存储全量数据）（1分）
2. 数据准确性要求高：企业经营分析和财务报表对数据准确性要求极高，Lambda架构的批处理层可以定期修正实时计算的结果，保证数据准确（1分）
3. Kappa架构的风险：Kappa架构虽然复杂度低，但历史数据重算依赖Kafka消息保留，3年历史数据的存储和回放成本极高且不现实；且零售企业的业务场景对数据准确性要求严格，不适合完全依赖实时计算（1分）

评分标准：5V特征每答对1个得0.5分（共3分），架构选择判断正确得2分，理由充分得3分。如选择Kappa架构且理由合理，最多得3分（理由部分酌情给分）。

问题3答案（7分）

(1) 数据仓库四层架构（5分）：

| 层次 | 全称 | 职责和作用 | |------|------|----------| | ODS | Operational Data Store（操作数据存储层） | 原始数据层，直接存放从各业务系统抽取的原始数据，不做任何加工处理，保持与源系统一致 | | DWD | Data Warehouse Detail（明细数据层） | 对ODS层数据进行清洗、脱敏、标准化等ETL处理，形成统一的明细数据，按主题域组织 | | DWS | Data Warehouse Summary（汇总数据层） | 基于DWD层按不同维度（时间、地区、品类等）进行聚合汇总，生成轻度汇总数据 | | ADS | Application Data Store（应用数据层） | 根据具体的业务分析需求，基于DWS层数据生成最终的分析结果（报表、指标等），直接供前端应用使用 |

评分标准：每层说明正确得1.25分，共5分。说出全称加0.5分，说明职责加0.75分。

(2) OLAP操作（2分）：

适合使用**下钻（Drill-down）**操作（1分）。

含义：下钻是从较高层次的汇总数据深入到较低层次的明细数据的操作。在本场景中，从"某地区"的汇总销售额下钻到"各门店"的明细销售额，同时结合时间维度的"上月"与"上上月"对比，实现了从粗粒度到细粒度的数据探索（1分）。

注：如果回答"切片（Slice）+ 对比分析"也可酌情给分。

---

考点映射

| 试题 | 核心考点 | 对应章节 | 分值 | |------|---------|---------|------| | 试题一 | 质量属性识别 + 架构风格对比 + Ping/Echo vs 心跳 | 07、08 | 25 | | 试题二 | MVC、分层架构、设计模式、污水池反模式、微服务 | 07、13、14 | 25 | | 试题三 | 缓存穿透/击穿/雪崩、Cache-Aside、读写分离、数据一致性 | 06 | 25 | | 试题四 | RMS调度、中断处理、看门狗、容错设计 | 16 | 25 | | 试题五 | Lambda vs Kappa、大数据5V、数据仓库分层、OLAP | 19 | 25 |

使用建议

1. 模拟考试：按150分钟完成，重点练习试题一（必答）
2. 选答策略：根据个人知识储备从试题二~五中选答2题，建议优先选择自己最熟悉的领域
3. 评分自查：对照参考答案的评分标准逐项自评，重点关注得分点的覆盖情况
4. 薄弱环节：对照考点映射，针对得分率低的章节进行重点复习