顶级临阵磨枪（软考高级系统架构-0）

前趋图（Precedence Graph）

前趋图（Precedence Graph）是一种用于描述任务、事件或进程之间先后依赖关系的有向无环图（Directed Acyclic Graph，DAG）。

通常记作：

G = (P, E)

其中：

• P：顶点集合（Vertex Set），表示进程、任务或事件
• E：边集合（Edge Set），表示前驱约束关系

边一般表示为：

E = {(p_i, p_j)}

表示进程 p_i 必须先执行完成，进程 p_j 才能开始执行，即：

p_i ➡️ p_j

由于前趋图只描述“先后依赖关系”，因此图中不能出现环路，所以它属于有向无环图（DAG）。

在实际分析中，本质上就是按照“节点大小关系 + 箭头方向”记录每一条边的依赖关系。

PV 操作（Semaphore Operations）

PV 操作是操作系统中用于实现进程同步与互斥的一种经典机制，其核心是信号量（Semaphore）。

信号量通常记作：

S_i

其中：

• S：Semaphore（信号量）
• 下标 i：表示第 i 个信号量

PV 操作包括两种基本原语：

P 操作（Proberen）

P 操作来源于荷兰语 “Proberen”，含义为“测试”或“申请资源”。

执行逻辑：

• 对信号量 S 减 1
• 若结果小于 0，则当前进程阻塞等待
• 若结果大于等于 0，则继续执行

因此：

• 执行前需要进行 P 操作
• 表示“申请资源”或“进入临界区”

常写作：

P(S_i)

V 操作（Verhogen）

V 操作来源于荷兰语 “Verhogen”，含义为“增加”或“释放资源”。

执行逻辑：

• 对信号量 S 加 1
• 若有等待进程，则唤醒其中一个

因此：

• 执行完成后进行 V 操作
• 表示“释放资源”或“退出临界区”

常写作：

V(S_i)

PV 操作与前趋图的关系

例如：

p_1 到 p_2

可表示为：

• p_1 执行结束后执行 V(S)
• p_2 执行前先执行 P(S)

磁盘调度

最短移臂调度算法（SSTF，Shortest Seek Time First）

找最近柱面号，同柱面下，扇区号小的优先

切换磁头代价较小

页存储逻辑地址和物理地址转换

假设逻辑地址十六进制 5148H 进程 P四个存储块，页面大小 4K，页号 0~7，页号 5 的页帧号 3 怎么换算出物理地址 3148H

页面大小 4K = 4 \times 1024 = 4096 = 2^{12}

• 页内偏移量占 12 位
• 高位是页号 5 查页表是 3

如果访问页面 6 不在内存 看状态位，在内存的，淘汰没被访问的，都被访问淘汰没被修改的

文件索引

某文件系统文件存储采用文件索引节点法假设磁盘索引块和磁盘数据块大小均为 1 KB, 每个文件的索引节点中有 8 个地址项，07，每个地址项大小为 4B，其中 05 为直接索引，6是一级间接，七7二级间接，那么我们要访问的这个文件的逻辑块号分别为 0，260 和 518，则系统应分别采用什么索引，其文件系统可表示的文件最大长度为多少 KB

块大小 1KB，地址项 4B，所以一个索引块能放： 1024 / 4 = 256 个地址。

0~5：直接索引，共 6 块
6：一级间接索引，可表示 256 块
7：二级间接索引，可表示 256 × 256 = 65536 块

先算一个索引块能放多少地址项：块大小 / 地址项大小。
然后按“直接块数、一级间接块数、二级间接块数”分段判断逻辑块号。

应用层协议

存储网络架构

DAS，单机存储架构 NAS，网络存储架构 SAN，网络存储架构

信息安全基础知识

机密性、完整性、可用性、可控性、可审查性

安全范围：

设备安全：物质基础。 数据安全：防止未授权的泄露，篡改和毁坏 内容安全：政治法律道德层次上的要求 行为安全：通过行为提供给用户，确保行为安全。

信息安全风险类别

人为： 被动 主动 灾害性 系统故障 人员无意识行为

加密技术

• DES 太短不安全 64 位，56 位密钥，8 位校验
• 3DES 三次更安全但更慢 112 或 168 位密钥长度
• AES 又快又安全，是现代主流
• RSA 512 位

补充记忆：

HTTPS 中通常：

• 非对称加密用于“交换会话密钥”
• 对称加密用于“实际数据传输”

消息摘要

例：哈希算法 常用算法，MD5，SHA-256

数字签名

发送者私钥加密

数字证书

CA = Certificate Authority

安全模型

常见口诀：

数据库体系结构

简单理解：

核心作用：

口诀：

• 外模式：用户看到什么
• 概念模式：数据库整体长什么样
• 内模式：数据实际上怎么存

数据模型

进一步理解：

常见概念：

概念数据模型

核心元素：

• 实体（Entity）
• 属性（Attribute）
• 联系（Relationship）

典型表示：

E-R 图。

基本数据模型

常见类型：

口诀：

• 概念模型：面向现实世界
• 基本模型：面向数据库实现
• E-R 属于概念模型
• 关系模型属于基本模型

关系代数运算

常见分类：

简单理解：

口诀：

• 选择选“行”
• 投影选“列”
• 连接拼“表”
• 并差交做“集合运算”

云原生架构

大数据设计架构

Lambda 架构（Lambda Architecture）

是一种“大数据实时处理架构”。

它的核心目标是：

同时兼顾：

• 实时性
• 准确性
• 海量数据处理能力

最早由 Nathan Marz 提出。

Lambda 架构的核心思想：

同一份数据：

• 一边走“实时计算”
• 一边走“离线批处理”

最后把两边结果合并。

经典结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

                数据流
                   │
        ┌──────────┴──────────┐
        │                     │
        ▼                     ▼

   Speed Layer          Batch Layer
   （实时层）              （离线层）

        │                     │
        ▼                     ▼

   实时结果              精确结果

        └──────────┬──────────┘
                   ▼

             Serving Layer
              （服务层）

它由三层组成。

1. Batch Layer（批处理层）

负责：

• 存储全量历史数据
• 做高准确性离线计算

特点：

• 慢
• 但结果最准确

典型技术：

例如：

1
2
3
4
5

每天凌晨重新统计：
- 用户画像
- 推荐模型
- 全站订单
- 风险评分

2. Speed Layer（实时层）

负责：

• 处理最新数据
• 提供低延迟结果

特点：

• 快
• 但可能不完全准确

因为：

• 数据可能不完整
• 窗口未闭合
• 有乱序问题

典型技术：

例如：

1
2
3
4
5

用户刚下单后：
立即更新：
- 实时销量
- 热搜榜
- 风控告警

而不是等第二天。

3. Serving Layer（服务层）

负责：

• 合并批处理结果
• 合并实时结果
• 对外提供查询

例如：

1
2
3
4

最终销量 =
历史离线统计
+
最近5分钟实时增量

为什么需要 Lambda 架构

因为：

早期大数据系统存在矛盾：

于是：

1
2

实时层负责“快”
离线层负责“准”

两边结合。

举个电商例子

假设淘宝统计：

1

今日商品销量排行榜

实时层：

1
2

用户下单后
1 秒内更新排行榜

但：

• 有重复消息
• 有退款
• 有延迟订单

所以结果不一定准。

离线层：

1

凌晨重新跑全量订单

得到准确结果。

最终：

1

实时增量 + 离线校正

Lambda 架构的问题

后来大家发现：

它太复杂。

因为：

你要维护：

1

两套计算逻辑

即：

• 实时计算代码
• 离线计算代码

容易：

• 逻辑不一致
• 运维复杂
• 开发成本高

所以后来出现 Kappa 架构

由 Jay Kreps 提出。

核心思想：

1

只保留流处理

即：

1

所有数据都是流

历史数据也可以重新回放。

结构变成：

1
2
3
4
5

Kafka
   ↓
Flink
   ↓
Serving

不用：

• Batch Layer
• 双代码

所以现代云原生实时系统：

很多已经：

1

Lambda → Kappa

二者对比

现在比较常见的现实情况是：

一句话总结：

Lambda 架构本质是：

1

“实时流处理 + 离线批处理”双轨并行

用：

1
2

实时层保证速度
离线层保证准确性

Kappa 架构

该架构的核心思想其实非常“Kafka 化”：

1
2
3

所有数据都是事件流
所有计算都基于流
历史数据靠回放解决

它不再区分：

• “离线数据”
• “实时数据”

而是统一：

1

事件日志（Event Log）

先看一个最典型的 Kappa 例子。

例子 1：电商实时订单系统

假设：

用户下单。

系统产生事件：

1
2
3
4
5
6

{
  "event": "order_created",
  "order_id": "1001",
  "user_id": "u88",
  "amount": 399
}

这些事件进入：

Apache Kafka

然后：

Apache Flink

持续消费：

1
2
3
4
5
6
7
8

Kafka
  ↓
Flink
  ↓
实时销量统计
实时GMV
实时推荐
实时风控

此时：

你的网站已经能：

• 实时排行榜
• 实时销售额
• 秒级监控
• 实时推荐

那问题来了：

如果：

1

统计逻辑写错了

怎么办？

Lambda 的做法：

1

重新跑离线 Batch

Kappa 的做法：

1

回放 Kafka 历史数据

例如：

1

从 offset=0 重新消费

重新计算。

这就是：

1

流式重算

所以 Kappa 的关键前提是：

1

消息流必须可长期保存

Kafka 天然适合。

例子 2：实时风控系统

这是 Kappa 非常适合的场景。

例如：

信用卡风控。

每次交易：

1
2
3
4
5
6

{
  "user": "u100",
  "ip": "x.x.x.x",
  "country": "RU",
  "amount": 8000
}

进入 Kafka。

Flink 实时处理：

1
2
3
4

- 是否异地登录
- 是否异常金额
- 是否高频交易
- 是否设备切换

然后：

1

实时拦截

这里：

1

低延迟 > 强一致

所以：

Kappa 很适合。

例子 3：IoT / 工业监控

例如：

设备持续上传：

1
2
3
4
5

温度
振动
电流
压力
转速

全部进入 Kafka。

Flink 持续计算：

1
2
3
4

最近5分钟平均振动
异常波动检测
设备健康评分
预测性故障

如果：

后面：

1

异常算法升级了

怎么办？

Kappa：

1

重新回放历史传感器流

重新生成结果。

这其实比 Lambda 更自然。

因为工业场景：

本来就是：

1

无限事件流

Kappa 为什么越来越流行

因为现代系统：

越来越“事件驱动”。

例如：

• Kafka
• Pulsar
• Redpanda
• EventBridge
• CDC
• Debezium

本质都在：

1

Everything is a stream

Kappa 能完全替代 Lambda 吗？

答案：

1

不能完全替代

但：

1

很多互联网实时业务已经偏向 Kappa

原因在于：

Kappa 有自己的限制。

Kappa 的几个核心问题

1. 回放成本巨大

假设：

1
2

每天 100TB 日志
保留 180 天

你要重算：

1

18 PB 数据

这非常恐怖。

Lambda：

1

离线批处理更适合超大规模重算

尤其：

• PB级
• 年级别
• 全量统计

2. Kafka 不是无限存储

理论上能长保留。

实际上：

成本极高。

所以：

很多公司：

1

Kafka 保存 3~7 天

历史数据进：

• HDFS
• S3
• Iceberg
• Hudi
• Delta Lake

这时候：

纯 Kappa 就不成立了。

3. 流处理不擅长复杂历史分析

例如：

1
2
3
4
5

统计：
过去3年
全国
所有用户
消费分布

这种：

OLAP / 数仓分析。

批处理更强。

4. AI / 机器学习训练

很多训练：

需要：

1

全量历史数据

例如：

• 特征工程
• embedding
• 离线训练
• 数据清洗

这类：

还是：

1

Batch 更适合

所以现代架构其实变成了：

流批一体（Streaming + Batch Unified）

代表：

现在很多公司的真实架构：

1
2
3
4
5

Kafka
   ↓
Flink 实时计算
   ↓
实时服务

同时：

1
2
3
4
5

Kafka CDC
   ↓
Iceberg / Hudi
   ↓
离线分析 / AI训练

也就是说：

1

实时与离线共享同一份数据源

这其实已经：

既不是纯 Lambda。

也不是纯 Kappa。

而是：

1

Lakehouse + Streaming

你可以这样理解三代演进：

一句话总结：

Kappa 的核心优势：

1
2

一套流处理逻辑
通过事件回放解决历史重算

它非常适合：

• 实时业务
• IoT
• 风控
• 推荐系统
• 实时监控

但：

1
2
3
4

超大规模历史分析
AI训练
长期归档
复杂OLAP

目前仍离不开 Batch。

SOAP协议是什么

SOAP（Simple Object Access Protocol）

面向服务架构

进一步理解：

ESB 负责：

• 消息转发
• 协议转换
• 数据格式转换
• 服务路由
• 服务编排

常见对比：

口诀：

• 注册表解决“服务在哪”
• ESB 解决“系统怎么连”

微服务

能拆就拆 独立，技术选型灵活 松耦合、易扩展

挑战

分布式、数据一致性、测试难度、监控管理分发扩容问题

数据库设计

redis

redis持久化方案

核心区别：

RDB（快照）

原理：

某一时刻把整个内存数据：

直接保存成二进制快照文件。

生成文件：

1

dump.rdb

常见触发方式：

1
2
3

save 900 1
save 300 10
save 60 10000

表示：

• 900 秒内至少 1 次修改
• 就执行快照

特点：

• 类似“拍照片”
• 保存的是某时刻完整数据

可能丢失：

最后一次快照之后的数据。

AOF（追加日志）

原理：

把所有写命令：

追加记录到日志文件。

例如：

1
2
3

SET name ray
INCR count
LPUSH msg hello

恢复时：

重新执行命令。

生成文件：

1

appendonly.aof

AOF 三种刷盘策略：

默认：

1

appendfsync everysec

最多丢失约 1 秒数据。

混合持久化

Redis 4.0 后支持。

核心思想：

• 前半部分用 RDB 快照
• 后半部分追加 AOF 日志

这样：

• 启动恢复更快
• 数据也更安全

属于目前推荐方案。

一句话记忆

口诀：

• RDB 快但可能丢数据
• AOF 安全但更重
• 混合持久化最均衡