软考
在游戏中攻打此考点云原生 + 大数据 + AI + 区块链深化
Docker/K8s 全组件 + IaaS-PaaS-SaaS + Serverless + Hadoop/Spark/Flink + 数据湖/湖仓一体 + NoSQL + CAP-BASE-Paxos-Raft + DevOps + AI/ML/DL + 区块链 + 秒杀
一句话定位：2024-2025 真题”新技术”占比 ~15%，Serverless / 湖仓一体 / 秒杀高并发已成论文新主战场。本篇把云原生、大数据、AI、区块链全部讲透到”可写论文”。
IMPORTANT
复习策略
本篇是 05-new-tech-web-arch.mdx 的”硬核深化版”。事实据教材第 2 版 + 2020-2025 真题核对（2026-07-29）。
A. 容器技术 Docker
A1 容器 vs 虚拟机对比
| 维度 | 虚拟机 VM | 容器 Container |
|---|---|---|
| 隔离级别 | 硬件级（Hypervisor） | 操作系统级（Namespace） |
| 启动速度 | 分钟级 | 秒级/毫秒级 |
| 资源开销 | 大（每 VM 含完整 OS） | 小（共享宿主内核） |
| 镜像大小 | GB 级 | MB 级 |
| 密度 | 单机几个 | 单机几十上百 |
| 隔离性 | 强 | 弱（共享内核） |
| 安全 | 强 | 相对弱 |
| 典型 | VMware / KVM / Hyper-V | Docker / containerd |
A2 Linux 内核支撑
| 技术 | 作用 |
|---|---|
| Namespace | 隔离视图（PID / NET / MNT / IPC / UTS / USER） |
| Cgroup | 资源限制（CPU / 内存 / IO） |
| UnionFS | 镜像分层（OverlayFS / AUFS） |
A3 Dockerfile 常用指令
| 指令 | 说明 | 真题点 |
|---|---|---|
| FROM | 基础镜像 | 第一条非注释指令 |
| RUN | 构建时执行（创建层） | 多条用 && 合并减少层 |
| COPY | 拷贝本地文件 | 推荐 |
| ADD | 拷贝 + 自动解压 / 远程 URL | 不推荐（行为不可预期） |
| CMD | 容器默认启动命令 | 可被 docker run 参数覆盖 |
| ENTRYPOINT | 入口命令 | 不易覆盖；与 CMD 配合 |
| ENV | 环境变量 | |
| EXPOSE | 声明端口 | 仅声明，需 -p 映射 |
| VOLUME | 声明挂载点 |
NOTE
- CMD 易被覆盖：
docker run image bash会覆盖 CMD - ENTRYPOINT 不易覆盖：参数会作为 ENTRYPOINT 的参数
- 最佳实践：ENTRYPOINT + CMD（CMD 作默认参数）
A4 多阶段构建
# 阶段 1：构建
FROM maven:3.8-openjdk-17 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests
# 阶段 2：运行
FROM openjdk:17-slim
COPY --from=builder /app/target/app.jar /app.jar
ENTRYPOINT ["java","-jar","/app.jar"]
- 优势：最终镜像不含构建工具，体积小、攻击面小
A5 真题举一反三
IMPORTANT
2024-05 综合：以下 Dockerfile 指令哪个会创建新镜像层 RUN 会创建新层；COPY/ADD 也会创建层；CMD/ENV/EXPOSE 只修改镜像元数据不创建层。
NOTE
2023-11 案例：容器 vs 虚拟机 答：①共享内核vs独立内核 ②秒级vs分钟级启动 ③单机密度高 ④隔离性弱于VM ⑤适合微服务部署。
B. Kubernetes 全组件（必考 1~2 题）
B1 K8s 架构总览
B2 控制面 Master 组件
| 组件 | 作用 | 真题点 |
|---|---|---|
| kube-apiserver | 所有操作的统一入口（REST API） | 唯一与 etcd 通信的组件 |
| etcd | 分布式 KV 存储（集群状态） | Raft 一致性；V3 gRPC |
| kube-scheduler | Pod 调度到合适节点 | 资源 + 亲和 + 污点容忍 |
| kube-controller-manager | 运行控制器（副本/节点/端点） | 闭环控制 |
| cloud-controller-manager | 云厂商特定逻辑（LB/路由） | 树外组件 |
B3 工作节点 Node 组件
| 组件 | 作用 |
|---|---|
| kubelet | 与 apiserver 通信，管理 Pod 生命周期，上报状态 |
| kube-proxy | Service 网络代理（iptables / IPVS 模式） |
| 容器运行时 | containerd / CRI-O（已废弃 dockershim） |
B4 核心对象对比表
| 对象 | 作用 | 关键字段 |
|---|---|---|
| Pod | 最小调度单位，多容器共享网络/存储 | containers, volumes |
| Deployment | 无状态应用 + 副本控制 + 滚动更新 | replicas, strategy |
| StatefulSet | 有状态（稳定网络标识 + 持久存储） | serviceName, volumeClaimTemplates |
| DaemonSet | 每个节点一个（日志采集 / 监控 Agent） | nodeSelector |
| Job / CronJob | 批处理 / 定时任务 | completions, schedule |
| Service | 4 种类型（ClusterIP / NodePort / LB / ExternalName） | type, ports |
| Ingress | 7 层路由（HTTP/HTTPS，Nginx/Traefik） | rules, tls |
| ConfigMap / Secret | 配置 / 密钥（Base64） | data |
| Namespace | 逻辑隔离 | — |
| HPA | 水平 Pod 自动伸缩 | scaleTargetRef, minReplicas, maxReplicas |
| PV / PVC | 持久卷 / 持久卷声明 | storage, accessModes |
B5 Service 四种类型
| 类型 | 访问范围 | 说明 |
|---|---|---|
| ClusterIP | 集群内 | 默认；虚拟 IP |
| NodePort | 集群外（节点 IP:Port） | 30000-32767 |
| LoadBalancer | 公网 | 云厂商 LB |
| ExternalName | 集群内 → 外部域名 | CNAME |
B6 真题举一反三
IMPORTANT
2024-05 综合：K8s 中负责 Pod 调度的组件是 kube-scheduler。监听未调度 Pod → 过滤（资源）→ 打分（亲和）→ 绑定节点。
IMPORTANT
- Deployment：无状态（Web/API），Pod 名随机，可任意替换
- StatefulSet：有状态（MySQL/Kafka/ZooKeeper），Pod 名稳定（statefulset-0/1/2），独立 PVC，有序启停
NOTE
2025-05 综合：HPA 自动伸缩基于什么指标 默认 CPU 利用率；可扩展自定义指标（Prometheus Adapter）；支持缩容到 0（结合 KEDA）。
C. 云计算模型
C1 IaaS / PaaS / SaaS 三层对比
| 模型 | 控制权 | 用户管理 | 典型产品 |
|---|---|---|---|
| IaaS 基础设施即服务 | OS + 中间件 + 应用 | 网络/存储/虚拟化由云管 | AWS EC2 / 阿里云 ECS / OpenStack |
| PaaS 平台即服务 | 应用 + 数据 | OS/中间件由云管 | Heroku / 阿里云 EDAS / GAE / K8s 托管 |
| SaaS 软件即服务 | 仅使用 | 全部由云管 | Salesforce / 钉钉 / 飞书 / Office365 |
TIP
- IaaS：租”毛坯房”（自己装修）
- PaaS：租”精装房”（自己住）
- SaaS：住”酒店”（拎包入住）
C2 部署模型
| 模型 | 说明 | 适用 |
|---|---|---|
| 公有云 | 多租户共享 | 互联网业务 |
| 私有云 | 单一组织独占 | 金融/政府 |
| 混合云 | 公有+私有 | 弹性+合规 |
| 社区云 | 行业共享 | 医疗/政务 |
C3 云原生四要素
IMPORTANT
必背 微服务 + 容器 + DevOps + 持续交付
C4 12-Factor App（云原生应用原则）
| 原则 | 说明 |
|---|---|
| 1 代码库 | 一份代码库，多份部署 |
| 2 依赖 | 显式声明 |
| 3 配置 | 环境变量（不入代码） |
| 4 后端服务 | 当作附加资源（DB/Cache/MQ） |
| 5 构建/发布/运行 | 严格分离 |
| 6 进程 | 无状态执行 |
| 7 端口绑定 | 自包含服务 |
| 8 并发 | 进程模型 |
| 9 易处理 | 快速启动/优雅终止 |
| 10 环境等价 | 开发/测试/生产尽量一致 |
| 11 日志 | 当作事件流 |
| 12 管理任务 | 一次性进程 |
C5 真题举一反三
IMPORTANT
2022-11 综合：以下属于 PaaS 的是 Heroku / 阿里云 EDAS / Google App Engine。EC2/ECS 是 IaaS，Salesforce 是 SaaS。
NOTE
2025-05 综合：云原生四要素是 微服务 + 容器 + DevOps + 持续交付。
D. Serverless 无服务器（2025-11 论文真题）
D1 两种形态
| 形态 | 全称 | 典型 |
|---|---|---|
| FaaS | 函数即服务 | AWS Lambda / 阿里云 FC / Azure Functions / 腾讯云 SCF |
| BaaS | 后端即服务 | Firebase / 阿里云 BaaS（DB/存储/认证/推送） |
D2 核心特征
| 特征 | 说明 |
|---|---|
| 事件驱动 | HTTP / 消息 / 定时 / 对象存储 / IoT 触发 |
| 自动弹性 | 0 到 N 自动伸缩 |
| 按量计费 | 执行次数 + 时长 + 内存（毫秒级） |
| 无运维 | 不感知服务器 |
| 无状态 | 状态外置（DB / Cache） |
D3 优缺点对比表
| 维度 | 优点 | 缺点 |
|---|---|---|
| 运维 | 零运维 | 调试难（本地与生产不一致） |
| 弹性 | 0 到 N 秒级 | 冷启动延迟（百毫秒~秒） |
| 成本 | 按量计费，无闲置 | 长任务反而贵 |
| 状态 | 天然分布式 | 强状态不友好 |
| 生态 | 厂商绑定函数 | 厂商锁定严重 |
| 架构 | 解耦事件流 | 链路长，排查复杂 |
D4 适用 vs 不适用
| 适合 | 不适合 |
|---|---|
| 事件驱动（Webhook / IoT） | 长连接（IM/游戏） |
| 定时任务（报表/对账） | 大文件持续处理 |
| 突发流量（秒杀预热） | 极致低延迟（小于 10ms） |
| 数据 ETL 转换 | 强状态复杂业务 |
| 图片/视频处理 | 长任务（>15 分钟） |
D5 论文段落模板（800 字）
IMPORTANT
Serverless 论文骨架 背景：业务有突发流量特征 + 团队规模小 + 运维成本高 → 选 Serverless。 方案：①前端 CDN ②API Gateway → FaaS 函数 ③对象存储 + CDN ④MQ 触发后台 ETL ⑤BaaS 数据库 / 认证。 效果：①零运维 ②按量计费，成本下降 60% ③弹性秒级响应突发。 问题：①冷启动 → 预热 + 长连接保留 ②厂商锁定 → 抽象 + Dapr ③调试 → 本地模拟器 + 全链路追踪。
D6 真题举一反三
IMPORTANT
2025-11 论文 ② Serverless 在突发流量场景的应用 论文要点：①事件驱动架构图 ②冷启动治理 ③厂商锁定规避 ④与传统微服务对比 ⑤成本测算。
NOTE
2024-11 综合：Serverless 不适合以下哪种场景 长连接 IM。FaaS 默认执行时长有限（如 15 分钟），且每次触发都是新进程，无法保持连接。
E. 大数据基础
E1 大数据 5V
| V | 含义 |
|---|---|
| Volume | 数据量大（PB 级） |
| Velocity | 处理速度快（实时/准实时） |
| Variety | 数据类型多样（结构化/半/非） |
| Veracity | 数据准确性（清洗 / 质量） |
| Value | 价值密度低（提炼） |
E2 大数据处理流程
F. Hadoop 生态
F1 HDFS 架构
| 角色 | 作用 |
|---|---|
| NameNode | 元数据（文件 → 块映射）；内存 |
| Secondary NameNode | 定期合并 fsimage + edits（非热备） |
| DataNode | 实际数据块（默认 128MB，3 副本） |
WARNING
易错点 Secondary NameNode 不是 NameNode 的热备，是辅助合并日志的。真正的 HA 用 Standby NameNode + JournalNode。
F2 MapReduce 流程
- 缺点：每阶段落盘，慢；Spark 基于内存远快于此。
F3 YARN 资源调度
| 角色 | 作用 |
|---|---|
| ResourceManager | 全局资源调度 |
| NodeManager | 单节点资源管理 |
| ApplicationMaster | 单作业管理（每个作业一个） |
F4 Hadoop 全家桶
| 组件 | 作用 |
|---|---|
| HDFS | 分布式文件存储 |
| MapReduce | 离线批处理 |
| YARN | 资源调度 |
| Hive | SQL on Hadoop（数据仓库） |
| HBase | 列族 NoSQL（基于 HDFS） |
| Pig | 脚本化数据流 |
| Sqoop | RDBMS ↔ HDFS 同步 |
| Flume | 日志采集 |
| Kafka | 消息队列 |
| ZooKeeper | 分布式协调 |
F5 真题举一反三
IMPORTANT
2024-05 综合：YARN 中负责单作业管理的组件是 ApplicationMaster。每提交一个作业启动一个 AM，向 RM 申请资源，启动 Task。
NOTE
2021-11 综合：HDFS 默认块大小是 128 MB（Hadoop 2.x+，旧版 64 MB）。3 副本。
G. Spark 与 Flink（流计算必考）
G1 Spark 核心
| 概念 | 说明 |
|---|---|
| RDD | 弹性分布式数据集（不可变 / 分区 / 血缘容错） |
| DAG | 有向无环图调度（Stage 划分） |
| 惰性计算 | transform 不执行，action 触发 |
| 内存计算 | 比 MapReduce 快 10~100 倍 |
G2 Spark 生态栈
| 模块 | 用途 |
|---|---|
| Spark Core | RDD / 调度 |
| Spark SQL | DataFrame / DataSet（Hive 替代） |
| Spark Streaming | 微批流处理（准实时） |
| MLlib | 机器学习 |
| GraphX | 图计算 |
G3 Spark vs Flink 对比表（必考）
| 维度 | Spark | Flink |
|---|---|---|
| 计算模型 | 批为主 + 微批流 | 真流式为主 + 批 |
| 流模型 | 微批（Spark Streaming / Structured Streaming） | 事件驱动（事件级延迟） |
| 延迟 | 秒~分钟 | 毫秒 |
| 状态管理 | 弱（基于检查点） | 强（ keyed state / operator state） |
| Exactly-once | Structured Streaming 支持 | 原生支持 |
| 时间语义 | 处理时间为主 | 事件时间 + Watermark |
| 窗口 | 滚动 / 滑动 / 会话 | 滚动 / 滑动 / 会话（更灵活） |
| API | DataFrame / SQL | DataStream / Table API / SQL |
| 典型场景 | 大数据离线 + 准实时 | 实时数仓 / CEP / 风控 |
G4 真题举一反三
IMPORTANT
2023-05 综合：以下关于 Spark RDD 错误的是 B. RDD 之间无依赖关系。错。RDD 通过血缘（lineage）建立依赖，是容错基础。
IMPORTANT
2025-11 案例：实时数仓选 Spark 还是 Flink 实时数仓（毫秒级延迟 / 事件时间 / 状态管理）→ Flink。准实时（秒级 / SQL 友好）→ Spark Structured Streaming。
H. 数据仓库 / 数据湖 / 湖仓一体
H1 三者对比表
| 维度 | 数据仓库 | 数据湖 | 湖仓一体 Lakehouse |
|---|---|---|---|
| 数据类型 | 结构化 | 全部（结构化/半/非） | 全部 |
| Schema | Schema-on-Write | Schema-on-Read | 两者皆有 |
| 事务 ACID | 支持 | 不支持 | 支持 |
| 处理 | ETL | ELT | 两者 |
| 典型 | Teradata / Greenplum / Hive | HDFS / S3 | Delta Lake / Iceberg / Hudi |
| 用户 | 业务分析 | 数据科学家 | 两者 |
H2 OLTP vs OLAP
| 维度 | OLTP | OLAP |
|---|---|---|
| 用途 | 事务处理 | 分析决策 |
| 数据量 | GB ~ TB | TB ~ PB |
| 操作 | 增删改查 | 复杂查询 |
| 事务 | 强 ACID | 弱 |
| 建模 | 规范化（3NF） | 星型 / 雪花 |
| 典型 | MySQL / Oracle | Greenplum / ClickHouse / Doris |
H3 真题举一反三
IMPORTANT
2024-05 综合：数据湖相对数据仓库的优势是 支持原始数据存储（结构化/半结构化/非结构化）+ Schema-on-Read。
IMPORTANT
2025-11 案例：湖仓一体核心技术 Delta Lake / Iceberg / Hudi 三件套，提供 ACID 事务、时间旅行、Schema 演化、Upsert 能力，让数据湖具备数据仓库的能力。
I. Lambda 与 Kappa 架构
I1 Lambda 架构
- 三层：批处理层（Batch）+ 速度层（Speed）+ 服务层（Serving）
- 缺点：两套代码（批 + 流）维护成本高
I2 Kappa 架构
- 只保留流处理，简化架构
- Flink 等统一流批后，Kappa 成为主流
I3 真题举一反三
IMPORTANT
- Lambda：批+流双层，准确度高，但代码维护成本高
- Kappa：仅流，简化；要求流引擎成熟（Flink）
- 演进：流批一体（Flink / Spark Structured Streaming）→ Kappa 主流
J. NoSQL 数据库（必考 1 题）
J1 四类型对比表（核心必背）
| 类型 | 特点 | 典型 | 适用 | 不适用 |
|---|---|---|---|---|
| 键值 KV | 极快、无结构、内存为主 | Redis / Memcached / DynamoDB | 缓存 / 会话 / 排行榜 | 复杂查询 |
| 列族 Column-Family | 稀疏矩阵、海量数据 | HBase / Cassandra | 时序 / 日志 / 推荐特征 | 强事务 |
| 文档 Document | JSON / 灵活 Schema | MongoDB / CouchDB | 内容管理 / 用户画像 | 跨文档事务 |
| 图 Graph | 节点 + 边 / 关系密集 | Neo4j / JanusGraph | 社交 / 推荐图谱 / 反欺诈 | 大数据量扫表 |
J2 BASE 理论
| 字母 | 含义 |
|---|---|
| BA Basically Available | 基本可用（允许部分不可用） |
| S Soft State | 软状态（允许中间状态） |
| E Eventual Consistency | 最终一致性 |
J3 真题举一反三
IMPORTANT
2022-05 综合：以下属于列族 NoSQL 的是 HBase / Cassandra。Redis 是 KV，MongoDB 是文档，Neo4j 是图。
IMPORTANT
2025-05 案例：社交关系推荐选什么数据库 图数据库 Neo4j / JanusGraph。节点（用户）+ 边（关注/好友）原生建模，多跳查询（朋友的朋友）O(1) 邻居访问，远快于关系型数据库的 JOIN。
K. CAP / BASE / 一致性算法
K1 CAP 定理
| 字母 | 含义 | 说明 |
|---|---|---|
| C Consistency | 一致性 | 所有节点看到相同数据 |
| A Availability | 可用性 | 每个请求都有响应 |
| P Partition Tolerance | 分区容错 | 网络分区仍能工作 |
IMPORTANT
必背结论 分布式系统 P 必选，故只能 CP 或 AP：
- CP：ZooKeeper / etcd / HBase / Redis Cluster（少数派拒绝）
- AP：Cassandra / Eureka / DynamoDB / CouchDB（继续服务，最终一致）
K2 Paxos
| 角色 | 作用 |
|---|---|
| Proposer | 提案者 |
| Acceptor | 接受者（多数派） |
| Learner | 学习者（接受最终值） |
- Basic Paxos：单值共识；两阶段（Prepare / Accept）
- Multi-Paxos：日志序列；优化为 Leader
- 难理解，工程化产品：Google Chubby / Spanner
K3 Raft
| 机制 | 说明 |
|---|---|
| Leader 选举 | 任期 Term + 心跳 + 随机超时 |
| 日志复制 | Leader 单向复制到 Follower |
| 安全性 Safety | 已提交的日志不丢失 |
| 成员变更 | 联合共识（两阶段） |
TIP
Raft 比 Paxos 易理解 Raft 通过分解（领导选举 + 日志复制 + 安全性）和强 Leader简化设计。代表实现：etcd / Consul / TiKV。
K4 其他共识 / 协议
| 协议 | 应用 |
|---|---|
| ZAB | ZooKeeper 原子广播（类 Paxos） |
| Gossip | Cassandra / Redis Cluster 流言式同步 |
| PBFT | 联盟链（Hyperledger Fabric） |
K5 真题举一反三
IMPORTANT
2024-11 综合：Raft 中 Leader 选举的触发条件是 Follower 在 election timeout 内未收到 Leader 心跳。随机化 election timeout 避免活锁。
NOTE
2020-11 综合：CAP 中网络分区发生时 只能选 CP 或 AP。例如 ZooKeeper 选 CP（少数派拒绝服务），Eureka 选 AP（继续服务，最终一致）。
L. DevOps 与持续交付
L1 CALMS 原则
| 字母 | 含义 |
|---|---|
| C Culture | 文化（开发与运维协作） |
| A Automation | 自动化（构建/测试/部署） |
| L Lean | 精益（消除浪费） |
| M Measurement | 度量（指标驱动） |
| S Sharing | 分享（知识/工具） |
L2 CI vs CD vs CD
| 缩写 | 全称 | 范围 |
|---|---|---|
| CI Continuous Integration | 持续集成 | 自动构建+测试+合并 |
| CD Continuous Delivery | 持续交付 | CI + 自动发布到预发（手动上线） |
| CD Continuous Deployment | 持续部署 | CD + 自动上线生产 |
L3 CI/CD Pipeline 阶段
L4 IaC 基础设施即代码
| 工具 | 类型 | 特点 |
|---|---|---|
| Terraform | 声明式 | HCL；多云；幂等 |
| Ansible | 命令式 | YAML Playbook；Agentless（SSH） |
| CloudFormation | 声明式 | AWS 专属 |
| Pulumi | 声明式 | 通用编程语言（TS/Python/Go） |
| Chef / Puppet | 命令式 | 老；Agent 模式 |
L5 SRE 三大支柱
| 概念 | 说明 |
|---|---|
| SLI Service Level Indicator | 指标（延迟 / 可用率 / 吞吐） |
| SLO Service Level Objective | 目标（99.9% 可用） |
| SLA Service Level Agreement | 协议（违约赔偿） |
L6 GitOps
- Git 作为单一可信源（Single Source of Truth）
- 声明式描述（YAML）
- 自动同步（ArgoCD / Flux）
- 持续交付 K8s 应用主流模式
L7 真题举一反三
IMPORTANT
2024-05 综合：以下关于 IaC 正确的是 Terraform 是声明式、Ansible 是命令式。声明式幂等，命令式顺序执行。
IMPORTANT
2025-11 案例：DevOps 落地关键 ①CI/CD 自动化 ②IaC ③监控可观测 ④灰度发布 ⑤故障自愈 ⑥文化协作。
M. AI / 机器学习 / 深度学习
M1 机器学习三分类
| 类型 | 任务 | 算法 |
|---|---|---|
| 监督学习 | 分类 / 回归 | 决策树 / SVM / KNN / 逻辑回归 / 神经网络 |
| 无监督学习 | 聚类 / 降维 | K-Means / DBSCAN / PCA / LDA |
| 强化学习 | 决策序列 | Q-Learning / SARSA / AlphaGo |
M2 深度学习模型对比
| 模型 | 全称 | 适用 | 关键组件 |
|---|---|---|---|
| MLP | 多层感知机 | 通用 | 全连接层 |
| CNN | 卷积神经网络 | 图像 / 视频 | 卷积 + 池化 + 全连接 |
| RNN | 循环神经网络 | 序列（NLP / 时序） | 隐状态 |
| LSTM | 长短期记忆 | 长序列 | 门控（输入/遗忘/输出） |
| Transformer | 注意力模型 | 大模型 | Self-Attention + Encoder-Decoder |
| GAN | 生成对抗 | 生成 | 生成器 + 判别器 |
| AutoEncoder | 自编码 | 降维/异常检测 | 编码器 + 解码器 |
M3 Transformer 与大模型
| 概念 | 说明 |
|---|---|
| Self-Attention | 自注意力机制，捕捉长距离依赖 |
| Multi-Head | 多头并行关注不同子空间 |
| BERT | Encoder-only；理解类任务（分类/问答） |
| GPT | Decoder-only；生成类任务 |
| 预训练 + 微调 | 大规模无监督 + 下游有监督 |
| 大模型 | GPT-4 / Claude / 文心一言 / 通义千问 |
M4 AI 测试（2024-05 论文 ④）
| 维度 | 测试方法 |
|---|---|
| 数据测试 | 数据质量 / 偏见 / 多样性 |
| 模型测试 | 准确率 / 精确率 / 召回率 / F1 / AUC |
| 鲁棒性 | 对抗样本 / 边界测试 |
| 可解释性 | LIME / SHAP |
| 公平性 | 性别 / 种族 / 年龄偏差 |
| 安全 | 数据投毒 / 模型逆向 |
IMPORTANT
- 准确率 Accuracy = (TP+TN) / 总数
- 精确率 Precision = TP / (TP+FP)
- 召回率 Recall = TP / (TP+FN)
- F1 = 2·P·R / (P+R)
M5 真题举一反三
IMPORTANT
2024-05 论文 ④ AI 系统测试 要点：①数据测试（质量/偏见）②模型测试（准确率/鲁棒性）③系统测试（性能/安全）④伦理测试（公平性/可解释）。
NOTE
2025-05 综合：以下哪个是图像识别的典型深度学习模型 CNN。卷积神经网络在 ImageNet 上突破是深度学习爆发的里程碑（AlexNet 2012）。
N. 区块链
N1 核心特性
| 特性 | 实现 |
|---|---|
| 去中心化 | P2P 网络，无中心节点 |
| 不可篡改 | 哈希链 + 共识 |
| 可追溯 | 完整历史记录 |
| 公开透明 | 公链账本公开 |
| 匿名性 | 地址 + 私钥 |
N2 共识机制对比表（核心）
| 共识 | 全称 | 原理 | 性能 | 适用 |
|---|---|---|---|---|
| PoW | 工作量证明 | 算力竞争解题 | 低（BTC 7 TPS） | 公链（BTC） |
| PoS | 权益证明 | 按持币量选块 | 中 | 公链（ETH 2.0） |
| DPoS | 委托权益证明 | 投票选见证人 | 高（EOS 千 TPS） | 公链 |
| PBFT | 实用拜占庭容错 | 三阶段提交 | 高 | 联盟链（Fabric） |
| DPOS+PBFT | 混合 | 投票 + BFT | 中高 | EOS |
N3 公链 / 联盟链 / 私链
| 类型 | 参与方 | 准入 | 典型 |
|---|---|---|---|
| 公链 | 任何人 | 自由 | BTC / ETH |
| 联盟链 | 多个组织 | 受控 | Hyperledger Fabric / FISCO BCOS |
| 私链 | 单一组织 | 内部 | 内部审计 |
N4 智能合约
- 以太坊：Solidity / EVM / Gas 计费
- Hyperledger Fabric：Chaincode（Go/Java）/ Docker 容器执行
- 应用：数字资产 / 供应链溯源 / 跨境支付 / 数字身份
N5 真题举一反三
IMPORTANT
2023-05 综合：联盟链常用共识机制是 PBFT（实用拜占庭容错）。三阶段（pre-prepare / prepare / commit），容忍 f 个拜占庭节点（需 3f+1 总节点）。
IMPORTANT
2025-05 案例：金融行业区块链选型 联盟链 + PBFT（Hyperledger Fabric）。理由：①受控准入 ②高 TPS ③符合监管 ④隐私可控（Channel）。
O. 秒杀 / 高并发架构（2025-11 论文真题）
O1 秒杀难点
| 难点 | 说明 |
|---|---|
| 瞬时高并发 | 平时 100 QPS，秒杀瞬时 10w+ QPS |
| 库存超卖 | 并发扣减竞争 |
| 黄牛防刷 | 脚本 / 播 / 接口被滥用 |
| 服务雪崩 | 下游依赖被打挂 |
| 热点数据 | 单 key 单行成为瓶颈 |
O2 分层解决方案
O3 各层方案对比表
| 层 | 方案 | 技术 |
|---|---|---|
| 前端 | 静态化 + 按钮禁用 + 验证码 | CDN / Nginx |
| 网关 | 限流 + 防刷 + 黑名单 | 令牌桶 / IP 限流 / 设备指纹 |
| 服务 | 异步下单 + 排队 + 接口幂等 | 线程池 / 队列 |
| 缓存 | Redis 预扣库存 + Lua 原子 | Redis Cluster / Lua |
| MQ | 削峰填谷 + 解耦 | Kafka / RocketMQ |
| 数据库 | 分库分表 + 乐观锁 | 分片 + version |
O4 四大原则
IMPORTANT
必背 动静分离 / 缓存为王 / 异步解耦 / 漏斗保护
- 动静分离：静态走 CDN
- 缓存为王：多级缓存（本地 / Redis）
- 异步解耦：MQ 削峰
- 漏斗保护：逐层减少流量（限流 / 熔断）
O5 库存超卖治理
| 方案 | 优点 | 缺点 |
|---|---|---|
| DB 乐观锁（version） | 简单 | DB 压力大 |
| DB 行锁（FOR UPDATE） | 强一致 | 慢 |
| Redis Lua 原子扣减 | 快 | 需同步 DB |
| Redisson 分布式锁 | 简单 | 性能瓶颈 |
| 分段库存（10 段 × 100） | 高并发 | 复杂 |
O6 论文段落模板（800 字）
IMPORTANT
秒杀论文骨架 背景：电商大促瞬时 10w QPS，常态 100 QPS → 1000 倍突发。 方案：①前端 CDN 静态化 + 验证码 ②网关令牌桶限流 + 黑名单 ③Redis 预扣库存（Lua 原子）④MQ 异步下单 ⑤DB 乐观锁兜底。 效果：①支撑 10w QPS ②零超卖 ③响应小于 100ms。 问题：①热点 key → 分段缓存 ②Redis 故障 → 降级 DB ③消息积压 → 消费者扩容。
O7 真题举一反三
IMPORTANT
2025-11 论文 ③ 高并发秒杀系统设计 论文要点：①分层架构图 ②四原则 ③库存超卖治理 ④热点数据 ⑤熔断降级 ⑥监控告警。
P. 反查表（核心必背）
| 考点 | 关键对比 | 真题年份 | 本笔记锚点 |
|---|---|---|---|
| 容器 vs VM | 启动秒 vs 分钟 | 2024-05 | A1 |
| Dockerfile 指令 | RUN 创建层，CMD 不创建 | 2023-11 | A3 |
| K8s 调度组件 | kube-scheduler | 2024-05 | B2 |
| StatefulSet vs Deployment | 稳定标识 vs 随机 | 2025-11 | B4 |
| HPA 指标 | CPU + 自定义 | 2025-05 | B4 |
| IaaS/PaaS/SaaS | 控制权分层 | 2022-11 | C1 |
| 云原生四要素 | 微服务+容器+DevOps+CD | 2025-05 | C3 |
| Serverless 冷启动 | 100ms~s | 2024-11 | D3 |
| Serverless 不适合 | 长连接 / 长任务 | 2025-11 | D4 |
| HDFS 块 | 128MB × 3 副本 | 2021-11 | F1 |
| YARN 角色 | RM/NM/AM | 2024-05 | F3 |
| Spark vs Flink | 微批 vs 真流 | 2025-11 | G3 |
| 数据湖 vs 仓库 | Schema on Read vs Write | 2024-05 | H1 |
| 湖仓一体 | Delta/Iceberg/Hudi | 2025-11 | H1 |
| Lambda vs Kappa | 批+流 vs 仅流 | 2024-05 | I1 |
| NoSQL 四类型 | KV/列族/文档/图 | 2022-05 | J1 |
| 图数据库 | Neo4j | 2025-05 | J1 |
| CAP 选择 | CP or AP | 2020-11 | K1 |
| Raft 选举 | Term + 心跳 | 2024-11 | K3 |
| Paxos 角色 | Proposer/Acceptor/Learner | 2021-05 | K2 |
| Terraform vs Ansible | 声明 vs 命令 | 2024-05 | L4 |
| CI/CD 区别 | 自动 vs 手动上线 | 2024-05 | L2 |
| AI 测试四维 | 数据/模型/系统/伦理 | 2024-05 | M4 |
| 图像识别模型 | CNN | 2025-05 | M2 |
| 联盟链共识 | PBFT | 2023-05 | N2 |
| 区块链金融 | 联盟链 + PBFT | 2025-05 | N5 |
| 秒杀四原则 | 动静/缓存/异步/漏斗 | 2025-11 | O4 |
| 库存超卖 | Redis Lua + 乐观锁 | 2025-11 | O5 |
记忆口诀 / 易错点汇总
IMPORTANT
云原生四要素 微、容、Dev、CD：微服务、容器、DevOps、持续交付。
IMPORTANT
12-Factor 简化版 一代码，二依赖，三配置；四后端，五构建，六进程；七端口，八并发，九易处；十等价，十一日志，十二管理。
IMPORTANT
CAP 取舍 P 必选，C/A 二选一。CP（ZK/etcd/HBase）保一致，AP（Eureka/Cassandra）保可用。
IMPORTANT
Spark vs Flink 一句话 Spark 批，Flink 流；Spark 微批，Flink 事件；Spark 秒级，Flink 毫秒。
WARNING
- Secondary NameNode 不是热备！是辅助合并 fsimage。
- PoW 性能低（BTC 7 TPS），不是公链首选性能王；PBFT 性能高但节点数有限（数十）。
- Serverless 冷启动 ≠ 无解，可预热 / 长连接保活 / 预留实例。
交叉引用
本系列笔记
09-cs-computation-deep.mdx— 流水线 / Cache / 可靠度 / 海明码11-database-network-deep.mdx— 数据库范式 / 网络协议（OLTP/OLAP 基础）15-architecture-styles-deep.mdx— 调用返回 / 管道过滤器 / 仓库 / 微服务风格16-quality-eval-deep.mdx— 可用性 / 性能 / 可修改性质量战术18-microservice-distributed-deep.mdx— 微服务分布式（本篇前置）20-enterprise-embedded-deep.mdx— 企业信息化 / 嵌入式（下一篇）21-exam-points-reverse-index.mdx— 全考点反查索引
主计划文档
.claude/plans/ruankao-architect-exam-plan.md— 总计划（含 Phase 编号）
外部延伸
- CNCF Landscape：cloud-native landscape
- Kubernetes 官方文档：kubernetes.io
- Databricks Delta Lake：docs.delta.io
- Apache Flink：flink.apache.org
自测题
NOTE
- 云原生四要素？K8s Master 5 大组件？Node 3 大组件？
- Service 4 种类型 + 区别？StatefulSet vs Deployment？
- Serverless 优点 4 / 缺点 5 / 适用 5 / 不适用 5？
- Spark vs Flink 7 维度对比？
- 数据仓库 vs 数据湖 vs 湖仓一体？
- NoSQL 四类型 + 典型产品 + 适用场景？
- CAP / BASE / Paxos / Raft？
- 秒杀四原则 + 库存超卖五种方案？
- 区块链四种共识 + 适用场景？
- AI 测试四个维度？
WARNING
如果默写不出来 说明知识没真正落地，回看对应章节并多做真题。
下一篇
➡️ 20-enterprise-embedded-deep.mdx — P19：企业信息化（EA/ERP/CRM/SCM/EAI/ESB）+ 嵌入式系统（RTOS / 实时调度 / 微内核）。