软考架构师知识点汇总

一、计算机系统基础（完整展开）

1. 硬件架构

硬件架构是理解系统性能、虚拟化、容器化技术的基础，考点集中在处理器架构 、存储体系 、总线与接口三个方面。

1.1 处理器架构

• CISC（复杂指令集计算机）
  • 特点：指令数量多、格式可变长，每条指令可完成复杂操作（如内存直接运算）。硬件实现复杂，编译器设计简单。
  • 代表：Intel x86、AMD64。
  • 适用：通用计算、桌面与服务器。
• RISC（精简指令集计算机）
  • 特点：指令数量少、定长编码，仅支持"加载-存储"架构（运算仅在寄存器间进行）。硬件简化，依赖编译器进行指令调度优化。
  • 代表：ARM、MIPS、RISC-V。
  • 适用：移动设备、嵌入式系统、低功耗场景。
• 考点 ：
  • 比较两者的指令执行效率：RISC通常每指令周期数（CPI）更低，但完成同样任务可能需要更多指令，总性能取决于编译器和硬件配合。
  • 流水线技术：RISC的定长指令更利于深度流水线，而CISC的变长指令会增加流水线控制复杂度。
  • 微架构实现：现代CISC处理器（如Intel Core）内部将CISC指令解码为类RISC的微操作（µops），融合了两者优势。

1.2 存储体系

存储体系基于局部性原理，构建层次化结构，以平衡速度、容量和成本。

• 层次结构 （速度递减、容量递增）：

  寄存器 → L1缓存 → L2缓存 → L3缓存 → 主存 → 本地磁盘 → 云存储

• 局部性原理 ：

  • 时间局部性：如果一个数据被访问，在短期内很可能再次被访问（循环、栈）。
  • 空间局部性：如果一个数据被访问，其邻近的数据也很快会被访问（数组遍历）。

• 缓存（Cache）

  • 映射方式 ：
    • 直接映射：内存块固定映射到某个缓存行，实现简单，但冲突率高。
    • 全相联映射：内存块可映射到任意缓存行，灵活但查找慢。
    • 组相联映射（折中）：将缓存分成若干组，每组内若干行，内存块先映射到组，再在组内全相联。
  • 替换算法：LRU（最近最少使用）、FIFO、LFU。
  • 写策略：写直达（write through，数据同时写入缓存和内存）与写回（write back，仅修改缓存，被替换时写回内存）。后者性能更优，但需维护脏位。

• 虚拟内存 ：

  • 分页：将虚拟地址空间划分为固定大小的页（4KB），映射到物理内存的页框。缺页中断时从磁盘换入。
  • 分段：按逻辑段（代码段、数据段）划分，长度可变，便于共享与保护，但易产生外部碎片。
  • 段页式：先分段再分页，结合二者优点，但地址转换开销大。
  • 地址转换：TLB（快表）加速虚拟地址到物理地址的转换，命中率直接影响系统性能。

1.3 总线与接口

• 总线分类：数据总线、地址总线、控制总线。
• 常见总线 ：
  • PCIe：点对点串行总线，用于显卡、SSD等高速设备。
  • SATA：用于硬盘、光驱。
  • USB：通用串行总线，热插拔。
• DMA（直接存储器访问）：允许外设直接与内存交换数据，无需CPU干预，提高吞吐量。

---

2. 操作系统（重点展开）

操作系统是计算机系统的核心软件，负责管理硬件资源、为应用程序提供运行环境。本科目重点考察进程管理 、内存管理 、文件管理 、设备管理 以及经典算法。

2.1 进程管理

2.1.1 进程状态与切换

• 三态模型 ：就绪、运行、阻塞。
  • 就绪：已获得除CPU外所有资源，等待CPU调度。
  • 运行：正在CPU上执行。
  • 阻塞：因等待某事件（如I/O完成）而暂停，即使分配CPU也无法继续。
• 五态模型（引入新建和终止状态）。
• 状态转换 ：
  • 就绪 → 运行：被调度器选中。
  • 运行 → 就绪：时间片用完或被抢占。
  • 运行 → 阻塞：请求资源（如读文件）未就绪。
  • 阻塞 → 就绪：等待的事件发生。

2.1.2 进程控制块（PCB）

PCB是进程存在的唯一标识，存储进程标识符、状态、程序计数器、寄存器、调度参数、内存指针等信息。系统通过PCB管理进程，创建进程时建立PCB，终止时回收。

2.1.3 线程

• 定义：进程内的轻量级执行单元，共享进程的地址空间和资源。
• 线程模型 ：
  • 用户级线程：由用户空间线程库管理，内核感知不到，切换快但无法利用多核。
  • 内核级线程：由内核管理，可以并行执行，但切换开销大。
  • 混合模型：将用户线程映射到内核线程（如Linux的NPTL）。
• 考点：线程与进程的对比（资源开销、调度、同步复杂度）。

2.1.4 调度算法

算法	描述	特点	适用
先来先服务（FCFS）	按到达顺序执行	公平，但平均等待时间长，不利于短作业	批处理系统
短作业优先（SJF）	估计运行时间最短的优先	最小化平均等待时间，但可能长作业饥饿	批处理系统
优先级调度	根据优先级选择，可分抢占/非抢占	可实现实时性，但可能饥饿，需动态调整	通用
时间片轮转（RR）	固定时间片，就绪队列循环	响应时间快，但时间片选择影响性能	分时系统
多级反馈队列	多个队列，优先级从高到低，时间片递增，新作业入高优先级队列，超时降级	兼顾短作业响应与长作业吞吐，现代操作系统主流	通用/服务器

• 考点：给定作业到达时间和服务时间，计算平均周转时间、平均等待时间；识别各算法特点。

2.1.5 进程同步与互斥

• 临界资源：一次只允许一个进程使用的资源（如打印机、共享变量）。
• 临界区：访问临界资源的代码段。
• 互斥（Mutual Exclusion）：保证同一时刻只有一个进程进入临界区。
• 同步（Synchronization）：协调进程执行顺序（如生产者-消费者）。

经典同步问题

1. 生产者-消费者问题

   • 描述：多个生产者向缓冲区放入数据，多个消费者从缓冲区取出数据，缓冲区容量有限。

   • 解决方案：三个信号量------mutex（互斥，初值1）、empty（空位计数，初值n）、full（产品计数，初值0）。

   • 伪代码：

     producer() {
         while(1) {
             produce_item();
             P(empty);     // 等待空位
             P(mutex);     // 进入临界区
             put_item();
             V(mutex);     // 离开临界区
             V(full);      // 增加产品计数
         }
     }
     consumer() {
         while(1) {
             P(full);      // 等待产品
             P(mutex);     // 进入临界区
             get_item();
             V(mutex);     // 离开临界区
             V(empty);     // 增加空位
             consume_item();
         }
     }

   • 注意：两个P操作的顺序不能颠倒，否则可能死锁（若先P(mutex)再P(empty)，当缓冲区满时，生产者会占用mutex等待empty，导致消费者无法进入临界区释放空位）。

2. 读者-写者问题

   • 描述：读者可同时读，写者互斥访问，且写者优先或读者优先。
   • 变体：读写锁实现。

3. 哲学家就餐问题

   • 描述：5位哲学家围坐，每两人之间一支筷子，需要两支筷子才能吃饭。
   • 解决方案：最多允许4人同时就餐、奇偶编号取筷子顺序、使用信号量避免死锁。

信号量与PV操作

• P操作（wait）：申请资源，信号量S减1；若S<0则进程阻塞。
• V操作（signal）：释放资源，信号量S加1；若S≤0则唤醒一个等待进程。
• 信号量初值 ：
  • 互斥信号量初值=1。
  • 同步信号量初值=0或资源数量。
• 考点：PV操作实现进程互斥与同步的代码填空、判断并发执行结果（如计算信号量最终值，分析是否存在死锁）。

2.1.6 死锁

• 必要条件 （缺一不可）：
  1. 互斥：资源一次只能被一个进程占用。
  2. 持有并等待：进程持有至少一个资源，同时等待其他进程持有的资源。
  3. 非抢占：资源不能被强制剥夺，只能由进程主动释放。
  4. 循环等待：存在一组进程{P0,P1,...,Pn}，P0等待P1的资源，P1等待P2的资源，...，Pn等待P0的资源。
• 死锁处理策略 ：
  • 预防：破坏四个必要条件之一。如：破坏"持有并等待"要求进程一次性申请所有资源；破坏"循环等待"给资源编号，要求按序申请。
  • 避免：银行家算法，动态检查资源分配是否会导致不安全状态。
  • 检测与恢复：允许死锁发生，通过检测算法发现，再通过剥夺资源、撤销进程等方式恢复。
• 银行家算法 （必考）：
  • 数据结构：Available（可用资源）、Max（最大需求）、Allocation（已分配）、Need（尚需 = Max - Allocation）。
  • 步骤：当进程提出请求 Request时，先检查 Request ≤ Need且 Request ≤ Available；然后试探分配，执行安全性算法；若安全则正式分配，否则拒绝。
  • 安全性算法：寻找一个安全序列，使得每个进程的 Need都不超过当前的 Available，然后逐步回收其 Allocation，最终所有进程完成。

2.2 内存管理

2.2.1 连续分配

• 单一连续区：早期单用户系统，内存分为系统区和用户区。
• 固定分区：内存划分为若干固定大小的分区，每个分区可装入一个作业。会产生内部碎片。
• 动态分区 ：按需分配，使用空闲分区表/链管理。会产生外部碎片，需采用紧凑（compaction）技术移动进程以合并空闲空间。
• 分配算法 ：
  • 首次适应（First Fit）：从头扫描，找到第一个足够大的分区。速度快。
  • 最佳适应（Best Fit）：找大小最接近需求的分区，产生最小碎片但扫描开销大。
  • 最坏适应（Worst Fit）：找最大的分区，避免产生微小碎片，但大分区被浪费。

2.2.2 分页管理

• 概念：将进程的虚拟地址空间分成大小相等的页，物理内存分成大小相等的页框。页内偏移地址相同，通过页表映射虚拟页到物理页框。
• 页表结构 ：
  • 多级页表（如x86-64使用四级页表）减少连续内存占用。
  • TLB（快表）：页表的硬件缓存，加速地址转换。TLB未命中时需访问内存中的页表。
• 地址转换 ：
  • 虚拟地址 = 页号 + 页内偏移。
  • 物理地址 = 页框号×页大小 + 偏移。
• 页面置换算法 （当内存不足时）：
  • 最佳置换（OPT）：淘汰未来最长时间不会访问的页面，理论最优但无法实现。
  • 先进先出（FIFO）：简单但可能产生Belady异常（增加物理块反而缺页率上升）。
  • 最近最久未使用（LRU）：淘汰最长时间未使用的页面，需硬件支持（计数器或栈），性能好但开销大。
  • 时钟算法（Clock/NRU）：近似LRU，使用访问位和修改位循环扫描。

2.2.3 分段管理

• 概念：按程序逻辑结构划分段（如代码段、数据段、堆栈段），每段长度可变。
• 优点：便于共享和保护，支持动态增长。
• 地址转换：段号 + 段内偏移，通过段表查找段基址和段限长。
• 与分页的比较 ：
  • 分页对用户透明，分段对用户可见。
  • 分页无外部碎片，分段有外部碎片。
  • 分段更容易实现共享（共享整个段）。

2.2.4 段页式管理

• 组合：先将程序分段，每段再分页。
• 地址结构：段号 + 页号 + 页内偏移。
• 地址转换：通过段表找到该段的页表地址，再通过页表找到物理页框。
• 特点：兼具分段共享保护和分页无外部碎片的优点，但需要两次地址转换，开销较大。

2.3 文件管理

2.3.1 文件结构与目录

• 文件逻辑结构：流式文件（无结构，字节序列）、记录式文件（有结构，如数据库表）。
• 文件物理结构 ：
  • 连续分配：简单，支持顺序访问，但产生外部碎片，不易扩展。
  • 链接分配：每个块存下一块指针，消除了外部碎片，但随机访问慢，指针占空间。
  • 索引分配：每个文件分配一个索引块，存放所有数据块的地址。支持随机访问，索引块本身开销大。
  • 混合索引（如Unix的i节点）：直接指针+一级间接指针+二级间接指针，平衡小文件和大文件。
• 目录结构 ：
  • 单级目录、两级目录（用户目录+文件目录）。
  • 树形目录（当前最常用）。
  • 硬链接：多个目录项指向同一个索引节点（inode），共享数据，不能跨文件系统。
  • 软链接（符号链接）：指向另一个文件路径的快捷方式，可以跨文件系统，但源文件删除后失效。

2.3.2 磁盘调度算法

算法	描述	优缺点
先来先服务（FCFS）	按请求顺序调度	简单，但平均寻道时间长
最短寻道时间优先（SSTF）	优先处理与当前磁头最近的请求	平均寻道时间短，但可能导致饥饿
扫描算法（SCAN）	磁头单向移动，处理沿途请求，到末端后折返	又称电梯算法，性能较稳定
循环扫描（C-SCAN）	单向移动，到末端后立即返回起点，忽略返回路径的请求	所有请求等待时间更均衡

• 考点：给定磁头起始位置和请求序列，计算平均寻道长度；分析各算法的饥饿问题。

2.4 设备管理

• I/O控制方式 ：
  • 轮询（程序直接控制）：CPU循环检查设备状态，效率低。
  • 中断驱动：设备完成时发送中断，CPU响应后处理数据，效率较高。
  • DMA（直接存储器访问）：设备直接与内存交换数据，仅在传输开始和结束时需要CPU干预，适合高速设备。
  • 通道控制：使用专门的处理机（I/O通道）负责I/O，进一步解放CPU。
• SPOOLing技术：将独占设备虚拟为共享设备，通过输入井和输出井实现脱机处理，例如打印机共享。
• 缓冲：解决CPU与I/O设备速度不匹配，常用单缓冲、双缓冲、循环缓冲。

---

3. 性能评价

性能评价部分考察如何度量系统性能、分析瓶颈和优化加速。

3.1 性能指标

• 响应时间：从用户发出请求到收到响应的时间。
• 吞吐量：单位时间内完成的任务数。
• 利用率：资源（CPU、磁盘）繁忙的时间比例。
• 加速比：系统优化后性能提升的倍数。
• Amdahl定律 （必考）：

  \\text{加速比} = \\frac{1}{(1 - F) + \\frac{F}{S}}

  其中 (F) 为可优化部分执行时间占总时间的比例，(S) 为该部分优化后的加速倍数。
  • 极限加速比：当 (S \to \infty) 时，加速比趋近于 (\frac{1}{1-F})。
  • 应用：常用于预测多核处理器并行化的理论收益，或系统某部分升级后的整体提升。

3.2 基准测试

• TPC系列：事务处理性能委员会制定，TPC-C用于在线交易处理，TPC-H用于决策支持查询。
• SPEC系列：标准性能评估公司，SPECint（整数运算）、SPECfp（浮点运算）。
• 考量：基准测试应反映真实应用场景，避免仅测试理论峰值。

---

二、操作系统部分重点总结与考点提示

知识点	常见题型	备考策略
进程状态转换	选择题（给出事件问状态变化）	牢记三态图，理解运行→就绪（时间片完）、运行→阻塞（请求I/O）
PV操作	填空、计算题	掌握生产者-消费者、读者-写者模型，会分析信号量初值与执行结果
死锁	选择题、计算题	背熟四个必要条件；银行家算法会画安全序列表格
页面置换算法	计算题	手动模拟OPT、FIFO、LRU，比较缺页次数；注意Belady异常
磁盘调度算法	计算题	给定序列计算平均寻道长度，区分SCAN和C-SCAN
文件系统	选择题	区分硬链接与软链接；理解混合索引结构
Amdahl定律	计算题	套用公式，注意F是优化部分执行时间占比，非代码占比

---

三、典型例题精讲

例题1（PV操作）

题目：某系统有3个并发进程，共享一个容量为5的缓冲区。进程P1负责向缓冲区放入数据，进程P2和P3负责从缓冲区取出数据。要求：

1. 缓冲区满时，P1必须等待；
2. 缓冲区空时，P2和P3必须等待；
3. 任何时刻只能有一个进程访问缓冲区（互斥）。

请用信号量写出P1、P2、P3的同步与互斥代码。

解析：

• 定义互斥信号量 mutex = 1。
• 定义同步信号量 empty = 5（空位初值），full = 0（产品数初值）。
• 由于有多个消费者，每个消费者都需要对 full进行P操作，对 empty进行V操作，但互斥必须保证对缓冲区的访问是互斥的。

semaphore mutex = 1;
semaphore empty = 5;
semaphore full = 0;

P1() {
    while(1) {
        produce_item();
        P(empty);      // 等待空位
        P(mutex);      // 进入临界区
        put_item();
        V(mutex);      // 离开临界区
        V(full);       // 增加产品数
    }
}

P2() {  // 消费者
    while(1) {
        P(full);       // 等待产品
        P(mutex);      // 进入临界区
        get_item();
        V(mutex);      // 离开临界区
        V(empty);      // 增加空位
        consume_item();
    }
}
P3() 同 P2。

例题2（银行家算法）

题目：系统有A、B、C三类资源，数量分别为10、5、7。当前分配如下表：

进程	Max	Allocation	Need
P0	7 5 3	0 1 0	7 4 3
P1	3 2 2	2 0 0	1 2 2
P2	9 0 2	3 0 2	6 0 0
P3	2 2 2	2 1 1	0 1 1
P4	4 3 3	0 0 2	4 3 1

Available = (3,3,2)。试问：当前系统是否安全？若P1请求(1,0,2)，能否立即分配？

解析：

1. 计算当前可用资源 Available = (3,3,2)。
2. 进行安全性检查：
   • 找Need ≤ Available的进程：P1 (1,2,2) ≤ (3,3,2)，可满足，假设分配后回收资源，Available变为(3+2,3+0,2+0)=(5,3,2)。
   • 接着P3 (0,1,1) ≤ (5,3,2)，分配后回收，Available变为(5+2,3+1,2+1)=(7,4,3)。
   • 接着P0 (7,4,3) ≤ (7,4,3)，分配后回收，Available变为(7+0,4+1,3+0)=(7,5,3)。
   • 接着P2 (6,0,0) ≤ (7,5,3)，分配后回收，Available变为(7+3,5+0,3+2)=(10,5,5)。
   • 接着P4 (4,3,1) ≤ (10,5,5)，分配后回收，Available变为(10+0,5+0,5+2)=(10,5,7)。
   • 安全序列为：P1 → P3 → P0 → P2 → P4。系统安全。
3. 检查P1请求(1,0,2)：
   • 请求(1,0,2) ≤ Need(1,2,2)，且 ≤ Available(3,3,2)，试探分配：
     • Available变为(2,3,0)。
     • P1的Allocation变为(3,0,2)，Need变为(0,2,0)。
   • 重新执行安全性检查：
     • Need ≤ Available的进程：P3 (0,1,1) ≤ (2,3,0)？不满足（C资源1>0）。P4 (4,3,1)不满足；P0 (7,4,3)不满足；P2 (6,0,0)不满足（A资源6>2）；P1 (0,2,0) ≤ (2,3,0) 满足，但分配后回收Available变为(2+3,3+0,0+2)=(5,3,2)。接下来P3 (0,1,1) ≤ (5,3,2) 满足，回收后Available=(5+2,3+1,2+1)=(7,4,3)；再P0 (7,4,3) 满足，回收后(7+0,4+1,3+0)=(7,5,3)；再P2 (6,0,0) 满足，回收后(7+3,5+0,3+2)=(10,5,5)；再P4 (4,3,1) 满足。存在安全序列P1→P3→P0→P2→P4。可以分配。

二、软件工程与项目管理细展开）

1. 开发过程模型

开发过程模型规定了软件生命周期中各项活动的组织方式，是项目管理与过程改进的基础。

1.1 传统过程模型

• 瀑布模型（Waterfall）
  • 阶段：需求分析 → 设计 → 编码 → 测试 → 运维，严格顺序。
  • 特点：文档驱动，每个阶段有明确的产出物，适合需求明确、技术成熟的项目。
  • 缺点：难以应对需求变更，反馈周期长，风险控制滞后。
• V模型
  • 结构：将测试活动与开发阶段一一对应（单元测试对应编码，集成测试对应概要设计，系统测试对应需求分析），强调测试与开发的并行性。
  • 适用：质量要求高、测试驱动开发的项目。
• 原型模型（Prototyping）
  • 目的：通过快速构建可运行的模型，帮助用户澄清需求，降低需求模糊带来的风险。
  • 类型：抛弃型原型（快速验证后丢弃）与演化型原型（逐步完善成为最终产品）。

1.2 敏捷模型

敏捷开发是近年来主流，强调个体与交互 、可工作的软件 、客户合作 和响应变化 。考纲中重点考察Scrum 和极限编程（XP）。

• 敏捷宣言 ：
  • 个体和交互 胜于 过程和工具
  • 可工作的软件 胜于 详尽的文档
  • 客户合作 胜于 合同谈判
  • 响应变化 胜于 遵循计划
• Scrum 框架 ：
  • 角色：产品负责人（Product Owner，维护产品待办列表）、Scrum Master（过程教练）、开发团队（自组织）。
  • 工件：产品待办列表（Product Backlog）、冲刺待办列表（Sprint Backlog）、燃尽图（Burndown Chart）。
  • 事件：冲刺（Sprint，固定时长，通常2-4周）、冲刺计划会、每日站会（Daily Scrum）、冲刺评审（Sprint Review）、冲刺回顾（Sprint Retrospective）。
  • 考点：Scrum中各角色的职责、冲刺期间需求是否可变（原则上不变，但产品负责人可终止冲刺）。
• 极限编程（XP） ：
  • 核心实践：测试驱动开发（TDD）、结对编程、持续集成、小版本发布、简单设计、重构。
  • 价值观：沟通、简单、反馈、勇气、尊重。
• 敏捷与瀑布对比 ：
  • 瀑布：计划驱动，适应稳定需求。
  • 敏捷：价值驱动，适应不确定需求。

1.3 统一过程（RUP）

• 四个阶段 ：
  1. 初始阶段：确定项目范围，建立业务模型，识别关键风险。
  2. 细化阶段：分析问题域，建立架构基线，制定详细计划。
  3. 构建阶段：迭代开发，完成功能，进行测试。
  4. 移交阶段：部署、培训、用户验收。
• 特点：用例驱动、架构为中心、迭代增量。
• 关键概念 ：工作流 （需求、分析、设计、实现、测试）与里程碑（每个阶段结束都有明确的评审）。

1.4 其他模型

• 螺旋模型（Spiral） ：结合瀑布与原型，引入风险驱动。每轮迭代包括：目标确定 → 风险分析 → 开发与验证 → 评审。适用于大型、高风险项目。
• 基于构件的开发（CBD）：复用现有组件进行装配，强调构件库、接口标准、组合框架。

---

2. 需求工程

需求工程是软件开发的起点，包含需求获取、分析、规格说明、验证与管理。

2.1 需求分类

• 功能需求：系统必须完成的功能（如"用户可以登录"）。
• 非功能需求 ：质量属性（性能、安全性、可用性）、约束（开发语言、平台）。架构师需要特别关注非功能需求，因为它们驱动架构设计。
• 业务需求：组织或客户的高层次目标。
• 用户需求：用户视角下的任务描述。

2.2 需求获取技术

• 访谈：结构化/非结构化。
• 问卷调查：适用于大规模用户。
• 原型法：通过可视化原型帮助用户澄清需求。
• 用户故事：敏捷中常用，格式为"作为[角色]，我想要[功能]，以便[价值]"。
• 用例（Use Case）：描述系统与外部参与者之间的交互，每个用例包含基本流与备选流。

2.3 需求验证

验证需求是否正确、完整、一致、可行、可测试。

• 需求评审：走查（Walkthrough）、正式审查（Inspection）。
• 原型验证：让用户试用原型。
• 可测试性检查：需求是否可被验证（例如"界面友好"难以测试，需量化）。

2.4 需求管理

• 需求跟踪矩阵：建立需求与设计、代码、测试用例的关联，确保变更影响可追溯。
• 变更控制 ：所有需求变更需经过变更控制委员会（CCB） 审批，评估影响后实施。

---

3. 软件测试

测试是保证质量的关键活动，考纲要求掌握测试方法、阶段、自动化策略。

3.1 测试方法

• 白盒测试 ：基于内部逻辑，常见覆盖准则：
  • 语句覆盖：每条语句至少执行一次（最弱）。
  • 判定覆盖（分支覆盖）：每个判定取真和假至少一次。
  • 条件覆盖：每个条件的真、假值至少出现一次。
  • 判定/条件覆盖：判定与条件的组合。
  • 路径覆盖：每条可能路径至少执行一次（最强，但通常不可行）。
  • 考点：根据程序图判断不同覆盖准则是否满足。
• 黑盒测试 ：基于规格说明，主要方法：
  • 等价类划分：将输入域划分成有效等价类与无效等价类，每个类选取代表值。
  • 边界值分析：针对边界情况设计测试用例（如最大值、最小值、略高于/低于边界）。
  • 因果图法：分析输入条件组合与输出结果的关系。
  • 场景法：基于用例的基本流与备选流设计测试。
• 灰盒测试：介于白盒与黑盒之间，关注程序内部数据结构，但不完全覆盖逻辑路径。

3.2 测试阶段

阶段	测试对象	主要目标	参与角色
单元测试	单个模块/类	验证模块内部逻辑正确性	开发人员
集成测试	模块间接口	验证模块组合后的协作正确性	开发/测试人员
系统测试	完整系统	验证系统功能与非功能需求	测试团队
验收测试	交付物	用户确认是否满足业务需求	用户/客户

• 集成测试策略 ：
  • 自顶向下 ：从主控模块开始，逐步添加下层模块，需编写桩模块（Stub） 模拟未集成部分。
  • 自底向上 ：从底层模块开始，逐步组装，需编写驱动模块（Driver） 调用被测模块。
  • 三明治集成：结合两种方式，同时从上、下两个方向进行。
• 回归测试：软件修改后，重新执行已通过的测试用例，确保修改未引入新缺陷。回归测试是持续集成中的重要环节。

3.3 测试自动化与DevOps

• 持续集成（CI）：每次代码提交触发自动构建与测试，快速发现问题。
• 测试左移（Shift Left）：将测试活动提前到开发阶段，鼓励开发人员编写单元测试，进行代码审查。
• 测试金字塔：单元测试（数量最多，执行快）、集成测试、端到端测试（数量少，执行慢）的比例关系。

---

4. 项目管理

项目管理涉及范围、时间、成本、质量、沟通、风险、配置等多个领域。考纲重点考察配置管理 和进度管理（关键路径法）。

4.1 配置管理（Configuration Management，CM）

配置管理是识别、控制、记录和审计软件制品变更的过程，是保证软件一致性和可追溯性的基础。

• 配置项（Configuration Item，CI）：纳入管理的软件工作产品，如需求文档、源代码、设计模型、测试用例、用户手册。临时文件、编译中间件等不纳入。
• 配置管理活动 ：
  1. 配置项识别：为每个配置项分配唯一标识。
  2. 版本控制：管理配置项的多个版本，支持并行开发与版本回退。常用工具：Git、SVN。
  3. 变更控制：所有变更需通过变更控制委员会（CCB）审批，包括变更请求（CR）的评估、批准、实施、验证。
  4. 配置审计：确保配置项与文档一致，变更已被正确实施。
  5. 配置状态报告：记录配置项的状态变更历史。
• 考点 ：
  • 哪些应纳入配置管理（源代码、需求文档、设计模型等）。
  • 变更控制流程：提交CR → 评估影响 → CCB决策 → 实施变更 → 验证 → 关闭。
  • 基线：经过正式评审和批准的配置项集合，作为后续开发的基础（如需求基线、设计基线）。基线变更必须走正式变更流程。

4.2 进度管理

• 关键路径法（Critical Path Method，CPM） ：
  • 网络图：用节点表示活动，箭线表示依赖关系（前导图法PDM常用）。
  • 关键路径：从项目开始到结束最长的路径，决定了项目的最短工期。关键路径上的活动无浮动时间。
  • 浮动时间（Float） ：活动可以延迟而不影响项目总工期的时间。
    • 总浮动时间 = 最晚开始时间 - 最早开始时间。
    • 自由浮动时间 = 下一活动最早开始时间 - 本活动最早完成时间。
  • 计算步骤 ：
    1. 正推（Forward Pass）：计算最早开始（ES）和最早完成（EF）。
    2. 逆推（Backward Pass）：计算最晚开始（LS）和最晚完成（LF）。
    3. 找出总浮动时间为0的活动，构成关键路径。
  • 考点：给定活动依赖和持续时间，绘制网络图，找出关键路径，计算总工期，计算某活动的总浮动时间。

4.3 其他项目管理知识点

• 风险管理：识别风险 → 分析（定性/定量） → 规划应对 → 监控。风险应对策略：规避、转移、减轻、接受。
• 质量管理：质量规划（确定标准）、质量保证（审计过程）、质量控制（监控结果，如用控制图）。
• 沟通管理：干系人分析、沟通计划、信息分发。

---

三、典型例题与考点精讲

例题1（敏捷开发）

题目 ：以下关于Scrum的叙述中，正确的是（ ）

A. 产品负责人负责维护冲刺待办列表

B. 冲刺期间，开发团队可以随时增加新需求

C. 每日站会上，团队成员需要汇报昨天做了什么、今天计划做什么、遇到了什么障碍

D. Scrum Master是团队的管理者，负责分配任务

解析：

• A错误：产品负责人维护的是产品待办列表（Product Backlog），冲刺待办列表由开发团队在冲刺计划会上从产品待办列表中选取。
• B错误：冲刺期间需求不应变化，保持稳定以利于团队专注；若必须变更，产品负责人可终止冲刺。
• C正确：每日站会（Daily Scrum）的三个经典问题。
• D错误：Scrum Master是教练和服务者，帮助团队移除障碍，不分配任务（团队自组织）。
  答案：C

例题2（关键路径法）

题目：某项目活动依赖关系及持续时间如下表，求项目的关键路径和总工期。

活动	前置活动	持续时间（天）
A	-	3
B	A	5
C	A	4
D	B	2
E	C	3
F	D, E	4

解析：

1. 绘制前导图：
   • A（3天）→ B（5天）→ D（2天）→ F（4天）
   • A（3天）→ C（4天）→ E（3天）→ F（4天）
2. 计算路径长度：
   • A-B-D-F = 3+5+2+4 = 14天
   • A-C-E-F = 3+4+3+4 = 14天
     两条路径都是14天，均为关键路径。
3. 总工期为14天，关键路径为A-B-D-F和A-C-E-F。

例题3（配置管理）

题目 ：关于配置管理，下列说法错误的是（ ）

A. 基线是经过正式评审和批准的配置项集合

B. 变更控制委员会负责审批变更请求

C. 配置审计的目的是确认配置项与文档的一致性

D. 所有项目文档都必须纳入配置管理

解析：

• A、B、C正确。
• D错误：并非所有文档都需要纳入配置管理，例如临时草稿、个人笔记等可以不纳入，但正式的工作产品（如需求规格说明书、源代码）必须纳入。
  答案：D

---

四、备考策略与重点提示

知识点	常见题型	备考建议
开发模型（瀑布、敏捷、RUP）	选择题	区分各模型的核心特点、适用场景，熟记敏捷宣言和Scrum角色
需求工程	选择题	掌握非功能需求对架构的影响；理解用例与用户故事的区别
软件测试	选择题、计算题（覆盖准则）	能计算白盒测试的覆盖率；熟悉等价类划分与边界值分析
配置管理	选择题	牢记配置项、基线、变更控制流程；区分配置管理与版本控制
关键路径法	计算题	熟练进行正推逆推计算，能够识别关键路径和浮动时间

---

三、系统架构设计

系统架构设计部分涵盖架构基本概念、架构风格、架构评估、架构设计方法、中间件技术等。下面分模块逐一展开。

1. 架构基本概念

1.1 软件架构定义

软件架构是系统的高层次结构，包括：

• 组成系统的构件（Component）
• 构件之间的连接件（Connector）
• 构件与连接件的约束与配置
• 架构的原理与设计决策

1.2 "4+1"视图模型（必考）

这是架构描述的核心模型，由Philippe Kruchten提出，用于从不同视角描述软件架构。

视图	面向角色	描述内容	常用图形	关注点
逻辑视图	最终用户、分析人员	功能需求、类结构、对象协作	类图、对象图、状态图	功能划分、模块职责
开发视图	开发人员、项目经理	模块组织、代码结构、文件布局	包图、组件图	开发分工、代码复用、构建管理
进程视图	系统集成人员、性能工程师	并发与同步、进程/线程模型、通信机制	活动图、时序图	性能、吞吐量、可扩展性
物理视图	系统工程师、运维人员	硬件部署、网络拓扑、资源分布	部署图	可用性、可靠性、网络通信
场景（用例）	所有角色	将四个视图串联，用于需求验证和架构评估	用例图、用例描述	系统行为的一致性、可测试性

• 考点：给出系统某方面的描述，要求判断属于哪个视图。例如："类图和对象图"属于逻辑视图；"模块划分与包结构"属于开发视图；"服务器与数据库的物理节点分布"属于物理视图。

1.3 架构设计阶段与层次

• 架构设计：在需求分析之后、详细设计之前，聚焦系统的高层结构和关键决策。
• 架构层次 ：
  • 应用架构：业务功能与流程。
  • 数据架构：数据模型、存储与流转。
  • 技术架构：技术选型、中间件、框架。
  • 部署架构：物理节点、网络、运维。

---

2. 架构风格（Architectural Styles）

架构风格是一类具有相似结构特征的架构模式。考纲要求识别、区分并选择适合特定场景的风格。

2.1 数据流风格

2.1.1 管道-过滤器（Pipe-Filter）

• 结构：数据通过一系列过滤器（处理单元）流动，每个过滤器对数据进行处理，通过管道（连接件）传递。
• 特点：每个过滤器独立、可复用；支持并发处理；数据流单向。
• 适用：编译器（词法分析→语法分析→语义分析→代码生成）、音视频处理、数据清洗ETL。
• 考点：过滤器之间的独立性；管道的作用；数据流顺序。

2.1.2 批处理

• 结构：将数据收集成批次，顺序处理。
• 特点：每个步骤独立，步骤之间无交互；适合离线计算。
• 适用：银行对账、报表生成。

2.2 调用-返回风格

2.2.1 主程序-子程序

• 结构：主程序调用子程序，子程序可再调用更低级子程序。
• 特点：单线程、层次化调用。
• 适用：传统结构化程序设计。

2.2.2 面向对象风格

• 结构：对象封装数据与行为，通过方法调用交互。
• 特点：继承、多态、封装；支持复用与扩展。
• 适用：大多数现代应用，但需注意对象之间紧耦合可能导致复杂性。

2.2.3 分层架构（Layered Architecture）

• 结构：系统划分为若干层，每层只依赖下层（或允许跨层调用）。典型：表示层、业务逻辑层、数据访问层。
• 特点：关注点分离，每层可独立替换；但可能引入性能开销。
• 常见陷阱：层与层之间过度耦合（如业务层直接调用数据库）；分层不严格导致跨层调用。
• 变体：三层架构（表现层-业务层-数据层）、四层（增加服务层）、六层（增加领域层、持久层等）。

2.3 独立构件风格

2.3.1 进程通信

• 结构：独立进程通过消息传递通信。
• 特点：进程隔离，可靠性高；但通信开销大。

2.3.2 事件驱动架构（Event-Driven Architecture，EDA）

• 结构：事件生产者发布事件，事件消费者订阅事件，通过事件总线（消息中间件）异步通信。
• 特点：松耦合、异步、高吞吐；适合实时响应、流式处理。
• 变体：事件通知（简单发布-订阅）、事件溯源（Event Sourcing，存储事件序列，可重放）、CQRS（命令查询职责分离）。
• 适用：金融交易系统、物联网、微服务间异步协作。

2.4 数据共享风格

2.4.1 仓库（Repository）

• 结构：中央数据存储（仓库）与多个独立构件（知识源）交互，构件通过仓库共享数据。
• 特点：适合数据驱动系统；构件间不直接通信，但仓库成为瓶颈。
• 适用：专家系统、CAD系统、黑板系统（Blackboard）。

2.4.2 黑板（Blackboard）

• 结构：黑板（共享数据）、知识源（独立处理模块）、控制器（调度知识源）。
• 特点：适合解决非结构化问题，各知识源协同工作。
• 适用：语音识别、多传感器融合。

2.5 虚拟机风格

2.5.1 解释器

• 结构：将高级语言或指令翻译并执行，包含解释引擎、运行状态存储。
• 特点：灵活，支持动态修改行为；但性能较低。
• 适用：脚本语言（Python、JavaScript）、规则引擎。

2.5.2 规则系统

• 结构：基于规则集和推理引擎，通过匹配规则产生行为。
• 适用：专家系统、业务规则引擎（如Drools）。

2.6 其他重要风格

2.6.1 微服务架构（Microservices）

• 结构：将应用拆分为一组小型服务，每个服务独立部署、独立数据库，通过轻量级通信（HTTP/REST、gRPC）协作。
• 特点 ：
  • 去中心化治理：每个团队可自主选择技术栈。
  • 独立部署：故障隔离，弹性伸缩。
  • 挑战：分布式事务、服务发现、监控复杂性、运维成本。
• 与SOA的区别 ：
  • SOA强调企业级服务总线（ESB），微服务强调去ESB、轻量级通信。
  • 微服务更细粒度，强调每个服务独立数据库和部署。
  • 微服务通常遵循"每个服务负责一个业务能力"。

2.6.2 面向服务架构（Service-Oriented Architecture，SOA）

• 结构：将功能封装为服务，通过ESB（企业服务总线）进行服务编排和通信。
• 特点：强调服务复用、标准接口（WSDL、SOAP）、企业级集成。
• 常见技术：Web Service（SOAP）、ESB、BPEL（业务流程执行语言）。

2.6.3 云原生架构

• 核心要素：容器化（Docker）、编排（Kubernetes）、服务网格（Istio）、声明式API、不可变基础设施。
• 特点：弹性、可移植、按需资源、持续交付。

2.7 架构风格对比与选择

风格	耦合度	适用场景	典型挑战
分层架构	中（依赖下层）	企业应用	性能损耗，分层渗透
微服务	低（通过API）	大型互联网应用	分布式事务，运维复杂
事件驱动	极低（异步）	实时响应、流处理	消息一致性，调试困难
管道-过滤器	低（数据流）	数据处理流水线	无法交互，需重构数据流
仓库/黑板	中（共享数据）	AI系统、数据集成	数据一致性与并发控制

考点：给定系统描述，选择最合适的架构风格，并说明理由。

---

好的，我们继续科目一：综合知识 的第三大部分------三、系统架构设计 。这是整个考试的核心，占比约25%-37%，也是案例分析、论文的基础。下面我将从架构基本概念 、架构风格 、架构评估 、架构设计方法与文档四个层面展开。

---

三、系统架构设计（详细展开）

1. 架构基本概念

1.1 软件架构定义

软件架构是系统的一组结构，包括软件元素、这些元素的外部可见属性以及它们之间的关系。架构不仅描述系统的组件，还描述了组件之间的交互、约束和设计决策。

1.2 "4+1"视图模型（必考）

由Philippe Kruchten提出，从五个不同视角描述软件架构，每个视图服务于不同的涉众。

视图	描述	面向涉众	常用模型
逻辑视图	系统的功能分解，即类、对象、包的结构	最终用户、分析人员	类图、对象图、状态图
开发视图	软件的模块组织、分层、子系统划分	开发人员、项目经理	包图、组件图、分层结构
进程视图	系统的并发与同步机制，进程/线程的通信	系统集成人员、性能工程师	活动图、时序图、状态图
物理视图	软件到硬件的映射，部署拓扑、网络配置	系统工程师、运维人员	部署图
场景（场景视图）	贯穿其他四个视图的用例或场景，用于验证架构	所有涉众	用例图、用例描述

• 考点：给出一个架构描述，让你判断属于哪个视图。例如："采用MVC模式，将界面、业务逻辑和数据访问分离"属于开发视图；"系统部署在三台服务器上，采用主备模式"属于物理视图。

1.3 架构设计过程

典型架构设计步骤：

1. 需求分析：识别功能需求、质量属性、约束条件。
2. 架构候选：选择或设计候选架构风格。
3. 评估与选择：通过ATAM等方法评估候选架构。
4. 架构细化：细化模块、接口、部署。
5. 架构文档：编写架构视图文档。
6. 验证：原型验证、评审。

---

2. 架构风格（Architectural Styles）

架构风格定义了组件类型、连接器类型和约束规则。以下是考纲要求掌握的主要风格及其对比。

2.1 数据流风格

• 管道-过滤器
  • 结构：过滤器（处理单元）与管道（数据流连接）。每个过滤器独立，通过管道传递数据流。
  • 特点：高内聚、可重用、易扩展，适合批处理、编译器、音视频处理。
  • 缺点：不适合交互式应用，数据格式转换开销大。
  • 实例：Unix shell命令管道、编译器词法分析→语法分析→语义分析。

2.2 调用/返回风格

• 主程序/子程序

  • 结构：主程序调用子程序，子程序可再调用下层。
  • 适用：传统结构化编程，简单系统。

• 面向对象

  • 结构：对象封装数据与方法，通过方法调用交互。
  • 特点：数据抽象、继承、多态，提高复用与可维护性。

• 分层架构

  • 结构：将系统划分为若干层，每层只依赖下层（严格分层）或允许跨层（宽松分层）。
  • 常见层次：表现层、业务逻辑层、数据访问层。
  • 优点：关注点分离、可替换性、可测试性。
  • 缺点：可能引入性能损耗，层间耦合难以完全避免。
  • 实例：TCP/IP协议栈、Java EE三层架构。

2.3 独立构件风格

• 进程通信：构件间通过消息传递，支持并发。
• 事件驱动（隐式调用）
  • 结构：构件不直接调用另一构件，而是发布事件，系统将事件分发给订阅者。
  • 特点：松耦合、高扩展性，适合GUI、分布式系统。
  • 缺点：难以追踪数据流，调试复杂。
  • 实例：消息队列（Kafka/RabbitMQ）、观察者模式、事件溯源架构。

2.4 虚拟机风格

• 解释器：将高级语言指令转换为机器码执行，如Java虚拟机。
• 规则系统：基于规则库和推理引擎，如专家系统。

2.5 仓库风格

• 数据仓库：中心数据结构（如数据库）被多个独立构件访问，构件之间通常不直接通信。
• 黑板系统：知识源（构件）通过黑板共享信息，协作求解，适合人工智能、语音识别。
• 实例：数据库系统、集成开发环境（IDE）的符号表。

2.6 分布式架构风格（重点）

风格	描述	优点	缺点	典型技术
面向服务架构（SOA）	基于服务，通过ESB（企业服务总线）进行通信，服务可复用	业务与IT对齐，服务重用	ESB可能成为性能瓶颈，治理复杂	Web Service、ESB
微服务	细粒度、独立部署、独立数据库、去中心化治理	独立演进、弹性伸缩、技术异构	分布式事务、运维复杂度高	Spring Cloud、Kubernetes、Istio
服务网格	将服务间通信（如负载均衡、熔断）下沉到基础设施层（Sidecar）	业务与通信解耦，可观测性强	引入额外延迟和资源消耗	Istio、Linkerd
无服务器	开发者只编写函数，平台负责伸缩和运行	无需管理服务器，按需计费	冷启动延迟，不适合长时间任务	AWS Lambda

• SOA与微服务对比 ：
  • SOA强调服务共享和ESB，通常共享数据存储。
  • 微服务强调独立部署和独立数据库，去ESB，使用轻量级通信（如REST/gRPC）。

2.7 其他风格

• C2风格：通过连接件异步通信，构件间无直接耦合，适合GUI系统。
• MVC：模型（数据）-视图（显示）-控制器（逻辑），是分层架构在交互系统中的特化。

---

3. 架构评估

架构评估旨在分析架构是否满足质量属性需求，识别风险点、敏感点和权衡点。考纲重点考察质量属性 和ATAM方法。

3.1 质量属性场景

质量属性场景是评估的基本单元，包含六部分：

1. 刺激源：产生刺激的实体（如用户、系统）。
2. 刺激：触发系统响应的条件（如并发请求、硬件故障）。
3. 制品：被刺激的组件（如数据库、服务）。
4. 环境：刺激发生时系统的状态（如正常、高负载）。
5. 响应：系统对刺激的反应（如重启、返回结果）。
6. 响应度量：可量化的响应指标（如恢复时间≤5秒、吞吐量≥1000 TPS）。

考点：给出质量属性描述，要求补充场景要素或识别质量属性。

3.2 核心质量属性与战术

质量属性	定义	常用战术
可用性	系统正常运行时间的比例	故障检测（心跳、看门狗）、故障恢复（冗余、主动/被动备份）、故障预防（消除单点）
性能	响应时间、吞吐量、资源利用率	资源需求（减少开销）、资源管理（缓存、线程池、负载均衡）、资源仲裁（优先级调度）
可修改性	变更的难易程度	局部化修改（高内聚）、预防连锁反应（接口隔离）、延迟绑定（配置文件、依赖注入）
安全性	抵抗攻击的能力	抵抗攻击（认证、授权、加密）、检测攻击（入侵检测）、从攻击中恢复（审计、备份）
可测试性	测试的容易程度	可控制（日志、模拟）、可观察（接口暴露、内置测试）
易用性	用户操作的便捷性	支持用户界面、错误恢复、用户反馈

考点：给定一个架构决策（如引入缓存、使用主备模式），问该决策主要提升哪个质量属性，或属于哪种战术。

3.3 架构评估方法------ATAM

ATAM（架构权衡分析方法）是考纲明确要求的评估方法，核心步骤：

1. 展示阶段：描述业务驱动、架构视图。
2. 调查阶段：分析质量属性场景，识别敏感点、权衡点。
3. 分析阶段：生成风险点、非风险点、敏感点、权衡点清单。
4. 报告阶段：输出评估报告。

关键术语：

• 敏感点：对某质量属性影响显著的组件或决策。例如，数据库访问层的性能直接影响整体响应时间。
• 权衡点：影响多个质量属性，且需要平衡的决策。例如，使用缓存可提高性能，但可能降低数据一致性（可用性）。
• 风险点：可能导致不良后果的架构决策。
• 非风险点：可接受的架构决策。

考点：识别给定场景中的敏感点、权衡点；理解ATAM的输入输出。

---

4 架构设计方法与文档

4.1 基于架构的开发方法

• 模型驱动架构（MDA）：将业务模型（PIM）通过转换得到平台相关模型（PSM），再生成代码。
• 属性驱动设计（ADD）：以质量属性为驱动，逐步细化架构。
• 敏捷架构：在敏捷开发中，架构需保持简单，逐步演进，避免过度设计。

4.2 架构文档

架构文档应包含：

• 架构视图（4+1视图）。
• 架构决策记录（ADR）：记录重要决策的上下文、决策、后果。
• 接口规范：组件之间的API、数据格式。
• 部署视图：硬件、网络、负载均衡配置。
• 质量属性说明：如何满足关键质量属性。

---

5. 典型例题与考点精讲

例题1（4+1视图）

题目 ：某系统设计文档中包含一个描述系统进程间通信、同步机制的视图，该视图属于"4+1"视图中的（ ）

A. 逻辑视图

B. 开发视图

C. 进程视图

D. 物理视图

解析：进程视图关注并发、同步、通信，因此选C。

例题2（架构风格）

题目 ：某系统采用消息队列解耦各个服务，服务之间通过发布-订阅方式异步通信，该架构风格属于（ ）

A. 管道-过滤器

B. 事件驱动

C. 分层架构

D. 面向服务

解析：发布-订阅是事件驱动风格的核心特征。虽然SOA和微服务也可能使用消息队列，但题干强调"发布-订阅异步通信"，属于独立构件中的事件驱动风格。答案：B。

例题3（质量属性战术）

题目 ：系统设计中，为了提高可用性，采用了主备数据库模式，并在主库故障时自动切换到备库。该决策采用的战术是（ ）

A. 资源管理

B. 故障恢复

C. 资源仲裁

D. 预防连锁反应

解析：主备切换属于故障检测与恢复，属于可用性战术中的故障恢复。答案：B。

例题4（ATAM术语）

题目 ：在ATAM评估中，若某个架构决策既能提高性能，又会降低安全性，则该决策被称为（ ）

A. 敏感点

B. 权衡点

C. 风险点

D. 非风险点

解析：影响多个质量属性且需要平衡的决策是权衡点。答案：B。

---

6. 备考策略与重点提示

知识点	常见题型	备考建议
"4+1"视图	选择题	熟记每个视图的描述、面向涉众和常用模型
架构风格	选择题、案例分析基础	能够区分风格，对比优缺点（尤其是微服务 vs SOA，事件驱动 vs 分层）
质量属性	选择题、案例分析	记住常用质量属性定义和战术，能根据场景判断质量属性
ATAM	选择题	掌握敏感点、权衡点、风险点的定义，了解评估流程
架构文档	选择题	了解ADR、视图的作用

特别提醒：系统架构设计是后续案例分析（科目二）和论文（科目三）的基础，综合知识中这部分内容需做到概念清晰、辨析准确。建议结合历年真题，反复练习架构风格识别和质量属性判断。

---

四、信息安全

信息安全是系统架构设计中的重要质量属性，涉及机密性、完整性、可用性、不可否认性等。考纲要求掌握加密技术、认证与授权、安全协议、安全架构模型等内容。

---

1. 信息安全基础概念

1.1 安全目标（CIA三元组）

• 机密性（Confidentiality）：防止信息被未授权访问。
• 完整性（Integrity）：防止信息被未授权篡改。
• 可用性（Availability）：确保授权用户能够及时访问信息。
• 其他属性：不可否认性（Non-repudiation，防止否认行为）、可审计性（Accountability）。

1.2 安全威胁分类

• 中断：破坏可用性（如DoS攻击）。
• 截获：破坏机密性（如窃听）。
• 篡改：破坏完整性（如修改数据）。
• 伪造：破坏真实性（如冒充身份）。

---

2. 加密技术

2.1 对称加密

• 特点：加密和解密使用同一密钥，速度快，适合大量数据加密。
• 常见算法：DES（56位密钥，已不安全）、3DES（三次DES）、AES（高级加密标准，128/192/256位）、SM4（国密算法）。
• 缺点：密钥分发困难，n个用户需n(n-1)/2个密钥。

2.2 非对称加密

• 特点：公钥加密、私钥解密（或私钥签名、公钥验签），密钥对管理方便。
• 常见算法：RSA（基于大数分解）、ECC（椭圆曲线，更高效）、SM2（国密）。
• 应用：数字签名、密钥交换、身份认证。

2.3 混合加密

• 典型应用：HTTPS。用非对称加密传输对称密钥，后续通信使用对称加密，兼顾安全与效率。
• 密钥交换协议：Diffie-Hellman、ECDH。

2.4 哈希函数

• 特点：单向、固定长度输出、抗碰撞。用于完整性校验、数字签名。
• 常见算法：MD5（已不安全）、SHA-1（已弱化）、SHA-256、SM3（国密）。

---

3. 数字证书与PKI

3.1 数字签名

• 过程 ：发送方用私钥 对消息摘要（哈希值）加密，形成签名；接收方用发送方公钥解密签名并对比摘要，确认消息完整且不可否认。
• 作用：防篡改、防抵赖。

3.2 数字证书

• 定义：由CA（证书认证机构）签发，将公钥与实体身份绑定的电子文档。
• 标准：X.509，包含版本号、序列号、签名算法、颁发者、有效期、主体、公钥、扩展信息等。
• 证书链：从终端证书逐级上溯到根证书，用于验证证书的信任链。

3.3 PKI（公钥基础设施）

• 组成：CA（认证中心）、RA（注册中心）、证书库、证书撤销列表（CRL）。
• 功能：密钥管理、证书签发与撤销、身份认证。

---

4. 身份认证与访问控制

4.1 认证方式

• 单因素：密码、PIN码。
• 双因素：密码+动态口令、指纹+智能卡。
• 多因素：结合"所知、所持、所是"中的多种。

4.2 认证协议

• Kerberos：基于对称加密，使用AS、TGS票据中心，适用于局域网。
• OAuth 2.0：授权框架，允许第三方应用获取用户资源，不直接传递密码。
• JWT：JSON Web Token，用于无状态认证，包含头部、载荷、签名。

4.3 访问控制模型

模型	描述	特点
DAC（自主访问控制）	资源所有者决定访问权限	灵活，但安全性较低
MAC（强制访问控制）	系统根据标签（如机密等级）强制控制	安全性高，常用于军事
RBAC（基于角色）	权限授予角色，用户被赋予角色	易于管理，适用企业
ABAC（基于属性）	基于用户、资源、环境属性动态决策	灵活，适合复杂场景

---

5. 网络安全

5.1 网络攻击

• DDoS：分布式拒绝服务，耗尽目标资源。
• 中间人攻击：拦截并篡改通信。
• SQL注入：利用未过滤的输入篡改数据库查询。
• XSS（跨站脚本）：注入恶意脚本到网页。
• CSRF（跨站请求伪造）：诱导用户执行非本意操作。

5.2 网络安全协议

• SSL/TLS：传输层安全协议，用于加密HTTP（HTTPS）、SMTP等。TLS 1.3为最新版本。
• IPsec：网络层加密，用于VPN。
• SSH：安全远程登录与文件传输。

5.3 防火墙与入侵检测

• 防火墙：包过滤、状态检测、应用层网关（WAF）。
• IDS/IPS：入侵检测系统/入侵防御系统，基于签名或异常行为。

---

6. 安全架构模型

6.1 零信任架构（ZTA）

• 核心原则："从不信任，始终验证"。不区分内外网，默认所有访问均需认证、授权和加密。
• 关键技术：微隔离、身份与访问管理（IAM）、持续监控。
• 与边界防御对比：传统模型依赖防火墙划分信任域，零信任认为内部威胁同样严重。

6.2 WPDRRC模型

• W（预警）：威胁感知、风险评估。
• P（保护）：访问控制、加密、加固。
• D（检测）：入侵检测、异常监控。
• R（响应）：事件响应、阻断攻击。
• R（恢复）：数据备份、系统恢复。
• C（反击）：追溯、反制（较少实施）。

6.3 云安全

• 责任共担模型：云服务商负责"云的安全"，用户负责"云中的安全"。
• 安全服务：CASB（云访问安全代理）、CWPP（云工作负载保护平台）。

---

7. 典型例题与考点精讲

例题1（加密算法）

题目 ：以下关于非对称加密的描述，正确的是（ ）

A. 加密和解密使用同一密钥

B. 适合加密大量数据

C. 可用于数字签名

D. 密钥分发比对称加密困难

解析：非对称加密使用公钥加密、私钥解密，密钥分发简单（公钥可公开），但速度慢，不适合大量数据加密；可用于数字签名。答案：C。

例题2（数字证书）

题目 ：X.509数字证书中，不包含的信息是（ ）

A. 证书持有者的公钥

B. 证书颁发者

C. 证书持有者的私钥

D. 证书有效期

解析：证书中只包含公钥，私钥由持有者保管，不包含在证书中。答案：C。

例题3（访问控制）

题目 ：某公司要求员工只能查看本部门的数据，部门经理可以查看本部门所有数据，高管可以跨部门查看。这种访问控制模型是（ ）

A. DAC

B. MAC

C. RBAC

D. ABAC

解析：基于角色（员工、经理、高管）分配权限，属于RBAC。答案：C。

例题4（零信任）

题目 ：零信任安全架构的核心思想是（ ）

A. 边界防御

B. 内外网隔离

C. 默认不信任任何访问

D. 仅对公网服务进行保护

解析：零信任强调"从不信任，始终验证"，不默认内外网。答案：C。

---

8. 备考策略与重点提示

知识点	常见题型	备考建议
对称/非对称加密	选择题	区分算法、应用场景，记住典型算法名称
数字签名与证书	选择题	掌握签名流程、X.509内容、PKI组成
访问控制模型	选择题	区分DAC、MAC、RBAC、ABAC的特点与适用
网络安全协议	选择题	记住SSL/TLS、IPsec、SSH的作用
零信任架构	选择题	理解与传统边界防御的区别

特别提醒：信息安全部分综合知识考题较为基础，重在概念辨析和算法归类。建议结合《系统架构设计师教程（第2版）》相关章节，重点记忆各类安全技术的定义和应用场景。

---

五、数据库与新技术（详细展开）

数据库与新技术在综合知识中占比约10%-15%，考察范围包括关系型数据库设计、NoSQL、大数据架构、云原生及新兴技术。

---

1. 关系型数据库设计

1.1 数据库设计阶段

• 概念结构设计：独立于具体DBMS，使用E-R图（实体-联系图）描述实体、属性、联系。
• 逻辑结构设计：将E-R图转换为关系模式，确定主键、外键，进行规范化。
• 物理结构设计：选择存储结构、索引、分区方式。

1.2 范式理论（重点）

范式	要求	示例
1NF	属性不可再分（原子性）	地址字段不能同时包含省、市、区
2NF	满足1NF，且非主属性完全依赖于候选键（消除部分依赖）	部分依赖：学号+课程号→成绩，但学号→学院
3NF	满足2NF，且非主属性不传递依赖于候选键（消除传递依赖）	传递依赖：学号→学院，学院→院长
BCNF	满足3NF，且所有函数依赖的决定因素都是候选键	处理主属性间的依赖

• 考点：给定关系模式，判断属于第几范式，或指出需要如何分解。

1.3 事务与并发控制

• ACID特性 ：
  • 原子性（Atomicity）：事务不可分割，要么全做要么全不做。
  • 一致性（Consistency）：事务执行前后数据库保持一致性状态。
  • 隔离性（Isolation）：事务之间互不干扰。
  • 持久性（Durability）：事务提交后结果永久保存。
• 并发问题：丢失更新、脏读、不可重复读、幻读。
• 隔离级别 ：
  • 读未提交（可能脏读）
  • 读已提交（防止脏读，可能不可重复读）
  • 可重复读（防止脏读、不可重复读，可能幻读，MySQL默认）
  • 可串行化（最高，强制事务串行执行）

1.4 索引

• 类型：B+树索引（适合范围查询）、哈希索引（适合等值查询）、全文索引、位图索引。
• 原则：在频繁查询的列、连接列、排序列上建索引；避免在频繁更新的列上建过多索引。

---

2. NoSQL数据库

2.1 分类与特点

类型	代表	特点	适用场景
键值型	Redis、Memcached	简单key-value，高性能	缓存、会话存储
文档型	MongoDB、CouchDB	存储JSON/BSON文档，结构灵活	内容管理、日志
列族型	HBase、Cassandra	按列族存储，扩展性强	大数据分析、时间序列
图型	Neo4j、JanusGraph	节点-边模型，支持图遍历	社交网络、推荐系统

• 考点：根据应用场景选择合适的NoSQL类型。

2.2 CAP定理

• C：一致性（所有节点数据一致）
• A：可用性（请求总能得到响应）
• P：分区容错性（系统在网络分区时仍能工作）
• 定理：分布式系统最多只能满足其中两个。
• 常见选择 ：
  • CP系统（如ZooKeeper、HBase）：强调一致性和分区容错，牺牲可用性。
  • AP系统（如Cassandra、CouchDB）：强调可用性和分区容错，牺牲强一致性。
  • CA系统（传统关系型数据库）：忽略分区（不存在网络分区时）。

2.3 BASE理论

• Basically Available：基本可用（响应时间允许延长，部分功能降级）。
• Soft state：软状态（允许数据存在中间状态）。
• Eventually consistent：最终一致性（经过一段时间后数据达成一致）。
• BASE是对CAP中一致性和可用性权衡的实践，最终一致性是常见选择。

---

3. 分布式数据库

3.1 分库分表

• 垂直分片：按业务模块拆分，如用户库、订单库。
• 水平分片：按某个字段（如用户ID）取模或范围拆分，将数据分散到多表/多库。
• 常用中间件：ShardingSphere、MyCAT、Vitess。

3.2 分布式事务

• 两阶段提交（2PC）：准备阶段（协调者询问参与者是否可提交），提交阶段（协调者发出提交或回滚）。存在单点故障、同步阻塞问题。
• 三阶段提交（3PC）：引入超时机制，缓解阻塞，但仍无法完全解决一致性问题。
• TCC（Try-Confirm-Cancel）：业务层面分三阶段，Try预留资源，Confirm确认，Cancel回滚。适合高并发场景。
• 最终一致性方案：本地消息表、RocketMQ事务消息、Saga模式。

---

4. 大数据架构

4.1 Lambda架构

• 组成 ：
  • 批处理层：存储全量数据，计算离线视图（如Hadoop、Spark），高延迟但准确。
  • 速度层：处理实时增量数据，补偿批处理延迟（如Storm、Flink），低延迟但可能存在近似。
  • 服务层：合并批视图和实时视图，提供统一查询。
• 特点：代码需维护两套（批处理和流处理），运维复杂。

4.2 Kappa架构

• 组成：统一使用流处理引擎（如Kafka + Flink）处理所有数据，批处理视为流处理的特殊情况（通过重放历史数据）。
• 特点：简化架构，避免代码重复，但要求流处理框架支持数据重放和历史计算。

4.3 湖仓一体

• 数据湖：存储原始格式数据（如Parquet），支持结构化、半结构化、非结构化。
• 数据仓库：存储经ETL处理的结构化数据，高性能分析。
• 湖仓一体：结合二者，数据湖作为统一存储，数据仓库作为加速层（如Delta Lake、Iceberg、Hudi）。

---

5. 云原生

5.1 容器与编排

• Docker：容器化技术，将应用及其依赖打包成镜像，实现环境一致性。
• Kubernetes（k8s）：容器编排平台，提供服务发现、负载均衡、自动伸缩、滚动更新。

5.2 服务网格

• 定义：将服务间通信（如重试、熔断、监控）下沉到基础设施层，通过Sidecar代理（如Envoy）实现。
• 代表：Istio、Linkerd。
• 优势：业务代码与通信逻辑解耦，可观测性增强。

5.3 Serverless

• FaaS：函数即服务，开发者上传代码，平台负责弹性伸缩和计费（如AWS Lambda、阿里云函数计算）。
• 适用：事件驱动型应用、短时任务，不适合长时间运行或有状态服务。

5.4 DevOps与CI/CD

• CI/CD：持续集成/持续部署，自动化构建、测试、部署。
• IaC：基础设施即代码，用代码定义和管理云资源（如Terraform）。

---

6. 新兴技术

6.1 边缘计算

• 概念：在靠近数据源（如传感器、终端设备）的位置进行计算和存储，减少网络延迟和带宽消耗。
• 与云计算关系：云边协同，边缘处理实时数据，云端负责集中训练和长期存储。
• 应用：工业物联网、自动驾驶、智慧城市。

6.2 人工智能与系统架构

• 大模型推理架构 ：
  • 模型并行：将大模型切分到多个GPU。
  • 量化：将浮点权重转为低精度（INT8），降低显存占用。
  • 推理加速：使用TensorRT、ONNX Runtime。
• MLOps：机器学习模型的全生命周期管理，包括训练、部署、监控、迭代。

6.3 区块链

• 架构特点：去中心化、不可篡改、共识机制（PoW、PoS、PBFT）。
• 应用：数字货币、供应链溯源、智能合约。

---

7. 典型例题与考点精讲

例题1（范式）

题目 ：关系模式R(A, B, C, D)，函数依赖集F={A→B, B→C, C→D}，则R属于第几范式？
解析：主键为A，存在传递依赖A→B→C→D，非主属性传递依赖于主键，因此属于2NF但不属于3NF。答案：2NF。

例题2（NoSQL选型）

题目 ：某社交平台需要存储用户之间的好友关系，并频繁查询"共同好友"，应选用哪种NoSQL数据库？

A. 键值型

B. 文档型

C. 列族型

D. 图型

解析：好友关系是典型的图结构，图数据库（如Neo4j）擅长处理关系查询。答案：D。

例题3（CAP定理）

题目 ：ZooKeeper在分布式系统中常用于服务注册与发现，它主要保证了CAP中的哪两个特性？

A. 一致性和可用性

B. 一致性和分区容错性

C. 可用性和分区容错性

D. 一致性和持久性

解析：ZooKeeper是CP系统，保证强一致性（如选主）和分区容错性，在网络分区时可能短暂不可用。答案：B。

例题4（Lambda vs Kappa）

题目 ：以下关于Lambda架构与Kappa架构的描述，错误的是（ ）

A. Lambda架构需要维护批处理和流处理两套代码

B. Kappa架构将所有数据视为流，通过重放历史数据实现批处理

C. Kappa架构比Lambda架构更易于实现 Exactly Once 语义

D. Lambda架构的批处理层可以处理全量历史数据

解析：Kappa架构也需要保证Exactly Once，但并非比Lambda更易实现；实际上两者都依赖流处理引擎的能力。C错误。答案：C。

---

8. 备考策略与重点提示

知识点	常见题型	备考建议
范式理论	选择题、计算题	熟练判断函数依赖和范式等级，掌握分解方法
事务与隔离级别	选择题	区分四种隔离级别对应的并发问题
NoSQL与CAP	选择题	记住各类NoSQL代表、CAP定理应用
分布式事务	选择题	了解2PC、TCC、最终一致性的适用场景
大数据架构	选择题	对比Lambda与Kappa的优缺点
云原生	选择题	理解容器、编排、服务网格、Serverless的概念

特别提醒：新技术部分概念较新，但考题停留在基本定义和对比层面，无需深入实现细节。建议结合历年真题，熟悉常考的技术术语和应用场景。

---

以上为"五、数据库与新技术"的详细展开。如需继续下一章节（如"六、法律法规与专业英语"），请告知。

五、数据库与新技术（详细展开）

数据库与新技术在综合知识中占比约10%-15%，考察范围包括关系型数据库设计、NoSQL、大数据架构、云原生及新兴技术。

---

1. 关系型数据库设计

1.1 数据库设计阶段

• 概念结构设计：独立于具体DBMS，使用E-R图（实体-联系图）描述实体、属性、联系。
• 逻辑结构设计：将E-R图转换为关系模式，确定主键、外键，进行规范化。
• 物理结构设计：选择存储结构、索引、分区方式。

1.2 范式理论（重点）

范式	要求	示例
1NF	属性不可再分（原子性）	地址字段不能同时包含省、市、区
2NF	满足1NF，且非主属性完全依赖于候选键（消除部分依赖）	部分依赖：学号+课程号→成绩，但学号→学院
3NF	满足2NF，且非主属性不传递依赖于候选键（消除传递依赖）	传递依赖：学号→学院，学院→院长
BCNF	满足3NF，且所有函数依赖的决定因素都是候选键	处理主属性间的依赖

• 考点：给定关系模式，判断属于第几范式，或指出需要如何分解。

1.3 事务与并发控制

• ACID特性 ：
  • 原子性（Atomicity）：事务不可分割，要么全做要么全不做。
  • 一致性（Consistency）：事务执行前后数据库保持一致性状态。
  • 隔离性（Isolation）：事务之间互不干扰。
  • 持久性（Durability）：事务提交后结果永久保存。
• 并发问题：丢失更新、脏读、不可重复读、幻读。
• 隔离级别 ：
  • 读未提交（可能脏读）
  • 读已提交（防止脏读，可能不可重复读）
  • 可重复读（防止脏读、不可重复读，可能幻读，MySQL默认）
  • 可串行化（最高，强制事务串行执行）

1.4 索引

• 类型：B+树索引（适合范围查询）、哈希索引（适合等值查询）、全文索引、位图索引。
• 原则：在频繁查询的列、连接列、排序列上建索引；避免在频繁更新的列上建过多索引。

---

2. NoSQL数据库

2.1 分类与特点

类型	代表	特点	适用场景
键值型	Redis、Memcached	简单key-value，高性能	缓存、会话存储
文档型	MongoDB、CouchDB	存储JSON/BSON文档，结构灵活	内容管理、日志
列族型	HBase、Cassandra	按列族存储，扩展性强	大数据分析、时间序列
图型	Neo4j、JanusGraph	节点-边模型，支持图遍历	社交网络、推荐系统

• 考点：根据应用场景选择合适的NoSQL类型。

2.2 CAP定理

• C：一致性（所有节点数据一致）
• A：可用性（请求总能得到响应）
• P：分区容错性（系统在网络分区时仍能工作）
• 定理：分布式系统最多只能满足其中两个。
• 常见选择 ：
  • CP系统（如ZooKeeper、HBase）：强调一致性和分区容错，牺牲可用性。
  • AP系统（如Cassandra、CouchDB）：强调可用性和分区容错，牺牲强一致性。
  • CA系统（传统关系型数据库）：忽略分区（不存在网络分区时）。

2.3 BASE理论

• Basically Available：基本可用（响应时间允许延长，部分功能降级）。
• Soft state：软状态（允许数据存在中间状态）。
• Eventually consistent：最终一致性（经过一段时间后数据达成一致）。
• BASE是对CAP中一致性和可用性权衡的实践，最终一致性是常见选择。

---

3. 分布式数据库

3.1 分库分表

• 垂直分片：按业务模块拆分，如用户库、订单库。
• 水平分片：按某个字段（如用户ID）取模或范围拆分，将数据分散到多表/多库。
• 常用中间件：ShardingSphere、MyCAT、Vitess。

3.2 分布式事务

• 两阶段提交（2PC）：准备阶段（协调者询问参与者是否可提交），提交阶段（协调者发出提交或回滚）。存在单点故障、同步阻塞问题。
• 三阶段提交（3PC）：引入超时机制，缓解阻塞，但仍无法完全解决一致性问题。
• TCC（Try-Confirm-Cancel）：业务层面分三阶段，Try预留资源，Confirm确认，Cancel回滚。适合高并发场景。
• 最终一致性方案：本地消息表、RocketMQ事务消息、Saga模式。

---

4. 大数据架构

4.1 Lambda架构

• 组成 ：
  • 批处理层：存储全量数据，计算离线视图（如Hadoop、Spark），高延迟但准确。
  • 速度层：处理实时增量数据，补偿批处理延迟（如Storm、Flink），低延迟但可能存在近似。
  • 服务层：合并批视图和实时视图，提供统一查询。
• 特点：代码需维护两套（批处理和流处理），运维复杂。

4.2 Kappa架构

• 组成：统一使用流处理引擎（如Kafka + Flink）处理所有数据，批处理视为流处理的特殊情况（通过重放历史数据）。
• 特点：简化架构，避免代码重复，但要求流处理框架支持数据重放和历史计算。

4.3 湖仓一体

• 数据湖：存储原始格式数据（如Parquet），支持结构化、半结构化、非结构化。
• 数据仓库：存储经ETL处理的结构化数据，高性能分析。
• 湖仓一体：结合二者，数据湖作为统一存储，数据仓库作为加速层（如Delta Lake、Iceberg、Hudi）。

---

5. 云原生

5.1 容器与编排

• Docker：容器化技术，将应用及其依赖打包成镜像，实现环境一致性。
• Kubernetes（k8s）：容器编排平台，提供服务发现、负载均衡、自动伸缩、滚动更新。

5.2 服务网格

• 定义：将服务间通信（如重试、熔断、监控）下沉到基础设施层，通过Sidecar代理（如Envoy）实现。
• 代表：Istio、Linkerd。
• 优势：业务代码与通信逻辑解耦，可观测性增强。

5.3 Serverless

• FaaS：函数即服务，开发者上传代码，平台负责弹性伸缩和计费（如AWS Lambda、阿里云函数计算）。
• 适用：事件驱动型应用、短时任务，不适合长时间运行或有状态服务。

5.4 DevOps与CI/CD

• CI/CD：持续集成/持续部署，自动化构建、测试、部署。
• IaC：基础设施即代码，用代码定义和管理云资源（如Terraform）。

---

6. 新兴技术

6.1 边缘计算

• 概念：在靠近数据源（如传感器、终端设备）的位置进行计算和存储，减少网络延迟和带宽消耗。
• 与云计算关系：云边协同，边缘处理实时数据，云端负责集中训练和长期存储。
• 应用：工业物联网、自动驾驶、智慧城市。

6.2 人工智能与系统架构

• 大模型推理架构 ：
  • 模型并行：将大模型切分到多个GPU。
  • 量化：将浮点权重转为低精度（INT8），降低显存占用。
  • 推理加速：使用TensorRT、ONNX Runtime。
• MLOps：机器学习模型的全生命周期管理，包括训练、部署、监控、迭代。

6.3 区块链

• 架构特点：去中心化、不可篡改、共识机制（PoW、PoS、PBFT）。
• 应用：数字货币、供应链溯源、智能合约。

---

7. 典型例题与考点精讲

例题1（范式）

题目 ：关系模式R(A, B, C, D)，函数依赖集F={A→B, B→C, C→D}，则R属于第几范式？
解析：主键为A，存在传递依赖A→B→C→D，非主属性传递依赖于主键，因此属于2NF但不属于3NF。答案：2NF。

例题2（NoSQL选型）

题目 ：某社交平台需要存储用户之间的好友关系，并频繁查询"共同好友"，应选用哪种NoSQL数据库？

A. 键值型

B. 文档型

C. 列族型

D. 图型

解析：好友关系是典型的图结构，图数据库（如Neo4j）擅长处理关系查询。答案：D。

例题3（CAP定理）

题目 ：ZooKeeper在分布式系统中常用于服务注册与发现，它主要保证了CAP中的哪两个特性？

A. 一致性和可用性

B. 一致性和分区容错性

C. 可用性和分区容错性

D. 一致性和持久性

解析：ZooKeeper是CP系统，保证强一致性（如选主）和分区容错性，在网络分区时可能短暂不可用。答案：B。

例题4（Lambda vs Kappa）

题目 ：以下关于Lambda架构与Kappa架构的描述，错误的是（ ）

A. Lambda架构需要维护批处理和流处理两套代码

B. Kappa架构将所有数据视为流，通过重放历史数据实现批处理

C. Kappa架构比Lambda架构更易于实现 Exactly Once 语义

D. Lambda架构的批处理层可以处理全量历史数据

解析：Kappa架构也需要保证Exactly Once，但并非比Lambda更易实现；实际上两者都依赖流处理引擎的能力。C错误。答案：C。

---

8. 备考策略与重点提示

知识点	常见题型	备考建议
范式理论	选择题、计算题	熟练判断函数依赖和范式等级，掌握分解方法
事务与隔离级别	选择题	区分四种隔离级别对应的并发问题
NoSQL与CAP	选择题	记住各类NoSQL代表、CAP定理应用
分布式事务	选择题	了解2PC、TCC、最终一致性的适用场景
大数据架构	选择题	对比Lambda与Kappa的优缺点
云原生	选择题	理解容器、编排、服务网格、Serverless的概念

六、法律法规与专业英语（详细展开）

法律法规与专业英语在综合知识中占比约5%-10%，其中法律法规主要考察知识产权、著作权、商业秘密等法律概念，专业英语为5道选择题，通常涉及架构、设计模式、安全等技术术语的英文阅读。

---

1. 法律法规

1.1 著作权法

• 著作权主体：作者、法人或其他组织。
• 作品类型：计算机软件属于文字作品，受著作权法保护。
• 权利内容：发表权、署名权、修改权、保护作品完整权、复制权、发行权、信息网络传播权等。
• 保护期限 ：
  • 公民作品：终生及死后50年。
  • 法人作品：首次发表后50年。
• 自动保护原则：作品自创作完成即自动获得著作权，无需登记。

1.2 计算机软件保护条例

• 软件著作权：自软件开发完成之日起产生。
• 权利归属 ：
  • 职务开发：为完成本职工作或单位任务开发的软件，著作权归单位。
  • 委托开发：若合同未约定，著作权归受委托人（开发者）。
  • 合作开发：共同享有，可协商使用。
• 侵权判定：未经许可复制、修改、发行软件，或故意避开技术措施，构成侵权。

1.3 专利权

• 授予条件：新颖性、创造性、实用性。
• 保护期限：发明专利20年，实用新型和外观设计10年，均自申请日起算。
• 与著作权的区别：保护思想的表现形式（著作权）vs 保护技术方案（专利）。

1.4 商业秘密

• 定义：不为公众所知悉、具有商业价值、经权利人采取保密措施的技术信息和经营信息。
• 保护：无需注册，通过保密协议、物理隔离等方式保护。
• 侵权：盗窃、泄露、违反保密义务使用他人商业秘密。

1.5 反不正当竞争法

• 适用范围：商业混淆、虚假宣传、商业诋毁、侵犯商业秘密等。

1.6 商标法

• 商标注册：区分商品或服务来源的标志，注册后享有专用权。
• 保护期限：10年，可续展。

1.7 常见法律风险与合规

• 开源许可证：GPL（传染性）、Apache（宽松）、MIT（最宽松）的合规要求。
• 出口管制：加密技术出口需符合国家规定。

---

2. 专业英语

2.1 考察形式

• 共5道选择题，每题含一段英文短文或填空题，内容涉及：
  • 软件架构概念（如"4+1" view, architectural style）
  • 设计模式（如 Singleton, Observer）
  • 安全术语（如 encryption, authentication）
  • 开发方法（如 Agile, DevOps）
• 常见题型：选择与短文意思一致的选项、选择合适的单词填空。

2.2 核心术语（高频）

英文术语	中文
architectural style	架构风格
quality attribute	质量属性
availability	可用性
scalability	可扩展性
maintainability	可维护性
coupling / cohesion	耦合 / 内聚
design pattern	设计模式
microservices	微服务
containerization	容器化
orchestration	编排
encryption	加密
decryption	解密
authentication	认证
authorization	授权
non-repudiation	不可否认性
vulnerability	漏洞
throughput	吞吐量
latency	延迟

2.3 备考建议

• 熟记《系统架构设计师教程（第2版）》附录中的英文术语。
• 阅读历年代码题中的英文描述，熟悉技术词汇在上下文中的用法。
• 不需要额外背单词，重点掌握技术术语的中英文对应。

---

3. 典型例题

例题1（著作权）

题目 ：某公司程序员小张利用业余时间独立开发了一款软件，未使用公司的设备和技术资料，则该软件的著作权属于（ ）

A. 小张

B. 小张所在公司

C. 小张和公司共同所有

D. 国家

解析：根据《计算机软件保护条例》，非职务开发且未利用单位资源，著作权归开发者个人。答案：A。

例题2（开源许可证）

题目 ：以下开源许可证中，具有"传染性"特点的是（ ）

A. MIT

B. Apache

C. GPL

D. BSD

解析：GPL要求衍生作品也必须以GPL方式开源，具有强传染性。答案：C。

例题3（商业秘密）

题目 ：以下关于商业秘密的说法，错误的是（ ）

A. 商业秘密无需公开即可获得保护

B. 商业秘密的保护期限是有限的

C. 商业秘密需采取保密措施

D. 侵犯商业秘密可能承担法律责任

解析：商业秘密保护无固定期限，只要符合条件且未公开，可永久保护。答案：B。

例题4（专业英语）

题目 ：The ability of a system to continue functioning in the event of a failure is called ______.

A. security

B. reliability

C. availability

D. maintainability

解析：系统在故障时仍能继续运行的能力是可用性（availability）。答案：C。

---

4. 备考策略与重点提示

知识点	常见题型	备考建议
著作权归属	选择题	区分职务开发、委托开发、合作开发的权利归属
保护期限	选择题	记忆著作权（50年）、专利（20/10年）、商标（10年）
开源许可证	选择题	了解GPL、Apache、MIT、BSD的核心差异
专业英语	选择题	熟悉技术术语英文表达，结合上下文理解

特别提醒：法律法规部分考法直接，以记忆为主，重点掌握著作权归属、侵权判定、保护期限。专业英语无需花大量时间，考前熟读教程附录术语即可。

---