2024年下半年系统架构设计师案例分析真题与参考答案(网友回忆版)

说明：

 本文根据网友回忆整理，题目顺序及部分题干可能存在偏差，部分小问和原始材料缺失。答案为个人整理的参考答案，仅供学习交流，请以官方发布的信息为准。

第 1 题：面向质量属性的软件架构设计

一、题目

阅读以下关于面向质量属性的软件架构设计的叙述，回答问题1和问题2。

某公司拟开发一个基于大语言模型的智能系统，该系统将通过多个大语言模型来协作处理用户提交的任务请求，任务求解过程的状态数据将被记录在任务板中，各个大语言模型根据任务板上任务的实时求解状态，来确定它们当前是否需要被调用以进一步处理该任务，并在处理完成之后将任务的最新状态更新到任务板上。

基于该系统的开发任务，公司召开项目讨论会。会上，项目组介绍了系统需求，主要包括：

（a）系统可支持用户在任务板上查看任务的状态和结果，并允许用户多次调用大型语言模型以进一步优化处理结果。

（b）系统可支持任务数据的导入导出，数据导入导出在1分钟内完成

（c）在数据服务器发生故障时，系统应能够立刻切换到备份服务器，并保证数据同步，以确保系统的不间断的服务。

（d）在系统正常负荷情况下，用户在任务板上查询任务状态和结果的响应时间应在2秒内。

（e）系统应确保用户数据和操作记录的安全，防止未经授权的访问。

（f）系统需要支持多语言接口，并提供查询词自动补全和搜索关联功能。

（g）系统应支持扩容，以容纳更多的用户和任务。扩容需求的实现应在两名运维人员工作的情况下在5天内完成。

（h）系统部署在云服务器上。当云服务器出现故障时，系统应在1分钟内检测出故障，并在1小时之内恢复。

（i）系统支持根据用户任务类型调用相应的大语言模型对任务进行处理。

（j）用户可以在任务板上搜索历史任务和结果，搜索结果应在3秒内返回

问题 1：识别功能性需求与质量属性

为了辅助架构师张工完成系统架构设计，首先需要对上述需求进行分析。请分析需求完善到表格中。

根据题目给出的需求，可整理如下。

这里需要注意两点。

第一，题目中的需求 b、d、j 都带有明确的时间限制，重点考查系统性能。需求 g 强调扩容所需的人力和时间，体现的是可修改性。

第二，需求 c 与 h 都涉及故障处理，但关注点并不完全相同。c 强调故障切换和数据同步，侧重可靠性；h 强调故障检测与恢复时间，侧重可用性。

问题 2：比较 Ping/Echo 与心跳策略

题目要求针对可用性需求 h，比较 Ping/Echo 策略和心跳策略，并解释为什么李工认为心跳策略更合适。

（1）两种故障检测策略的工作方式

Ping/Echo 策略

监控方主动向被监控节点发送 Ping 请求，被监控节点收到请求后返回 Echo 响应。监控方根据是否收到响应，以及响应时间是否超时，判断节点是否正常。

• 收到有效响应：说明节点在当前检测路径上能够响应请求。
• 未收到响应或发生超时：可能意味着节点故障、网络中断或响应延迟，需要进一步判断。

心跳策略

被监控节点按照预定的时间间隔，主动向监控方发送心跳消息。监控方记录最近一次收到心跳的时间，如果在规定期限内持续没有收到心跳，就将该节点判定为疑似故障，并触发后续的故障处理或切换流程。

心跳消息通常很短，可以只携带节点标识、状态或时间戳等必要信息。

（2）为什么可以选择心跳策略？

心跳策略的优势主要体现在以下方面：

不过，心跳并不一定比 Ping/Echo 更快，也不一定始终更节省资源。两者的开销与效率取决于实现方式、检测频率、网络环境等因素。心跳检测同样可能因网络拥塞或消息丢失而误判，因此通常需要结合超时阈值、连续丢失次数等条件判断。

第 2 题：基于 Cache-Aside 的缓存设计

一、题目背景

某购物网站为了提高商品信息的查询效率，决定将经常访问的商品数据放入缓存系统，减少对主数据库的直接访问。

经过讨论，项目组选择 Cache-Aside（旁路缓存）策略。

Cache-Aside 是一种常见的缓存设计模式。应用程序负责读取缓存、访问数据库，并根据需要更新或删除缓存；缓存系统本身不自动保证与数据库保持一致。

问题 1：Cache-Aside 的数据读取流程

使用Cache-Aside缓存策略，当用户查询商品信息时，此请求会从应用程序服务器发送请求到数据库服务器，通过缓存系统处理，然后返回所请求的信息，请补充完善图1中（1）~（5）处的内容，协助设计师完成缓存系统中的数据读取模块的设计方案。

当用户查询商品信息时，可以按照以下流程处理。

缓存命中时，不需要访问数据库；缓存未命中时，应用程序才从数据库读取数据，并将结果写入缓存。

需要注意的是，如果数据库中不存在对应商品，也要考虑如何处理缓存未命中，避免大量重复请求持续穿透到数据库。实际项目中可以结合空值缓存、布隆过滤器等方案处理缓存穿透问题。

问题 2：Cache-Aside 的数据更新流程

使用Cache-Aside缓存策略，当用户更新商品信息时，此请求会从应用服务器发至数据库服务器，并进行缓存处理，请补充完善图2中（1）和（2）处的内容，协助工程师完成缓存系统中的数据更新模块的设计方案。

对于商品信息更新，常见的处理顺序是：

为什么通常选择删除缓存，而不是直接更新缓存？

因为数据库中的数据通常是权威数据源。更新数据库后删除对应缓存，后续查询发现缓存不存在，就会重新读取数据库并重建缓存。

相比同时维护数据库和缓存中的完整数据，这种方式通常更简单，也能避免缓存中残留旧数据。

但要注意：先更新数据库、再删除缓存，并不意味着可以彻底消除并发情况下的数据不一致。

问题 3：并发读写为什么会产生数据不一致？如何解决？

题目中，线程 1 执行数据更新，线程 2 执行数据读取。王工认为这种设计可能导致数据库与缓存中的数据不一致。

这个判断是有道理的。

 1. 数据不一致是如何产生的？

假设数据库和缓存中最初保存的商品价格都是 100 元。

随后发生以下情况：

最终，数据库中的价格是 120 元，缓存中的价格却是 100 元。

这说明，Cache-Aside 的数据库操作和缓存操作不是一个原子事务。多个线程并发执行时，操作顺序可能交错，导致旧数据重新进入缓存。

2. 常见解决方案

方案一：使用锁机制

在涉及同一业务数据的关键读写流程中引入互斥锁或其他协调机制，避免读取旧数据与缓存写入操作发生不受控的交错。

这种方案需要注意锁的粒度、锁的持有时间以及分布式环境下的锁失效问题，否则可能影响并发性能。

方案二：使用消息队列进行异步同步

数据库更新成功后，将相关事件发送到消息队列，由消费者负责删除或更新缓存。

这种方式有利于解耦业务处理与缓存维护，但需要考虑消息重复投递、消息丢失、消费失败以及最终一致性问题。若要求数据库更新与事件发布可靠关联，可以考虑事务性 Outbox 等机制。

方案三：通过数据库变更日志同步

使用 MySQL binlog 等数据库变更日志，配合 Debezium、Canal 等工具捕获数据变更，再由消费端执行缓存失效或同步操作。

这种方式适合需要集中处理数据变更的系统，但也需要设计好消费位点、失败重试和事件幂等处理。

方案四：使用数据库触发器

在数据库发生 INSERT、UPDATE 或 DELETE 操作时，通过触发器执行相关逻辑。

不过，触发器直接访问外部缓存通常不适合作为通用方案。更常见的做法是让触发器写入数据库中的事件表，再由其他组件异步处理。

方案五：采用延迟双删策略

一种常见做法是：

第二次删除的目的，是尽量清理并发读取过程中可能重新写入的旧缓存。

但延迟双删并不能提供严格的一致性保证，其效果取决于并发时序、延迟设置以及请求持续时间。对一致性要求较高的场景，还需要其他协调机制。

方案六：采用 Write-Through 等缓存写入模式

在 Write-Through 模式下，写操作经过缓存层，并由缓存层同步写入数据库，具体事务和一致性能力取决于实现。

它可以改变应用程序维护两份数据的方式，但并不意味着所有并发问题都会自动解决。选型时需要结合缓存产品的能力、事务支持以及业务一致性要求。

 3. 如何选择？

不同方案的适用场景有所区别：

在一般的商品查询场景中，Cache-Aside 配合“先更新数据库、再删除缓存”通常是一个合理起点。如果业务对一致性要求更高，再根据并发规模、可接受的数据延迟和系统复杂度选择补充机制。

第 3 题：暂时缺少

暂无

第 4 题：Elasticsearch 分词与商品推荐系统

一、题目背景

本题涉及基于 Elasticsearch 的商品推荐系统，并通过微信小程序向用户提供服务。

问题 1：Standard、Simple、Whitespace 和 Keyword 分词器有什么区别？

Elasticsearch 的分词器会把输入文本处理为一个或多个词项（Token），供倒排索引和搜索使用。

四种常见分词器的区别如下。

举例来说，输入文本为：

Hello, World! 2024

在常见配置下，四种分词器的处理结果可以概括为：

• Standard：hello
  、world、2024
• Simple：hello
  、world
• Whitespace：Hello,
  、World!、2024
• Keyword：Hello, World! 2024

其中，Simple 会丢弃由数字和标点等非字母字符构成的部分；Whitespace 只按空白字符分隔，不会主动删除词项内部的标点。

还需要注意中文分词问题。Standard 分词器并不等同于面向中文语义的专业分词器。对于中文商品名称、品牌、品类等搜索场景，通常需要结合中文分词插件或自定义分析器，才能获得更符合业务预期的搜索效果。

问题 2：架构图填写

问题 3：RESTful 架构如何实现前后端分离？

RESTful 架构通过资源、统一接口和标准 HTTP 方法组织客户端与服务器之间的交互，为前后端分离提供了一种常见的设计方式。

主要体现在以下几个方面。

1. 通过资源和 URL 组织接口

将业务对象抽象为资源，并使用 URL 标识资源。例如：

GET    /api/products/1001POST   /api/productsPUT    /api/products/1001DELETE /api/products/1001

这些接口分别对应获取商品、创建商品、更新商品和删除商品等操作。

2. 使用标准 HTTP 方法表达操作

客户端通过 GET、POST、PUT、DELETE 等方法表达不同的操作意图，服务端根据请求方法和资源地址执行对应处理。

3. 明确前后端职责

前端负责页面展示、用户交互和界面状态管理；后端负责业务规则、数据处理、权限校验和持久化存储。

前端通过 HTTP API 向后端发送请求，并根据返回的数据更新页面。常见的数据格式是 JSON。

4. 通过接口契约实现独立开发

前后端提前约定 URL、请求方法、参数、响应结构和错误码，就可以分别开展开发和测试，降低双方对内部实现细节的依赖。

本期小结

本次整理涉及四类常见的系统架构设计知识：

• 质量属性：
   根据需求描述识别功能性、性能、可靠性、可用性、安全性和可修改性。
• 故障检测：
   理解 Ping/Echo 与心跳机制的工作方式，以及它们在开销和检测时效上的差异。
• 缓存设计：
   掌握 Cache-Aside 的读写流程，重点理解并发读写导致缓存与数据库不一致的原因。
• 搜索与接口设计：
   区分 Elasticsearch 常见分词器，并理解 RESTful 架构对前后端职责分离的支持。

#软考 #系统架构师 #案例分析