一、质量属性与架构评估（贯穿全表，出现频次最高）

1. 质量属性效用树

效用树是对质量属性进行识别、分类和优先级排序的架构评估工具，根节点是“效用（Utility）”，向下分解为性能、可用性、安全性、可修改性等质量属性，叶节点是具体的质量属性场景。

填空题常见形式：给定场景描述，补全效用树中的质量属性或子属性，并对叶节点标注（重要性，实现难度）即（H/M/L，H/M/L）。

典型树形结构示例：

• 性能：数据延迟（在线交易响应≤2s，H/M）、事务吞吐（5000 TPS，H/H）

• 可用性：硬件故障（5min内恢复，H/L）、软件容错（服务降级时核心可用，M/M）

• 安全性：数据加密（AES，H/L）、访问控制（RBAC，M/L）

• 可修改性：接口扩展（新增API≤2人天，M/L）、业务规则配置化（H/M）

2. 敏感点、权衡点、风险点、非风险点

• 敏感点：一个或多个构件（和/或构件之间的关系）的特性，对某个质量属性有显著影响。例如“查询响应时间要求影响数据传输协议和处理过程的设计”描述的是敏感点。

• 权衡点：影响多个质量属性、且对多个质量属性都是敏感点的系统属性。例如“加密算法选择”同时影响安全性和性能，就是典型权衡点。

• 风险点：架构决策可能带来潜在质量属性下降的不确定性。例如“业务逻辑尚未达成共识”是风险点。

• 非风险点：已有明确依据、风险可控的决策。

答题时先判断题干描述影响的是一个还是多个质量属性——只影响一个是敏感点，影响多个是权衡点。

3. 质量属性场景六要素

一个完整的质量属性场景由六部分组成：

填空题常挖去“响应度量”或“环境”，结合上下文补全即可。

4. 敏感信息超过 16 字节的处理

超长敏感信息（如超长域名、完整地址）直接加密效率低，常见处理策略：

• 分块加密：将长敏感字段拆分为多个字节块，分别加密，提升加密效率。

• 令牌化（Tokenization） ：用唯一令牌替换原敏感数据，原值存入映射库；令牌本身不携带原值信息，降低泄露面。

• 格式保留加密（FPE） ：加密后保持原有数据格式和长度，适合需要对长度敏感的场景。

答题落点：“拆分 + 令牌化 + 映射存储” 是超长敏感信息处理的三件套。

二、微服务与 DDD

5. 微服务的概念、优势与挑战

概念：将单体应用拆分为一组小型、独立部署的服务，服务之间通过轻量级通信机制交互。

核心优势：

• 独立部署：单个服务可独立发布，不影响其他服务；

• 技术异构：不同服务可用不同技术栈；

• 故障隔离：一个服务故障不必然导致全局崩溃；

• 弹性扩展：按服务粒度扩展，而非整体扩缩容；

• 团队自治：按业务能力组织小团队，加快迭代。

主要挑战：

• 分布式复杂性：网络调用、超时、重试、幂等、分布式事务；

• 服务拆分粒度：拆多大、按什么边界拆；

• 数据一致性：跨服务事务难以用本地事务解决；

• 运维成本：链路追踪、配置管理、服务发现、监控的复杂度显著上升。

6. 限界上下文

限界上下文是 DDD 战略设计的核心产物，定义领域模型的语义边界：在边界内，同一个术语（如“商品”）有唯一、明确的含义；超出边界，同一术语可以有完全不同的模型。

在微服务架构中，一个限界上下文通常对应一个微服务（或一组紧密相关的微服务） ，是服务拆分的自然边界。

答题关键词：“语义边界” + “模型一致性边界” + “微服务拆分候选边界” 。

三、架构风格

7. 解释器风格

核心：为特定领域定义一种“语言”（DSL/规则语法），并提供一个解释器来解析和执行该语言的语句。

优点：文法易扩展（新增语法只需增加解释器类）；规则可动态修改，业务人员可通过更新脚本/配置调整行为，可修改性强。

缺点：执行效率低（逐节点解释执行）；复杂文法难以维护；可利用场景相对有限。

适用场景：规则引擎（金融风控规则频繁调整）、脚本化功能、需要业务人员参与规则维护的系统。

8. 批处理 vs 管道-过滤器

• 批处理风格：将任务分解为一系列独立的处理步骤，每一步对整个数据集进行处理后再交给下一步。特点是整体处理、步骤间解耦，适合大数据离线计算、ETL。

• 管道-过滤器风格：每个过滤器独立处理数据流，通过管道连接。过滤器增量处理、可独立复用和重组；但不适合交互式应用，且过滤器之间的数据格式协商有成本。

两者共同点：都是顺序化处理、步骤间低耦合；区别在于批处理面向数据集、管道-过滤器面向数据流。

9. 前后端分离与 RESTful

前后端分离的核心：后端只提供数据接口（通常是 RESTful API），前端负责渲染和交互，双方以接口契约协作。

RESTful 设计要点：

• 用 URI 标识资源（名词复数，如 /users）；

• 用 HTTP 方法表达操作语义：GET 查询、POST 创建、PUT 更新、DELETE 删除；

• 无状态：每个请求携带完成该请求所需的全部信息；

• 通过 HTTP 状态码 + JSON 传输结果。

四、心跳、缓存与数据

10. Ping/Echo 与心跳

二者都是可用性的故障检测战术，但机制不同：

“从资源利用率角度解释心跳更适合的原因” ：心跳由被监控方主动发送，检测方只需被动监听，不需要为每个被监控对象维护主动探测的状态和定时器，在监控大量节点的场景下资源开销更低；而 ping/echo 需要检测方对每个目标发起请求，连接数和状态维护成本随目标数线性增长。

11. 旁路缓存（Cache Aside）的读写原理

读：先查缓存 → 命中直接返回 → 未命中查数据库 → 将结果写回缓存 → 返回。

写：先更新数据库 → 再删除缓存（不是更新缓存）。

为什么是删除而不是更新缓存：并发写场景下，两个写请求更新缓存的顺序可能与数据库更新顺序不一致，导致缓存中留下旧值；删除缓存让下一次读自然回源，降低不一致窗口。写多场景下频繁删除缓存会带来命中率下降，因此 Cache Aside 更适合读多写少。

12. 数据不一致的三种解决方案

答题时优先写 “先更新数据库，再删除缓存 + 延时双删/异步补偿” 这一组合。

13. Redis 主从复制：全量同步与增量同步

全量同步（首次同步或无法增量时）：

1. slave 发送 PSYNC；

2. master 返回 FULLRESYNC，生成 RDB 并发送；

3. 发送 RDB 期间的新写命令暂存于 replication buffer，RDB 发完后将 buffer 中的命令发给 slave。

增量同步（断线重连后）：

• 依赖 repl_backlog_buffer（环形缓冲区）；master 和 slave 分别记录写位置和读位置，重连后比较差距，差距在 backlog 范围内则只补发缺失部分。

• 若差距已被环形缓冲区覆盖，则退化为全量同步。

14. Redis 两种持久化方式

• RDB：某一时刻的快照，二进制紧凑、恢复快；但两次快照之间的数据可能丢失。

• AOF：追加写命令日志，可配置 appendfsync 策略（always / everysec / no）；数据更完整，但文件更大、恢复更慢，且需要重写（rewrite）压缩。

实际生产常用 RDB + AOF 混合持久化。

15. Redis zset 实现的命令与原理

zset（Sorted Set）是按 score 排序的唯一成员集合，底层常用跳表 + 哈希表：哈希表保证 O(1) 按成员查 score，跳表保证按 score 范围查询和排名的高效性。

典型命令：ZADD、ZRANGE、ZREVRANGE、ZRANGEBYSCORE、ZRANK、ZINCRBY、ZREM。

两大典型应用：

• 排行榜：score 作为分数/热度，ZREVRANGE 取 Top N；

• 延时队列：成员为任务，score 为执行时间戳，定时用 ZRANGEBYSCORE 0 当前时间戳 取出到期任务消费，消费成功后 ZREM。

16. MongoDB 空间矢量存储

MongoDB 通过 GeoJSON 对象 + 地理空间索引（2dsphere / 2d） 支持空间数据，可执行邻近查询、范围查询、包含查询。相比传统关系库，文档模型天然适合嵌套的坐标结构，水平扩展能力更强，适合位置服务、轨迹、地理围栏等场景。

17. HDFS 热、温、冷存储

HDFS 本身是统一存储层，但可按数据访问频率配合不同存储策略：

• 热数据：高频访问，放在高速介质（SSD/内存加速） ，副本数高；

• 温数据：中频访问，常规 HDD；

• 冷数据：极少访问，可放归档存储/纠删码，降低副本开销和存储成本。

核心逻辑：按访问频率分层，兼顾性能与成本。

五、可靠性与容错

18. 系统可靠性与软件可靠性的定义与提高技术

系统可靠性：系统在规定条件下、规定时间内完成规定功能的能力。提高手段包括冗余（硬件冗余、软件冗余、数据冗余）、故障检测与恢复、容错设计、降级运行等。

软件可靠性与系统可靠性的区别：软件可靠性更强调软件失效由设计缺陷触发，不存在“磨损”，但存在残留缺陷；系统可靠性涵盖硬件、软件、网络、环境等整体。提高软件可靠性的手段：形式化方法、严格测试、容错软件结构（N 版本、恢复块）、防御性编程。

19. 恢复块 vs N 版本程序设计

两者都是软件容错的经典结构：

共识恢复块（Consensus Recovery Block） 结合两者：多个版本运行 + 表决 + 恢复块机制，可靠性理论上优于单独使用任一方法。

六、分布式系统进阶

20. 分布式锁：死锁风险与类型

分布式锁的核心要求：互斥、不死锁、可重入（可选）、高可用。

死锁的典型来源：

• 加锁后客户端崩溃，且锁没有超时自动释放；

• SETNX 与 EXPIRE 非原子执行：加锁成功但设超时失败，锁永不释放。

避免死锁的关键手段：

• 使用 SET key value NX PX timeout 原子加锁 + 超时；

• 唯一 value（requestId） + Lua 脚本释放，防止误删他人锁；

• 超时续期（watchdog）应对业务执行超过锁租期。

分布式锁的主要类型：基于 Redis 的锁（性能高、模型相对简单）、基于 ZooKeeper 的锁（临时顺序节点 + Watch，一致性更强但部署成本高）、基于数据库的锁（唯一索引/乐观锁，简单但性能有限）。

21. 限界上下文的定义（已在第 6 条覆盖，不再重复）

22. 互斥锁、多粒度锁、乐观锁/悲观锁

• 互斥锁：同一时刻只允许一个持有者进入临界区，其他阻塞等待。

• 多粒度锁：在不同粒度层级上加锁（如数据库的行锁/页锁/表锁），在并发度和锁管理开销之间权衡。

• 悲观锁：假设冲突一定会发生，先加锁再操作（SELECT ... FOR UPDATE）。优点是一致性强；缺点是并发度低、可能死锁。

• 乐观锁：假设冲突较少，提交时通过版本号/CAS检测冲突，冲突则重试。优点是读不阻塞、并发度高；缺点是冲突频繁时重试成本高。

Redis 高并发控制场景的优化策略：用 Redis 做分布式锁/信号量/令牌桶限流，将并发控制在入口；对热点 key 用 分段锁/分片降低单点竞争；读多写少场景用乐观锁 + 重试，避免长期持锁。

23. 两种方案优缺点分析（分布式锁语境）

以 Redis 锁 vs ZooKeeper 锁 为典型：

• Redis：性能高、实现轻；但主从异步复制下，主节点宕机可能丢失锁信息，强一致模型较弱，需 RedLock 等算法弥补。

• ZooKeeper：临时顺序节点 + Watch，一致性和可靠性更强，天然避免死锁（会话断开节点自动删除）；但性能低于 Redis，运维和部署成本更高。

答题模板：“性能选 Redis，强一致选 ZK；实际业务按一致性要求和并发量权衡” 。

24. 冷启动与启动方式

冷启动：系统/应用没有任何预热状态时的启动——进程不存在、缓存为空、连接未建立。

冷启动的典型场景：

• 应用进程冷启动：后台无该应用进程，需创建进程、初始化组件；

• Serverless 函数冷启动：函数首次调用或间隔超过容器生命周期，需初始化运行环境。

启动方式分类（应用侧） ：冷启动、温启动、热启动。热启动时进程和大部分状态已存在，启动最快；冷启动最慢。

Serverless 冷启动缓解方式：预热池（预初始化沙箱）、预留并发、精简依赖包缩小初始化时间。

七、安全与风险

25. 风险驱动的安全分析 4 个步骤

安全分析应以风险为导向，典型步骤为：

1. 资产识别：确定需要保护的核心资产（数据、服务、接口）；

2. 威胁场景建模：分析资产面临的威胁和攻击路径；

3. 攻击可能性与影响评估：量化威胁被利用的可能性和后果等级；

4. 风险判定与缓解：确定风险等级，制定并验证缓解措施。

答题落点：“资产 → 威胁 → 可能性/影响 → 风险处置” ，顺序不可颠倒。

26. 形式化开发 vs 软件测试

• 形式化开发：用数学语言描述规约，通过定理证明/模型检验验证性质，能在早期发现设计级缺陷；但门槛高、成本大，难以覆盖全部系统。

• 软件测试：通过执行发现缺陷，直观、可落地；但只能证明“存在缺陷”，不能证明“不存在缺陷”，且受测试用例覆盖度限制。

二者是互补关系：形式化保证关键性质，测试提供工程可验证的兜底。

八、新兴架构与智能化

27. 端侧 AI vs 云端 AI

端侧 AI：模型部署在终端设备本地推理，不依赖云端往返。

端侧相较于云端的三项核心优势：

1. 低延迟/离线可用：本地推理响应可到几十毫秒级，无网络也可工作；

2. 隐私安全：数据不出端，减少传输和第三方服务器暴露面；

3. 成本与带宽：无需持续上传数据，高频调用时边际成本低。

局限：模型容量受终端算力/功耗限制，复杂推理能力弱于云端；模型更新不如云端灵活；本地设备被攻破同样存在风险。

结论：主流方向是端云协同——高频轻量任务端侧，复杂任务云端。

28. 典型智能化功能（5 个以上）

可作为答题素材的典型智能化功能：

• 智能推荐（个性化内容/商品）

• 语音识别与实时翻译

• 图像识别/智能修复

• 异常检测与智能告警

• 智能客服/对话式交互

• 预测性维护

• 路径规划与调度优化

29. 智能化四层架构：感知层、边缘层、AI 决策层、应用层

• 感知层：传感器、RFID、终端设备，负责采集物理世界数据；

• 边缘层：靠近数据源的计算节点，负责实时预处理、过滤、轻量推理，降低回传带宽和时延；

• AI 决策层：模型推理/训练/决策引擎，承担复杂分析、预测和策略生成；

• 应用层：面向最终业务场景（智能家居、智慧城市、工业监控等），消费下层结果。

四层架构的缺点：层级增多带来端到端时延叠加；跨层运维和故障定位复杂；边缘层与云端之间的数据/模型同步成本高；对标准化接口依赖强，异构设备接入难度大。

30. 学习路径推荐与前置依赖

核心是有向无环图（DAG）+ 拓扑排序：将知识点/课程视为节点，前置依赖视为有向边，拓扑排序给出满足所有依赖关系的学习顺序；若存在环，需先检测并打破循环依赖。

典型算法：Kahn 算法（入度法）或 DFS 拓扑排序；环检测用 DFS 或入度不为零判定。

31. 知识图谱概念

知识图谱是结构化的语义知识库，以 “实体—关系—实体”三元组为基本单元，也可用“实体—属性—属性值”表示，形成网状知识结构。

两层架构：

• 数据层：存储事实三元组；

• 模式层（本体层） ：定义概念、关系类型和约束，是知识图谱的逻辑基础。

32. 智能化功能与“轻量级内核”

“轻量级内核”在边缘/端侧智能化语境中，指只保留完成核心推理/决策所需的最小运行时和模型组件，去除不必要的框架依赖，以降低资源占用、加快启动。特点是可裁剪、低依赖、启动快、资源占用小，便于在算力受限的边缘设备上部署。

九、通信、建模与数据管理

33. MQTT 协议

概念：轻量级发布/订阅消息协议，基于 TCP，专为低带宽、高延迟、不可靠网络中的 IoT 设备设计。

核心组成：

• Publisher（发布者）、Subscriber（订阅者）、Broker（代理）；

• Topic（主题）：发布/订阅的匹配依据，支持通配符 + / #；

• QoS 等级：0（最多一次）、1（至少一次）、2（恰好一次）。

优势：报文头小、开销低；发布/订阅解耦生产者和消费者；适合海量设备上行数据。

34. 时序数据库

概念：专门为时间序列数据（按时间顺序产生、带时间戳的数值流）优化的数据库。

核心特点：时间戳索引、高写入吞吐、按时间范围的高效聚合查询、降采样/保留策略、列式压缩存储。典型场景：监控指标、IoT 传感器数据、金融行情。

35. Petri 网

Petri 网是三元组 PN=(P,T,F)PN=(P,T,F)：PP 为库所（place），TT 为变迁（transition），FF 为流关系（弧）。

关键矩阵：

• 关联矩阵（Incidence Matrix） ：行对应库所、列对应变迁，元素表示变迁对库所的输入/输出权重；

• 初始标识 M0M0​：各库所中的托肯（token）分布。

基本性质：可达性（从 M0M0​ 经过变迁序列能到达哪些标识）、有界性/安全性（库所托肯数不超过界）、活性（变迁是否可能被激发）。在架构分析中，Petri 网可用于对并发、同步、资源竞争进行形式化建模和验证。

36. 数据库类型与推荐技术

选型核心维度：一致性要求、数据模型、查询模式、扩展方式、运维成本。

37. 对比 ES Simple、Whitespace、Keyword 分词

三者是 Elasticsearch 的内置分词器/分析器：

• Whitespace：仅按空白字符（空格、制表符、换行）切分，不处理标点，不移除任何字符，不做小写化；

• Simple：按非字母字符切分，并转小写，但不像 Standard 那样做复杂的 Unicode 处理；

• Keyword：不分词，将整个输入作为一个 token，常用于精确值字段（ID、标签、枚举）。

38. UML 时序图的消息类型及概念

• 同步消息：发送方发出后等待接收方返回，用实线实心箭头表示，对应“调用—返回”阻塞语义。

• 异步消息：发送方发出后不等待返回，用实线开放箭头表示，适合事件通知、消息队列。

• 返回消息：接收方处理完后返回结果，用虚线开放箭头表示。

• 自调用消息：对象调用自身方法，箭头指向自己。

• 创建/销毁消息：创建对象用指向对象框的箭头，销毁用对象框上的 X。

• 答题落点：同步=阻塞等待，异步=非阻塞通知，返回=虚线，生命线激活期表示对象执行期。

39. 时序图与协作图的选取原则

• 时序图：强调消息按时间顺序的交互过程，适合表达“先做什么、后做什么”、流程时序、条件分支。

• 协作图（通信图）：强调对象之间的结构关系和连接，适合表达“谁和谁通信、通过什么链连接”，弱化时间顺序。

• 选取原则：关注流程顺序选时序图；关注对象拓扑/协作关系选协作图；两者语义可互换，但侧重点不同。

40. UML 时序图中的条件分支片段

• alt：条件分支，相当于 if/else，可有多条互斥路径。

• opt：可选片段，条件成立才执行，相当于 if 无 else。

• loop：循环片段。

• par：并行片段。

• break：中断片段。

• critical：临界区片段。

• neg/assert：否定/断言片段。

• 填空常考：条件分支用 alt，可选分支用 opt，循环用 loop，并行用 par。

41. ROS 的定义和特点

ROS 是机器人操作系统，本质是分布式通信中间件 + 工具链 + 软件包生态，不是传统操作系统内核。特点：

• 分布式节点架构：节点之间松耦合通信；

• 发布/订阅、服务、动作等通信模型；

• 语言无关、可复用：C++/Python 等；

• 工具丰富：rviz、gazebo、rosbag、rqt；

• 社区生态大，但 ROS1 存在实时性、安全性、单 master 等局限。

42. ROS2 与 ROS1 的改进

• 去中心化：ROS2 取消单 Master，基于 DDS 发现机制，节点自动发现；

• 实时性增强：支持实时通信、QoS 策略；

• 多平台/嵌入式：更好支持 Windows、RTOS、微控制器；

• 安全性：支持加密、认证、访问控制；

• 通信可靠性：QoS 可配置可靠/尽力而为、历史深度、寿命等；

• 生命周期管理：节点生命周期状态机；

• 生产级：更适合多机器人、工业场景。

43. ROS 的通信机制名称填空

ROS1 常见通信机制：

• Topic（话题）：发布/订阅，异步、多对多；

• Service（服务）：请求/响应，同步、一对一；

• Parameter Server（参数服务器）：全局参数存储；

• Action（动作）：长耗时任务，带反馈和取消。

ROS2 常见：

• Topic、Service、Action、Parameter，底层由 DDS 支撑；另有 Node、Executor、QoS 等概念。

44. ROS2 架构每一层含义

常见分层：

• 应用层：用户节点、业务功能包；

• 客户端库层：rclcpp/rclpy，提供 ROS 编程接口；

• 中间件抽象层（RMW） ：统一不同 DDS 实现的接口；

• DDS 层：数据分发服务，负责发现、序列化、QoS、通信；

• 操作系统/硬件层：Linux/RTOS、传感器和执行器。
  答题落点：应用→客户端库→RMW→DDS→OS/硬件，核心是“RMW 屏蔽 DDS 差异”。

45. Scrapy 框架与“异步 IO”

Scrapy 组件：引擎、调度器、下载器、爬虫（Spider）、Item Pipeline、下载器中间件、爬虫中间件。

数据流：引擎从调度器取请求 → 下载器中间件 → 下载器 → 响应 → 爬虫解析 → 产出 Item/新请求 → Pipeline 处理 Item、调度器排队新请求。

异步 IO：单线程事件循环下，发起 I/O 后不阻塞等待，而是注册回调/协程，I/O 完成后再继续处理；核心是非阻塞 + 事件循环 + 回调/协程。Scrapy 基于 Twisted 异步网络库，因此能在一个进程内并发处理大量请求，避免“一个请求阻塞整个爬虫”。

46. 区块链技术的六个层次及功能

47. 智能合约包含哪三方面

按常见答题口径：

1. 合约条款/业务逻辑：参与方、规则、条件数字化；

2. 状态数据：合约账户状态、变量、账本数据；

3. 触发条件与执行动作：满足条件后自动执行的规则和结果。
   可简记为：业务规则 + 状态数据 + 自动触发执行。

48. 三角色在业务流程中的操作步骤和职责

通用答题框架：先识别三个角色，再按“输入—操作—输出—职责”列。
常见三角色模板：

• 数据/资产提供方：提交数据或交易，保证真实性；

• 平台/共识节点方：验证、打包、共识、上链，维护账本；

• 使用方/监管方：查询、审计、授权使用，保证合规。
  步骤：身份注册/认证 → 提交请求 → 验证与共识 → 执行/记录 → 查询/审计。若题干给的是具体业务，把角色名替换为题干术语即可。

49. “三种资源选架构”的典型适用场景

若题干指资源调度架构，常见三种：

• 集中式调度：单调度器统一决策，适合小规模、策略简单、易管理的集群；

• 两级调度：资源管理层 + 框架调度器，适合多计算框架共享集群（如 YARN/Mesos）；

• 共享状态调度：多个调度器共享集群状态，适合高并发、低延迟、大规模场景（如 Omega）。
  若题干指“选型架构”，则按单体、SOA、微服务的适用场景答：小团队快速交付选单体；企业集成选 SOA；高并发、独立部署选微服务。答题时先看题干关键词。

50. 多粒度锁填空：意向锁与层次锁

• 多粒度锁：在行、页、表等不同粒度上加锁，减少锁数量、提高并发。

• 意向锁：对下层节点加锁前，先在上层加“意向锁”，表明“下层将被加锁”。常见：

  • IS：意向共享锁；

  • IX：意向排他锁；

  • SIX：共享 + 意向排他。

• 锁升级/降级：低粒度锁过多时升级为高粒度锁，反之降级。

• 填空关键词：先加意向锁、再对目标节点加锁；S/X/IS/IX/SIX；粒度越细并发越高、管理开销越大。

51. 互斥锁填空补充

• 互斥锁保证同一时刻只有一个线程进入临界区；

• 实现依赖原子操作（CAS/TestAndSet）；

• 分为自旋锁（忙等）和阻塞锁（睡眠唤醒）；

• 可扩展：可重入锁、公平锁/非公平锁、读写锁；

• 风险：死锁、优先级反转、锁粒度过大导致并发下降。

52. 悲观锁“按行为分类”的设计方案

• 按行为分为 共享锁 S（读锁） 和 排他锁 X（写锁）；

• 读操作加 S 锁，多个读可并发；写操作加 X 锁，与任何锁互斥；

• 设计方案：事务开始时按需加锁，读用 SELECT ... LOCK IN SHARE MODE，写用 SELECT ... FOR UPDATE；按固定顺序加锁避免死锁；设置锁等待超时；尽量缩短持锁时间。

53. 完成 Petri 网模型

步骤：

1. 将状态/条件映射为库所 P；

2. 将动作/事件映射为变迁 T；

3. 将输入输出关系映射为弧 F；

4. 给出初始托肯分布 M0；

5. 检查可达性、有界性、活性，必要时调整。
   答题落点：P 表状态、T 表动作、F 表流转、M0 表初始资源。

54. Petri 网关键矩阵分析

• 关联矩阵 C：行对应库所、列对应变迁，元素为输入/输出权重差；

• 状态方程：M=M0+C⋅xM=M0​+C⋅x，x 为各变迁激发次数向量；

• S 不变量：满足 CTy=0CTy=0，表示托肯守恒/资源约束；

• T 不变量：满足 Cx=0Cx=0，表示可回到初始状态的变迁序列；

• 可达树/可达图：分析从 M0 可达的标识、死锁、活性。
  填空常考：关联矩阵、初始标识、状态方程、S/T 不变量、可达性。

55. 软件可靠性与硬件可靠性的差异

原表“软件可靠性与软件可靠性”应为笔误，常考软/硬件对比：

• 硬件有物理磨损，失效率呈浴盆曲线；软件无磨损，失效由设计缺陷/残留缺陷触发；

• 硬件可用冗余替换提高可靠性；软件冗余需独立版本/恢复块，且要保证故障独立性；

• 软件可靠性更依赖需求、设计、测试、形式化验证；硬件更依赖老化筛选、冗余、容错。

56. “系统架构图填空”答题方法

1. 先识别架构风格：分层、微服务、事件驱动、Lambda/Kappa、IoT 四层、区块链六层、ROS2 分层；

2. 找组件：网关、服务、数据库、消息队列、缓存、注册中心、监控；

3. 找连接件：HTTP/RPC、消息主题、数据流箭头、同步/异步；

4. 按题干术语填，注意箭头方向、层次边界、数据存储位置；

5. 不确定时优先填题干已出现的名词，不要自造组件。

57. “根据题干构件类型”答题方法

构件类型常见分法：

• 处理构件：负责计算/业务逻辑；

• 数据构件：负责存储/数据访问；

• 连接构件：负责通信/适配/消息传递。
  答题：从题干找“谁处理、谁存储、谁连接”，填构件名 + 职责；若考架构风格，则填该风格的构件/连接件/配置，如管道-过滤器的“过滤器/管道”、事件驱动的“事件生产者/消费者/事件总线”。

58. “根据题干填写业务内容”答题方法

按 角色 → 输入 → 处理步骤 → 输出 → 规则/约束 提取；用题干原词；按流程顺序写；不编造题干未给信息；遇到“职责”就写“负责什么 + 对谁负责 + 产出什么”。

59. “两种方案优缺点分析”通用模板

按维度对比：一致性、性能、复杂度、可用性、扩展性、运维成本、适用场景。先列方案 A/B，再逐维写优劣，最后给选型建议。若上下文是分布式锁，套 Redis vs ZooKeeper；若是数据一致性，套延时双删 vs 异步补偿 vs 分布式锁。

60. Redis 高并发控制场景的优化策略（补强）

热点 key 分片、读写分离、连接池、Pipeline 批量、Lua 保证原子、限流降级、异步削峰、锁粒度细化、避免大 key/热 key、缓存预热、多级缓存。

61. 学习路径推荐算法（补强）

将知识点建 DAG，前置依赖为有向边；用拓扑排序给出满足依赖的学习顺序；若有权重，可按掌握度、难度、收益做个性化排序；先用 DFS/入度法做环检测，有环则先拆环。

62. 冷启动与启动方式（补强）

• 冷启动：无进程、无缓存、无连接，需完整初始化；

• 温启动：部分状态已存在，仍需部分初始化；

• 热启动：进程和状态基本就绪，最快；

• Serverless 冷启动：函数实例未就绪，需创建运行环境；缓解：预热池、预留并发、精简依赖包、减小镜像。

63. MQTT 补强

• QoS0：最多一次，可能丢；QoS1：至少一次，可能重复；QoS2：恰好一次；

• 保留消息：Broker 保存主题最后一条消息，新订阅者立即收到；

• 遗嘱消息：客户端异常断开时由 Broker 发布；

• 主题通配符：+ 单层、# 多层；

• 核心角色：Publisher、Subscriber、Broker。

64. 时序数据库补强

时间戳索引、列式压缩、高写入吞吐、按时间范围聚合、降采样、保留策略、连续查询；适合监控指标、IoT 传感器、金融行情。

65. 知识图谱补强

核心是 实体—关系—实体三元组；分数据层和模式层/本体层；存储常用图数据库；构建流程：信息抽取 → 知识融合 → 知识加工 → 存储查询。

66. 数据库类型与推荐技术实践补强

选型按：一致性要求、数据模型、查询模式、扩展方式、运维成本。强事务选关系型；灵活 schema 选文档型；海量写入选列族；低延迟缓存选键值；关系遍历选图数据库。

67. 质量属性效用树填空模板

根节点“效用”→ 质量属性（性能/可用性/安全性/可修改性等）→ 细分场景 → 叶节点标 （重要性 H/M/L，实现难度 H/M/L）。填空先看题干场景属于哪个质量属性，再填子属性和场景描述。

68. 敏感点/权衡点/风险点判定流程

先看题干描述影响一个还是多个质量属性：只影响一个是敏感点；影响多个且对多个都敏感是权衡点；不确定/未达成共识是风险点；有依据可控是非风险点。

69. 端侧 AI 的局限（补强）

算力/功耗/存储受限，模型容量小；复杂推理弱于云端；模型更新和运维不如云端灵活；终端被攻破仍有隐私风险。结论：端云协同。

70. 四层 IoT 架构缺点补强

端到端时延叠加、跨层运维和故障定位复杂、边缘与云端数据/模型同步成本高、异构设备标准化接入难、边缘节点安全防护弱。