核心知识点

第1章 绪论

第2章 计算机系统基础知识

基础知识

真实程序、核心程序、小型基准程序和合成基准程序，其评测准确程度依次递减。

把应用程序中用得最多、最频繁的那部分核心程序作为评估计算机系统性能的标准程序，称为基准测试程序(benchmark)。

关键成功因素法（CSF）：通过分析找出使得企业成功的关键因素，然后再围绕这些关键因素来确定系统的需求,并进行规划。在现行系统中，总存在着多个变量影响系统目标的实现，其中若干个因素是关键的和主要的（即关键成功因素）。通过对关键成功因素的识别，找出实现目标所需的关键信息集合，从而确定系统开发的优先次序。关键成功因素来自于组织的目标，通过组织的目标分解和关键成功因素识别、性能指标识别，一直到产生数据字典。

企业应用集成（EAI）构建统一标准的基础平台，将进程、软件、标准和硬件联合起来，连接具有不同功能和目的而又独自运行的企业内部的应用系统，以达到信息和流程的共享，使企业相关应用整合在一起。

EAI就是在各个应用系统的接口之间共享数据和功能。

EAI的基本原则就是集成多个系统并保证系统互不干扰，也就是独立性。

EAI提供4个层次的服务，从下至上依次为通信服务、信息传递与转化服务、应用连接服务、流程控制服务。

操作系统

页面大小为4K，逻辑地址为十六进制5148H

可以推出其页号为5，页内地址为148H（4K=2^12，后12位即为页内地址/偏移量）

页面淘汰原则：未访问-未修改

• 访问标志（Access bit）用来判断该页是否“活跃”，影响是否被优先保留

• 修改标志（Dirty bit）用来判断淘汰时是否需要写回磁盘，影响淘汰成本。

页式存储管理：像把一本书按“页数”强制裁剪成等大小纸片，便于管理但不考虑内容逻辑（固定大小（如4KB））

段式存储管理：像一本书按“章节”分（代码段、数据段、栈段等），逻辑划分清晰（不固定，按逻辑划分）

段页式存储管理：先将程序划分为段，每段再划分为页，结合两种优点。

• 内部中断：由CPU在执行指令过程中检测到错误或特殊情况引起
  • 溢出中断：这通常是由于指令执行过程中的条件满足（如算术溢出等）而引发的中断。
• 外部中断：这是由外部事件引发的中断，如硬件设备的输入输出、定时器到达等。
• 访管中断(软终端)：用于在用户态下请求操作系统内核提供服务或执行特权操作。
• 信号中断：信号通常用于进程间的通信或通知进程某些事件的发生。

计算机网络

在 TCP/IP 网络中：

• IP地址：用于定位哪台主机
• 端口号：用于定位主机上的哪个进程/服务

DHCP协议允许服务器向客户端动态分配 IP 地址和配置信息。

在一个网段中可以配置多台DHCP服务器，默认关闭，可以服务多个子网。

• SMTP：25端口，邮件发送
• POP3：110端口，邮件收取，收取后服务器删除
• IMAP：143端口，邮件同步，收取后服务器保留
• HTTP：80端口，超文本传输协议，网页传输
• HTTPS：443端口，安全的 HTTP（SSL/TLS 加密）

(物链)网输(会示用)

• 应用层：SMTP, POP3, FTP(20/21), Telnet, HTTP, DHCP(67), DNS(53)
• 传输层：TCP, UDP
• 网络层：IP, ICMP, IGMP, ARP, RARP
• 网络接口层

路由器工作在网络层

交换机工作在数据链路层

磁盘管理

最短移臂调度算法：先根据柱面找最近的，再根据扇区号由小到大

• 柱面号：所有盘面上在同一位置的磁道集合 就组成了一个“柱面”
• 磁头号：指定读取哪个盘面（哪一个磁头）
• 扇区号：指定某个磁道上的哪一个小区域

嵌入式

安全攸关系统：是指系统失效会对生命或者健康构成威胁的系统，存在于航空、航天、汽车、轨道交通等领域，对安全性要求很高，通常在需求分析阶段就必须考虑安全性需求。

安全性需求:是指通过约束软件的行为，使其不会出现不可接受的违反系统安全的行为需求。

需求本身就是根据已知的系统信息来进行获取的。

最早截止期调度算法：优先解决已经逾期或最早需要处理的任务，以最快解决潜在的延误问题。

最晚截止期调度算法：优先处理当前的紧急任务，以防任务逾期。

混成系统：一般由离散分离组件和连续组件并行或串行组成，组件之间的行为由计算模型进行控制。

第3章 信息系统基础知识

电子政务

• 政府对政府G2G：基础信息的采集、处理和利用（人口信息采集）
• 政府对企业G2B：向企(事)业单位发布的各种方针、政策、法规、行政规定
• 政府对居民G2C：面向居民所提供的服务（户口、各种证件和牌照的管理，图书馆、学校）
• 企业对政府B2G：应向政府缴纳的各种税款，向政府供应各种商品和服务，建议
• 居民对政府C2G：除了包括个人应向政府缴纳的各种税款和费用，按政府要求应该填报的各种信息和表格，以及缴纳各种罚款等外，更重要的是开辟居民参政、议政的渠道。（报警服务）

第4章 信息安全技术基础知识

计算机信息系统安全保护等级：

• 用户自主保护级：为用户提供可行的手段，保护用户和用户组信 息，避免其他用户对数据的非法读写与破坏。
• 系统审计保护级：实施了粒度更细的自主访问控制
• 安全标记保护级：具有系统审计保护级所有功能，还提供有关安全策略模型、数据标记以及主体对客体 强制访问控制的非形式化描述；具有准确地标记输出信息的能力；消除通过测试发现的任何错误。
• 结构化保护级：本级的计算机信息系统可信计算基必须 结构化为关键保护元素和非关键保护元素。
• 访问验证保护级：本级的计算机信息系统可信计算 基满足访问监控器需求。访问监控器仲裁主体对客体的全部访问。

安全审计涉及四个基本要素：控制目标、安全漏洞、控制措施和控制测试。

第5章 软件工程基础知识

软件生命周期

• 软件定义
  • 问题定义
  • 可行性研究
  • 需求分析
• 软件开发
  • 概要设计：模块划分以及模块间接口设计（将软件需求转化为数据结构和软件系统结构）
  • 详细设计：模块内部设计（过程设计，通过对结构细化，得到软件详细数据结构和算法）
  • 编码
  • 测试（属于开发）
• 软件运行和维护

软件生命周期模型又称软件开发模型(software develop model)或软件过程模型(softwareprocess model)，它是从某一个特定角度提出的软件过程的简化描述。

软件过程模型的基本概念：软件过程是制作软件产品的一组活动以及结果，这些活动主要由软件人员来完成，软件活动主要有如下一些：

1. 软件描述：必须定义软件功能以及使用的限制。
2. 软件开发：也就是软件的设计和实现，软件工程人员制作出能满足描述的软件。
3. 软件有效性验证：软件必须经过严格的验证，以保证能够满足客户的需求。
4. 软件演化：改进软件以适应不断变化的需求。

常见的开发模型

• 瀑布模型：因果关系紧密相连，前一阶段的输出是后一阶段的输入。优点是流程规范化，有利于评审；缺点是过于理想，缺乏灵活性，容易产生需求偏差。
• 快速原型模型：适用于需求不够明确的项目。通过快速地建立一个能够满足用户需求的软件原型，提供用户使用，再根据用户的反馈结果进行修改，能够充分实现用户的参与和决策。根据原型是否抛弃，分为抛弃型原型和演化型原型。
• 增量模型：将软件产品划分成为一系列的增量构件，分别进行设计、编码、集成和测试。
• 螺旋模型：结合了瀑布模型和原型模型的优点，最主要的特点在于加入了风险分析。它是由目标设定、风险分析、开发和有效性验证、评审这4个部分组成。
• 喷泉模型：主要用于描述面向对象的开发过程，最主要的特点是迭代。所有的开发活动没有明显的边界，允许各种开发活动交叉进行。
• 敏捷方法：核心思想在于适应型、以人为本、迭代增量式的开发过程。在敏捷方法中，软件项目的构建被切分成多个子项目，各个子项目成果都经过测试，具备集成和可运行的特征。在敏捷方法中，从开发者的角度来看，主要的关注点有短平快的会议、小版本发布、较少的文档、合作为重、客户直接参与、自动化测试、适应性计划调整和结对编程；从管理者的角度来看，主要的关注点有测试驱动开发、持续集成和重构。
• 统一过程(RUP)：是用例驱动、以架构为中心、迭代和增量的软件开发过程，有9个核心工作流：业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境。

CMMI

CMMI(Capability Maturity Model Integration for Software, 软件能力成熟度模型集成)：

• 初始级：过程随意且混乱
• 已管理级：有组织有目标
• 已定义级：标准流程、制度化，开始项目累计，企业资产的收集
• 量化管理级：对过程性能的可预测
• 优化级：使用从多个项目收集来的数据对整体的组织级绩效进行关注

体系文件的层次结构从上到下分别为：

1. 顶层方针
2. 过程文件
3. 规程文件
4. 模板类文件

UML

UML（Unified Modeling Language，统一建模语言）是一种用于面向对象软件系统分析与设计的标准建模语言，它通过一套标准图形符号，帮助开发者、架构师、项目经理等人员描述、设计、沟通系统结构和行为。

组成要素：

• 事物
  • 结构事物：UML模型的静态部分
  • 行为事物：UML模型的动态部分
  • 分组事物：UML模型的组织部分
  • 注释事物：UML模型的解释部分
• 关系
  • 依赖：一个事物的变化会影响另一个事物（虚线箭头）
  • 关联：类与类之间的关系（实线）
    • 聚集：弱拥有，部分可以离开整体而存在（实线+空心菱形）
    • 组合：强拥有，部分离开整体不可以存在（实线+实心菱形）
  • 泛化：父子元素，特殊/一般的关系（实线+空心三角形）
  • 实现：类（或组件）实现了接口所定义的方法（虚线+空心三角形）
• 图（只列举了重要的）
  • 类图：类、类的特性以及类之间的联系
    • 类之间的关系（就是UML的关系，不包括实现）
      • 依赖：一个类使用到另一个类
      • 关联：一个类与另一个类之间有“拥有”关系，但不是整体-部分。
      • 聚集：一种弱“整体-部分”关系，部分可以脱离整体单独存在。
      • 组合：一种强“整体-部分”关系，部分不能脱离整体单独存在。
      • 泛化：表示继承关系，一个类是另一个类的子类。
  • 用例图：展现一组用例、参与者以及它们之间的关系
    • 参与者不一定是人，还可以是硬件设备，甚至是时间
    • 关系
      • 用例之间
        • 拓展关系：根据情况可能有多个分支
        • 包含关系：可提取公共行为
        • 泛化关系（继承关系）：共性抽象为父用例
      • 参与者与用例之间
        • 关联关系
      • 参与者与参与者之间
        • 泛化关系（继承关系）：共性抽象为父用例
  • 序列图（顺序图）：消息的时间顺序
    • 消息
      • 同步消息：发送方等待接收方完成处理
      • 异步消息：发送方无需等待接收方完成处理
      • 返回消息：响应结果返回给发起方
    • 结构化控制
      • alt：条件分支
      • opt：可选行为
      • loop：循环
      • break：中断
      • par：并行
  • 协作图（通信图）：对象之间的连接关系
  • 活动图：从一个活动到另一个活动的流程
  • 状态图：对象状态及其转换

“4+1”视图模型：

• 逻辑视图：最终用户（类图）
• 实现视图：程序员
• 用例视图：分析测试人员
• 进程视图：集成人员
• 部署视图：系统工程师

另一种表述：逻辑视图、进程视图、开发视图、物理视图和统一的场景

流程图的环形复杂度=判定节点数+1

COM支持两种形式的对象组装：

• 包含：一个对象拥有指向另一个对象的唯一引用。

• 聚集：直接把内部对象接口引用传给外部对象的客户，而不是再转发请求。

项目管理

甘特图Gantt图：清晰描述每个任务开始时间和结束时间

项目活动图PERT图：描述任务和任务之间的依赖关系

关键路径：距离最长的一条路径

活动节点

最早开始时间|工期|最早完成时间

最迟开始时间|总浮动时间|最迟完成时间

口诀：正退取前面的最大值，反推取后面的最小值

最早开始时间 = max(前置活动的最早完成时间)

最迟完成时间 = min(后置活动的最迟开始时间)

总浮动时间 = 最迟开始时间-最早开始时间 或 最迟完成时间=最迟开始时间

需求工程

需求工程包括需求开发和需求管理两大类活动。

需求开发包括：需求获取，需求分析，需求定义，需求验证。

需求管理包括：变更控制、版本控制、需求跟踪和需求状态跟踪。

需求开发的结果应该有项目视图和范围文档、用例文档和SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定，它是需求开发和需求管理之间的桥梁。

需求变更管理的流程：

1. 问题分析和变更描述：这是识别和分析需求问题者一份明确的变更提议，以检查它的有效性，从而产生一个更明确的需求变更提议。
2. 变更分析和成本计算：使用可追溯性信息和系统求的一般知识，对需求变更提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并且确认，应该进行是否执行这一变更的决策。
3. 变更实现：这要求需求文档和系统设计要同时修改。如果先对系统的程序做变更，然后再修改需求以及实现者文档，这几乎不可避免地会出现需求文档和程序的不致。

系统分析与设计

结构化方法

结构化分析的常用手段是数据流图DFD和数据字典。

• 数据流图
  • 四种基本要素
    • 数据流：用一个箭头表示数据流向（箭头）
    • 处理（加工）：对数据进行加工或转换（圆形）（一般用动宾结构或者动词）
      • 黑洞：有输入无输出
      • 奇迹：无输入有输出
      • 灰洞：输入不足以产生输出
    • 数据存储：用数据库或文件形式存储的数据（矩形框少一边）
    • 外部项：数据源或者数据终点，数据的使用者（矩形框）
  • 数据平衡原则
    • 层间平衡：父子图数据流保持一致
    • 图内平衡：每一个加工都有输入输出，避免出现黑洞、奇迹、灰洞。
• 数据字典：描述数据的信息集合

E-R图（实体-联系图）：描述现实世界的概念模型

• 实体：矩形框（不能直接用某表，某表是某实体的实现）

• 属性：椭圆形框

• 联系：菱形框

  • 一对一联系
  • 一对多联系
  • 多对多联系

• 实体：数据以及该数据的相关属性

• 类：是数据和行为的封装体

软件结构化设计

• 架构设计（结构设计）：定义软件系统各主要部件之间的关系。
• 接口设计（人机界面交互）：软件内部，软件和操作系统间以及软件和人之间如何通信。
• 数据设计：将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性。
• 过程设计：系统结构部件转换成软件的过程描述。确定软件各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法。

内聚类型（由高到低，越上面越好）：

• 功能内聚：完成单一功能，各部分协同工作
• 顺序内聚：处理元素相关，顺序执行
• 通信内聚
• 过程内聚：处理元素相关，特定次序执行
• 时间内聚：同一时间间隔内执行
• 逻辑内聚
• 偶然内聚

耦合类型（由低到高，越上面越好）：

• 非直接耦合
• 数据耦合
• 标记耦合
• 控制耦合
• 通信耦合
• 公共耦合
• 内容耦合

接口的定义不仅仅属于其模块自身的内部特性，与外部模块也具有相关性。

面向对象方法

• 对象模型：对象以及对象之间的关系（发生的客体）

• 动态模型：时间和操作顺序（什么时候发生）

• 功能模型：描述从输入到输出的过程（发生了什么）

• Essential Use Cases(本质用例): 用于早期需求分析阶段。抽象的，与技术无关。

• Real Use Cases(现实用例): 用于系统设计和实现阶段。具体的，贴近界面和实现。

软件开发方法

• 从开发风范上看
  • 自顶向下的开发方法：先对最高层次中的问题进行定义、设计、编程和测试，而多其中未解决的问题作为一个子任务放到下一层次中去解决
  • 自底向上自开发方法：根据系统功能要求，从具体的器件、逻辑部件或者相似系统开始，通过对其进行相互连接、修改和扩大，构成所 要求的系统
• 从性质上看
  • 形式化方法：具有坚实数学基础的方法，从而允许对统和开发过程做严格处理和论证，适用于那些系统安全级别要求极高的软件的开发。
  • 非形式化方法：不把严格性作为其主要着眼点，通常以各和开发模型的形式得以体现。

软件测试

• 黑盒测试：不考虑内部，对软件界面和软件功能进行测试。

• 白盒测试：是从程序结构方面出发对测试用例进行设计。

  • 常用的白盒测试法有控制流分析、数据流分析、路径分析、程序变异等。
  • 测试用例的覆盖程度从低到高：(两个判定，每个判定有两个条件，T表示判定为True，t表示条件为true)
    • 语句覆盖：确保每一行代码都被至少执行一次
    • 判定覆盖（分支覆盖）：确保每个判定语句的每个分支都被至少执行一次（TT, FF）
    • 条件覆盖：每个条件至少有一次真值、有一次假值(tttt, ffff)
    • 判定条件覆盖：每个条件所有的可能取值至少执行一次（条件覆盖），同时每个判断本身所有的结果也要至少执行一次（判定覆盖）
    • 条件组合覆盖：每个判定中的各个条件的各种可能组合都至少出现一次(tftf, tttt, ffff, ftft)
    • 路径覆盖：覆盖程序中所有可能的执行路径（不能替代条件覆盖和条件组合覆盖）

• 灰盒测试：除了重视输出相对于输入的 正确性，也看重其内部的程序逻辑。

• 单元测试：各模块单独测试

• 集成测试：模块组装起来同时进行测试

• 系统测试：采用黑盒测试

  • 功能测试
  • 性能测试
  • 验收测试
  • 压力测试

性能测试：

• 负载测试：各种负载环境
• 压力测试：测上限，瓶颈
• 强度测试：测下限，限定资源
• 容量测试：并发、同时在线

自动化测试脚本：

• 线性脚本：录制手工执行的测试用例得到的脚本。

• 结构化脚本：类似于结构化程序设计，具有各种逻辑结构、函数调用功能。

• 共享脚本：共享脚本是指可以被多个测试用例使用的脚本，也允许其他脚本调用。

• 数据驱动脚本：将测试输入存储在数据文件中，而不是存储在脚本中。

• 关键字驱动脚本：是数据驱动脚本的逻辑扩展。它将数据文件变成测试用例的描述，采用一些关键字指定要执行的任务。

• Alpha测试：是在开发环境下进行的测试，由用户内部用户模拟实际操作环境下进行的受控测试。

• Beta测试：是用户在实际使用环境下进行的测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

• 验收测试是向未来的用户表明系统能够像预定要求那样工作。

• 回归测试的目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其它规定的要求的不损害性。

软件维护

• 正确性维护【修BUG】：识别和纠正软件错误/缺陷，测试不可能发现所有错误。
• 适应性维护【应变】：指使应用软件适应环境变化【外部环境、数据环境】而进行的修改。
• 完善性维护【新需求】：扩充功能和改善性能而进行的修改。
• 预防性维护【针对未来】：为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使系统适应各类变化而不被淘汰。经典实例：【专用】改【通用】。

基于构件的软件工程

构件有3个核心特点：

1. 独立部署单元；
2. 作为第三方的组装单元；
3. 没有（外部的）可见状态。

构件分类方法：

1. 关键字分类法：根据领域分析的结果将应用领域的概念按照从抽象到具体的顺序逐次分解为树形或有向无回路图结构。
2. 刻面分类法：利用Facet（刻面）描述构件执行的功能、被操作的数据、构件应用的语境或任意其他特征。
3. 超文本方法：基于全文检索技术，使得检索者在阅读文档过程中可以按照人类的联想思维方式任意跳转到包含相关概念或构件的文档。

构件分类：

• 独立而成熟的构件：数据库系统、操作系统
• 有限制的构件：基础类库
• 适应性构件：兼容性（ActiveX）
• 装配的构件：大多数软件提供商提供的软件
• 可修改的构件：版本替换

构件组装方式：

• 顺序组装
• 层次组装
• 叠加组装

构件组装技术：

• 基于功能的：侧重功能需求来组装
• 基于数据的：根据核心数据设计框架，然后根据框架中各个结点的需求提取构件
• 面向对象：封装、继承、多态，更好的支持软件复用

不兼容情况：

• 参数不兼容：操作用相同的名字，但参数类型和个数不同
• 操作不兼容：操作名不同
• 操作不完备：提供的接口是请求接口的子集，或者相反

接口是一个已命名的一组操作的集合。

逆向工程

逆向工程导出的信息可分为如下4个抽象层次:

1. 实现级：包括程序的抽象语法树、符号表等信息。
2. 结构级：包括反映程序分量之间相互依赖关系的信息。
3. 功能级：包括反映程序段功能及程序段之间关系的信息。
4. 领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息。

非功能需求

• 操作性需求：技术环境需求、系统集成需求、可移植性需求、维护性需求
• 性能需求：速度需求、容量需求、 可信需求
• 安全性需求：系统价值需求、访问控制需求、加密/认证需求、病毒控制需求
• 文化需求：多语言需求、个性化定制需求、规范性描述需求、法律需求

三层CS结构可以满足操作性需求和文化需求。

遗留系统

• 高水平、高价值：改造
• 高水平、低价值：集成
• 低水平、高价值：继承
• 低水平、低价值：淘汰

Web 系统设计

• 从架构来看：MVC, MVP, MVVM, REST, Webservice, 微服务

• 从缓存来看：MemCache, Redis, Squid

• 从并发分流来看：集群(负载均衡)、CDN

• 从数据库来看：主从库(主从复制), 内存数据库, 反规范化技术, NoSQL, 分区(分表)技术, 视图与物化视图。

• 从持久化来看：Hibernate, Mybatis

• 从分布存储来看：Hadoop, FastDFS, 区块链

• 从数据编码看：XML, JSON

负载均衡：

• 应用层实现：
  • HTTP重定向：请求转发。实现简单，但性能较差。
  • 反向代理服务器：由反向代理服务器转发。部署简单，但代理服务器可能成为性能瓶颈（Apache, Nginx）
• 传输层实现：
  • DNS域名解析：由DNS服务器给出解析地址，控制权在域名服务商那里。
  • 基于NAT：将一个外部IP映射为多个IP地址，每次请求动态转化为一个内部地址。技术成熟（四层交换机）

CDN(Content Delivery Network, 内容分发网络)利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，主要加速静态资源。

REST(Representational State Transfer, 表述性状态转移)将Web应用程序的功能作为资源来表示，使用统一资源标识符URI来对资源进行操作。、

REST是一种设计风格而不是一个架构。

RESTful是遵循REST原则的Web服务，是REST的形容词。

REST的核心概念：

• 资源：借助URI标识Web上的资源。资源和URI是一对多关系。
• 表述：描述资源在Web上某一个时间的状态。常用的表现形式有HTML, JSON, XML, 纯文本。
• 状态转移：包括应用状态和资源状态（客户端和服务端交互必须是无状态的）
  • 应用状态：客户端维护
  • 资源状态：服务器维护
• 超链接：嵌入链接和其他资源建立联系

REST的主要特点：

• 无状态性：服务端不保存客户端的状态信息。每次请求自带相应内容。
• 缓存：允许客户端对响应进行缓存。
• 统一接口：服务端和客户端之间通过统一的接口进行交互。
• 分层系统：服务端和客户端通过中间层进行通信。
• 客户端-服务器：客户端发送请求，服务端接受并处理返回响应。两者之间是松耦合的。

微服务：将一个大型的单个应用或服务划分为一组微型、可独立部署的服务。

每个服务可以独立开发、管理和迭代，彼此之间使用统一接口进行交流。

优势：

• 复杂应用解耦
• 独立
• 技术选型灵活
• 容错
• 松耦合、易扩展

微服务架构带来的挑战：

• 并非所有系统都能转成微服务
• 部署更复杂
• 性能问题
• 数据一致性问题

XML：通用性强；复杂不宜维护

JSON：数据格式简单，易维护；通用性没有XML好

• 有状态服务：服务器保存数据，前后请求有关联
• 无状态服务：服务器不保存数据，单词请求包含所有信息

第6章 数据库设计基础知识

数据库模式

• 外模式：视图级
• 概念模式：表级
• 内模式：文件级

聚簇索引会影响内模式

数据库设计过程

• 需求分析：需求说明文档、数据字典、数据流图
• 概念结构设计：ER模型（实体集之间的关系：1:1;1:*;*:*;）
• 逻辑结构设计：规范化理论、关系模式
• 物理设计
  • 实体完整性约束：主键唯一且非空
  • 参照完整性约束：外键要么为空，要么是其他关系的主键
  • 用户自定义完整性约束

ER图集成时产生的冲突及解决办法：

• 属性冲突：包括属性域冲突和属性取值冲突。

• 命名冲突：包括同名异义和异名同义。

• 结构冲突：包括同一对象在不同应用中具有不同的抽象，以及同一实体在不同局部E-R图中所包含的属性个数和属 性排列次序不完全相同。

• 闭包：是一个操作，表示一个属性集可以推导出哪些属性。

• 候选码：是一个结果，表示哪些属性集能唯一标识一个元组，是数据库设计中用于做主键的候选项。

元组也称为行。

关系代数

• 交
• 并
• 差
• 投影：选择列（π）
• 选择：选择行（σ）
• 笛卡尔积：列数为两者之和，行数为两者之积（×）
• 自然连接：列数为两者之和（去重），行数为同名属性列相等行数（⋈）

关系操作中，操作的对象和结果都是集合。

规范化理论

• 1NF：属性不可分割
• 2NF：消除非主属性对候选键的部分依赖
• 3NF：消除非主属性对候选键的传递依赖
• BCNF：消除主属性对候选键的部分和传递依赖

保持函数依赖：所有原始依赖能从子模式依赖并集中推导出

无损连接：两个子模式的交集属性能决定其中一个完整子模式

反规范化

• 冗余列：多个表中保留相同的列
• 派生列：增加可以由其他列计算出来的列
• 表重组：两个表组成一个表
• 表分割
  • 水平分割
  • 垂直分割

反规范化会带来数据不一致的问题：

• 应用程序同步
• 批量处理同步
• 触发器同步

事务

四大特性 ACID：

• 原子性 Atomicity：要么全部完成，要么全部不完成。undo log 回滚日志来保证的。
• 一致性 Consistency：操作前后，数据满足完整性约束。通过 持久性 + 原子性 + 隔离性 来保证；
• 隔离性 Isolation：每个事务都有一个完整的数据空间，对其他并发事务是隔离的。MVCC或锁机制来保证的。（重点）
• 持久性 Durability：事务结束后，数据修改是永久的。 redo log 重做日志来保证的。

分布式数据库

全局概念模式 是整个分布式数据库系统中统一的数据视图，描述了系统中所有数据的逻辑结构，不关心数据的物理存储位置和访问方式。

全局外模式 是特定用户或应用程序所看到的全局数据库的子集视图，是在全局概念模式的基础上构建的“定制化视图”。

• 可用性：故障仍可用
• 自治性：局部DBMS
• 共享性：数据共享
• 分布性：不同场地存储
• 透明性：用户不关心
  • 分片透明：是否分片、怎么分片
    • 水平分片：按记录
    • 垂直分片：按字段
  • 位置透明：存放在哪里
  • 复制透明：数据的复制与同步
  • 逻辑透明：局部DBMS支持什么格式

两阶段提交协议 2PC

2PC事务

• 表决阶段：所有参与者同意提交才提交，有一个撤销就得撤销
• 执行阶段：协调者根据表决结果执行

MySQL

索引类型

• 按「数据结构」分类：B+树索引、Hash索引、Full-text索引（倒排索引）
  • InnoDB 和 MyISAM 都只支持 B+树索引 和 Full-text 索引
  • Memory 只支持 B+树索引和 hash索引
• 按「物理结构」分类：聚簇索引（主键索引）、二级索引（辅助索引）
  • 主键索引叶子节点放的是所有数据
  • 二级索引叶子结点放的是主键值（回表）
• 按「字段特性」分类：主键索引、唯一索引、普通索引、前缀索引
  • 主键索引：建立在主键字段上的索引
  • 唯一索引：建立在 unique 字段上的索引
  • 普通索引：建立在普通字段上的索引（不为主键不为 unique）
  • 前缀索引：针对字符串类型字段前几个字符建立的索引（减少索引的存储空间）
• 按「字段个数」分类：单列索引、联合索引
  • 单列索引：建立在一个字段上的索引
  • 联合索引：建立在多个字段上的索引
    • 最左匹配原则：按照最左有限的方式进行索引匹配
    • 不遵循 最左匹配原则 会导致索引失效
    • 最左匹配原则匹配到范围查询就停止匹配，即 范围查询后面的字段无法用到联合索引

索引下推：部分查询条件下推到存储引擎层进行过滤，而不是服务层过滤，减少 IO

覆盖索引：二级索引中包含了要查询的所有列

MySQL 的主从复制依赖于 bin log ，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上。复制的过程就是将 binlog 中的数据从主库传输到从库上。

这个过程一般是异步的，也就是主库上执行事务操作的线程不会等待复制 bin log 的线程同步完成。

主从复制过程：

• 写入 Bin log：主库写 binlog 日志。
• 同步 Bin log：从库创建 I/O 线程连接主库的 log dump 线程，接收 bin log 并写到 relay log 中。
• 回放 Bin log：从库创建 SQL 线程，回放 relay log，同步数据。

主从复制类型：

• 异步复制：主库不需要等待从库响应
• 同步复制：主库需要等待所有从库响应
• 半同步复制：主库需要等待部分从库响应，通过配置参数

基于MySQL的分布式锁的缺点：

• 性能瓶颈：高并发场景下，数据库性能下降
• 单点故障：数据库出现故障将导致分布式锁失效
• 拓展性差：单个数据库无法满足大规模的系统
• 锁粒度问题：锁粒度可能过大或过小，不好控制
• 数据一致性差：不同节点之间的数据同步存在延迟或不一致

并发问题：

• 脏读：读到其他其他事务未提交数据
• 不可重复读：查询结果不同
• 幻读：查询结果的记录数量不同

事务的隔离级别：

• 读未提交：事务没提交时，所做的变更就能被其他事务看到
• 读已提交：MVCC，提交后才能看到 （解决了脏读）
• 可重复读：MVCC，事务看到的数据和启动该事务时保持一致（解决了脏读 和 不可重复读，很大程度上避免了 幻读，默认的隔离级别）
  • 快照读(普通查询，读取进入事务时候的快照)通过 MVCC 避免幻读
  • 当前读(select ... for update, update, insert, delete ，读取最新数据）通过引入临键锁避免幻读
  • 幻读发生的场景：
    • A快照读记录为空，B新增记录x提交，A更新该条记录，A快照读查到记录数据
    • A快照读查范围数据n条，B新增记录x提交，A当前读再查范围数据 n + 1 条
  • 为了避免上述两种场景，在开启事务后，需要尽快执行当前读
• 串行化：加锁，后访问的事务必须等前一个事务执行完成才能执行（解决了脏读、不可重复读 和 幻读）
  • 普通查询也会对记录加 S 型 next-key 锁

数据分片：

• 水平分片：元组分裂为多个子集
• 垂直分片：属性分裂为多个子集
• 导出分片：水平分片的条件不表示本关系属性的条件，而是其他关系属性的条件
• 混合分片：采取水平分片和垂直分片两种形式混合

分布透明性：

• 分片透明性：用户了解操作不用了解分片
• 位置透明性：用户了解分片情况不用了解存储场地
• 局部数据模型透明性：用户了解存储场地不用了解局部场地使用何种数据类型

Redis

数据结构

• Key

• Value

  • String：字符串、整数或浮点数

    • 底层结构：int 和 SDS（len值保存长度，可以存二进制数据）
    • 应用场景：缓存对象、分布式锁
    • 常用指令：
      • set username:1 jim
      • SET lock_key unique_value NX PX 10000nx参数保证只在key不存在时操作,px为过期时间，释放锁

  • List：一个链表，每个节点都包含一个字符串

    • 底层结构：压缩列表（元素个数小于 512 个，每个元素小于 64字节），双向链表。3.2版本后用 quicklist 实现
    • 应用场景：消息队列
    • 常用指令：
      • LPUSH + BRPOPLPUSH 实现消息队列
        • 消息队列的三大需求：消息保序、处理重复的消息和保证消息可靠性
        • 一边进一边出 保证了消息保序
        • BRPOPLPUSH 保证了阻塞读取，避免一直请求。以及消息者消费后备份消息，保证消息可靠。
        • 缺陷：不支持消费组实现，组内消费者分担消息消费，组间消费者可以重复消费（Stream 支持）
      • LPUSH mq "111000102:stock:99"（111000102 为消息id，保证了消息不重复）
      • BRPOPLPUSH mq mq_bak 1010为超时时间，将mq的最右元素返回并弹出到mq_bak

  • Hash：键值对集合

    • 底层结构：压缩列表（元素个数小于 512 个，每个元素小于 64字节），哈希表。7.0版本后用 listpack 实现
    • 应用场景：购物车(cart_id,[{iphone 11, 5599}, {apple watch s4, 2299}])
      • 也可以用 String 实现，String 保存一个 JSON 字符串即可。如果数据变更频繁就用 hash。
    • 常用指令：
      • HSET uid:1 name jim
      • HGET uid:1 name

  • Set：无序并唯一字符串

    • 底层结构：整数集合（元素个数小于 512 个），哈希表
    • 应用场景：点赞、共同关注（交并差集操作）
    • 常用指令：
      • SADD article:1 uid:1添加
      • SREM article:1 uid:1删除

  • ZSet：有序并唯一键值对(浮点数-字符串，根据浮点数排序)

    • 底层结构：压缩列表（元素个数小于 128 个，每个元素小于 64 字节），跳表。7.0后用 listpack 实现
    • 应用场景：排行榜
    • 常用指令：
      • ZADD read:ranking 200 jim 添加 注意是 分数 在前
      • ZREVRANGE read:ranking 0 2 WITHSCORES展示阅读量前三的人及其分数

  • BitMap：一连串的二进制数组（占用空间小）

    • 底层结构：Redis 的 String ，但只能保存二进制 0 或 1
    • 应用场景：签到统计
    • 常用命令：
      • setbit uid:sign:1:202409 2 12为偏移量，用来定位，记录用户9月3日已签到
      • getbig uid:sign:1:202409 2 查询

  • HyperLogLog：提供不精确的去重计数

    • 底层结构：比较复杂
    • 应用场景：百万级uv计数
    • 常用命令：
      • pfadd page1:uv user1 usr2添加两个访问用户
      • pfcount page1:uv计数

  • GEO：存储地理位置信息

    • 底层结构：和 zset 一致
    • 应用场景：滴滴打车
    • 常用命令：
      • GEOADD cars:locations 116.034579 39.03045 33 写入车辆经纬度信息，33是id
      • GEORADIUS cars:locations 116.000000 39.000000 5 km ASC COUNT 10返回10个 5km内最近的车辆信息

  • Stream：专门为消息队列设计，支持发布订阅模式、消费组、自动生成唯一ID、自动保存消费者读取消息并在消费成功后返回确认消息等功能

    • 应用场景：消费队列（但仍存在消息丢失和消息积压的问题）
    • 常见命令：
      • XADD mq * name xiaolin 表示生成唯一ID
      • XGROUP CREATE mymq group1 0-0创建名为group1的消费者，并从第一条消息开始读取
      • XREADGROUP GROUP group1 consumer1 STREAMS mymq >group1中的consumer1消费者开始消费，> 表示从第一条未读消息开始

缓存穿透、缓存击穿和缓存雪崩

• 缓存穿透：查询数据库也不存在的数据

  • 解决方案：
    • 非法请求限制
    • 缓存空值：数据库不命中后即在数据库中缓存空值
      • 消耗内存，通过设置较短过期时间。
      • 数据不一致，过期时间内数据库新增该数据。得通过消息队列或者其他异步方式清理缓存空值。
    • 布隆过滤器：布隆过滤器没有的，数据库一定没有

• 缓存击穿：某个热点数据缓存过期，大量请求打到数据库（可以认为是缓存雪崩的子集）

  • 解决方案：
    • 加锁查询：查询数据库时加锁，防止并发查询，查到后写入数据库。
    • 热点数据永不过期

• 缓存雪崩：缓存数据大量过期或者宕机，大量请求打到数据库。

  • 过期解决方案：（和击穿类似）
    • 加锁查询
    • 过期时间加随机数
  • 宕机解决方案：
    • 集群部署
    • 备份缓存
    • 限流和降级

过期处理

删除策略主要有两种：

• 定期删除：每隔一段时间删除
  • 每次扫描一部分，过期占比大，继续扫描一部分
• 惰性删除：访问键时，检查是否过期

内存回收机制：当内存使用量达到最大限制时触发

• 不淘汰数据：超过最大内存后，报错禁止写入（默认）

• 设置了过期时间的键

  • volatile-lru：对设定了过期时间的键使用 lru 算法删除（删除最久未使用，Least Recently Used）

  • volatile-lfu：对设定了过期时间的键使用 lfu 算法删除（删除最少使用，Least Frequently Used）

  • valatile-random：对设定了过期时间的键随机删除

  • valatile-ttl：对设定了过期时间的键根据存活时间删除（删除剩余存活时间短）

• 针对所有数据

  • allkeys-lru
  • allkeys-lfu
  • allkeys-random

正常情况下：惰性删除 + 定期删除一起使用，主动删除（内存回收）其实属于异常的兜底处理了。

持久化

RDB 持久化 、 AOF 持久化、混合持久化

• RDB 持久化：创建快照

  • 触发条件
    • save 命令：同步创建快照，会阻塞。
    • bgsave 命令：异步创建快照（默认）
      • 生成 RDB 文件时，主进程可以正常处理客户端请求。因为使用了写时复制的技术，主线程 fork 出一个子进程，并不会把主进程的所有内存数据重新复制一份给子进程，而是让主进程和子进程共享相同的内存页面，主进程修改数据的时候会复制出副本进行修改。
    • 自动触发：
      • 配置文件设置，save 900 1 表示如果至少有一个键被修改，900s后触发。
      • 通过 SHUTDOWN 正常关闭 Redis；
      • 主从节点建立连接时，主节点自动触发，生成 RDB 文件，然后发送给从节点。
  • 优缺点：恢复大数据集的速度比较快，但是可能会丢失最后一次快照以后的数据。

• AOF 持久化：追加写命令到 AOF 文件中

  • 工作流程操作：命令写入 （append）、文件同步（fsync）、文件重写（rewrite）、重启加载 （load）
    • 命令写入：写命令（比如 SET, LPUSH, SADD 等修改数据的命令）追加到 AOF 缓冲区（buffer）的末尾
    • 文件同步：持久化到磁盘的 AOF 文件
      • always：每次写命令都会同步
      • everysec(默认)：每秒同步一次
      • no：只会在AOF 关闭或 Redis 关闭时执行
    • 文件重写：AOF 文件会逐渐增大，所以需要重写。
      • 重写过程：将当前数据库状态转化成一系列写命令保存到新的 AOF 文件中（去重），不会解析原始文件。
      • 重写操作由 bgrewriteaof 完成，创建子线程执行，不会阻塞。
      • 重写过程中，新的写命令追加到 旧的 AOF 文件以及缓冲区中。重写完成后，缓冲区命令追加到新的 AOF 文件中，然后切换到新的 AOF 文件。
    • 重启加载：读取 AOF 文件中的所有命令并重新执行，恢复数据库。
  • 优缺点：数据的完整性比较高，但是对于大数据集，AOF 文件可能会比较大，恢复的速度比较慢。

• 混合持久化：在 AOF 重写的时候同时生成一份 RDB 快照，然后将这份快照作为 AOF 文件的一部分，最后再附加新的写入命令。前半部分是 RDB ，后半部分是 AOF 。恢复数据的时候先加载 RDB 然后通过 AOF 记录的命令恢复。

Redis 的持久化机制，并不能保证数据不丢失：因为 Redis 是先执行命令再写入 aof，所以如果执行命令写入 aof 这段时间 Redis 宕机了，重启后也无法利用 aof 恢复！

主从复制

可以通过主从复制、哨兵模式 和 集群模式来实现 高可用。

主从复制：实现读写分离。

• 包括三种模式：全量复制、基于长连接的命令传播、增量复制。

• 第一次同步，全量复制。后续命令传播。如果网络断开，根据 repl_backlog_buffer 缓冲区判断是全量同步还是增量同步。

• 全量复制：传输的是 RDB 文件

  • 使用场景：初次同步、从服务器数据丢失、主从服务器数据差异过大

• 增量复制：传输的是 命令

  • 如何实现：主服务器根据从服务器记录的偏移量，来发送增量数据。
    • repl_backlog_buffer：环形缓冲区，在主服务器中，记录了已经执行的命令
    • replication offset：标记环形缓冲区的偏移量，主从服务器都有
    • Tips：如果从服务器的数据已经不在环形缓冲区中，则需要进行全量复制，为了避免全量复制的性能损耗，尽量将环形缓冲区设置的大一点。

哨兵模式

哨兵模式：实现 主从节点 故障转移

• 哨兵节点主要负责三件事情：监控、选主、通知

• 监控

  • 三个定时监控：主从信息获取，哨兵信息发布，节点心跳检测（向主从节点以及其他哨兵发送）
  • 主观下线和客观下线
    • 主观下线：哨兵节点认为某个节点有问题。（心跳检测没有回应）
    • 客观下线：超过一定数量 quorum 的哨兵节点认为主节点有问题。（ quorum 的值建议设置为哨兵个数的二分之一加 1，只有主节点才有客观下线）

• 选主 + 通知

  • 选主：每个哨兵发送命令给其余哨兵，其余哨兵如果是第一次收到该命令则同意，否则拒绝。如果每个哨兵获得的同意数大于等于 max(quorum, num(sentinels) / 2 + 1) 则成为Leader。如果没有哨兵满足则进行下一轮选举。

  • Leader 实现故障转移：选择节点成为主节点；向其余节点发送命令，使其成为新主节点的从节点；监视老主节点，上线后通知其成为新主节点的从节点。

    • 选择主节点的参考依据：响应时间短、从节点优先级高、复制偏移量大（越大越完整）、runid 小

集群模式

集群模式 保证的是大数据量，高吞吐量场景

哨兵模式 保证的是主从的高可用，读写分离场景

集群模式：将数据存储在多个服务器上（一份数据一个服务器存不下）

• 虚拟槽分区：每个键通过哈希算法映射到槽上，每个集群节点负责一定范围的槽。槽的个数是2 的 14 次方，和 HashMap 中数组长度是 2 的幂次方一样，能够保证扩容后，大部分数据停留在扩容前的位置，少部分需要迁移。
• 支持主从复制和主节点的自动故障转移（与哨兵类似）

客户端在发送请求时，会通过集群的任意节点进行连接，如果该节点存储了对应的数据则直接返回，反之该节点会根据请求的键值计算哈希槽并路由到正确的节点。

可能会出现脑裂问题：

脑裂是指分布式系统中节点之间失去正常联系，导致集群分区，从而造成数据不一致的问题。

数据不一致：网络异常造成主节点与哨兵和从节点分区，哨兵选举出新的主节点，此时就出现了两个主节点，客户端不知道往哪里写。

如何避免？通过合理配置一下两个参数尽量避免，使主节点无法被写入（无法完全避免脑裂）

• min-slaves-to-write：主节点能执行写操作的最少跟随的从节点数量
• min-slavas-max-lag：从节点的最大延迟（超过改值，不会计入主从点的跟随）

集群分片方式：

• 客户端分片：分区逻辑在客户端实现，使用一致性哈希或者普通哈希。
• 中间件分片：使用中间件进行路由分发
• 客户端服务端分片：客户端采用一致性哈希，服务端提供错误重定向

分布式锁

分布式锁：当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。

Redis 实现

加锁：SET lock_key unique_value NX EX 5 ：

• lock_key 就是 key 键；
• unique_value 是客户端唯一标识，区分不同客户端；
• NX 代表只在 lock_key 不存在时，才对 lock_key 进行设置操作；
• EX 5 表示设置 lock_key 的过期时间为 5s，这是为了避免客户端发生异常而无法释放锁。

解锁：使用 lua 脚本，删除前需要判断执行操作的客户端就是加锁的客户端（通过 unique_value）

if redis.call("GET",KEYS[1]) == ARGV[1]
then
    return redis.call("DEL",KEYS[1])
else
    return 0
end

Redisson 实现

设置了过期时间，就需要 续期，来保证操作共享资源的时间小于过期时间。

可以通过 Redisson 优雅的进行锁的续期：

Redisson 中的分布式锁自带自动续期机制，其提供了一个专门用来监控和续期锁的 Watch Dog（ 看门狗），如果操作共享资源的线程还未执行完成的话，Watch Dog 会不断地延长锁的过期时间，进而保证锁不会因为超时而被释放。

看门狗机制：

• 异步实现，基于 lua 脚本
• 可重入，同一线程可以多次获取
• 递归调用实现续期（默认10s调用一次，将超时时间设置为 30s，会先判断是否需要续期）

// 1.获取指定的分布式可重入锁对象
// 2.获取锁且不设置锁超时时间，才会使用 Watch Dog 机制。获取不到 throw 异常
// 3.try 中执行业务
// 4.finally 中释放锁
RLock lock = redisson.getLock("lock");
if (!lock.tryLock()) throw xxx;
try {
    // do something
} finally {
    lock.unlock();
}

红锁

单点故障问题：

在生产环境会使用主从+哨兵方式来部署 Redis，在使用分布式锁的过程中，发生主从切换时，从节点可能不一定同步了主节点的锁信息，导致两个竞争者同时获取到锁。

红锁 是为了防止Redis集群中因主节点异常宕机而导致锁失效，从节点重复获取到锁。

红锁 加锁时只需超过半数节点获取锁成功就表示加锁成功。

使用红锁需要集群部署 redis，官方推荐至少 5 个实例，不需要部署从库和哨兵，仅需主库。5 个实例之间没有主从机制，没有任何信息交互。

Redlock 的实现流程：

1）客户端获取当前时间（t1）。

2）客户端按照顺序依次对 N 个 Redis 节点利用 set 命令进行加锁操作，对每个节点加锁都会设置超时时间（远小于锁的总过期时间），如果当前节点请求超时，立马向下一个节点申请锁。

3）当客户端成功从半数的 Redis 节点获取到了锁，这个时候获取一下当前时间 t2，然后计算加锁过程的总耗时 t（t2 - t1）。如果 t < 锁的过期时间，这个时候就可以判断加锁成功，反之加锁失败。

4）加锁成功则执行业务逻辑，加锁失败则依次向全部节点发起释放锁的流程。

但红锁也不一定安全，实例的时间跳跃时，就可能出现问题。

所以一般业务上还是使用 主从 + 哨兵 来实现分布式锁。

MongoDB

MongoDB是一种基于文档模型的 NoSQL 数据库，它使用类似 JSON 的 BSON 格式来存储数据。相对于传统的关系型数据库，MongoDB 有以下显著区别：

1）数据模型：使用集合和文档，每个文档相当于关系型数据库中的一行，但具有更灵活的结构和更复杂的嵌套数据形式。

2）模式灵活性： 各文档可以有不同的键值对，对模式的灵活性要求更低，适合快速迭代和处理异构数据。

3）扩展性： 非常容易水平扩展，可以把数据分布到多个服务器上，而关系型数据库通常水平扩展困难。

4）查询语言：有自己的查询语言，更适合处理文档型数据。

优点：

• 高效存储与查询：使用BSON格式存储数据，不仅支持复杂数据类型，还能利用索引实现快速查询。
• 简化数据模型：将数据聚合在文档中，简化了数据模型。
• 易于扩展：能够轻松应对数据结构的变化，迁移方便。
• 高性能：利用内存映射文件技术，将热数据加载到内存中，提升性能。
• 数据处理能力：提供丰富的聚合框架便于数据分析。

死锁

死锁的四个必要条件：互斥、并有并等待、不可剥夺、循环等待

避免死锁：至少破坏死锁发生的一个条件

• 破坏互斥条件：通常不可行，因为加锁就是为了互斥。
• 破坏持有并等待条件：一次性申请所有资源。
• 破坏不可剥夺条件：申请不到进一步资源时，释放已有资源。
• 破坏循环等待条件：对资源进行排序，线程按序申请。

哈希算法和一致性哈希

普通的哈希算法 （分布式哈希）的不足：

• 「存储节点」数量发生变化，需要重新映射「存储节点」和「数据」的关系
• 迁移数据的时候，也需要重新映射

一致性哈希：指将「存储节点」和「数据」都映射到一个首尾相连的哈希环上

• 数据映射的结果值往 顺时针的方向的找到第一个节点，就是存储该数据的节点。

• 通过这种方式，当新增或删除 存储节点时，只影响一小部分节点（会导致数据分布不均匀）

• 可以通过引入虚拟节点来提高均衡度

数据库设计

• 用户需求分析：对系统的功能、性能、限制等进行科学分析
• 概念结构设计：对系统进行分析和定义
• 逻辑结构设计：将抽象概念模型转换为与DBMS支持的数据模型相符合的逻辑模型
• 物理结构设计：逻辑模型的具体实现
• 数据库实施阶段：根据逻辑设计和物理设计建立数据库，组织数据入库并运行
• 数据库运行和维护阶段：不断进行评价、调整与修改

超类实体：作为其他实体的通用父类实体

派生属性：可以由其他属性计算出来的属性

SQL 注入攻击

SQL 注入（SQL Injection） 是一种将恶意 SQL 语句插入到应用程序的输入参数中，并通过传入数据库执行，从而达到绕过身份验证、查询、修改、删除数据库中敏感数据的攻击方式。

常见的解决方案：

1. 使用预编译语句（PreparedStatement）
2. ORM 框架（如 MyBatis、Hibernate）
3. 白名单控制和输入校验

设计模式

设计模式是一套可以被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解并且提高代码的可靠性。

设计模式的分类：

（1）根据目的分类：

• 创建型主要用于创建对象
  • 工厂方法模式(FactoryMethod)
  • 抽象工厂模式（Abstract Factory）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
  • 建造者模式(Builder)：将一个复杂类的表示与其构造相分离，使得相同的构建过程能够得出不同的表示。
  • 原型模式(Prototype)：允许对象在不了解创建对象的确切类以及如何创建细节的情况下创建自定义对象。
  • 单例模式(Singleton)
• 结构型主要用于处理类和对象的组合
  • 适配器模式（Adapter)
  • 桥接模式(Bridge）
  • 组合模式(Composite)
  • 装饰模式(Decorator)
  • 外观模式(Facade)
  • 享元模式(Flyweight)
  • 代理模式(Proxy)
• 行为型主要用于描述类或对象怎样交互和怎样分配职责
  • 职责链模式(ChainofResponsibility)
  • 命令模式(Command)
  • 解释器模式(Interpreter)
  • 迭代器模式(Iterator)
  • 中介者模式(Mediator)
  • 备忘录模式(Memento)
  • 观察者模式(Observer)
  • 状态模式(State)
  • 策略模式(Stratege)
  • 模板方法模式(TemplateMethod)
  • 访问者模式(Visitor)

（2）根据作用范围分类：

• 类模式用于处理类和子类的关系，这种关系通过继承建立，在编译时就确定了，是一种静态关系。
• 对象模式处理对象间的关系，具有动态关系。

数据仓库

4大特点：

• 面向主题：数据按主题组织。
• 集成性：消除了源数据中的不一致性，提供整个企业的一致性全局信息。
• 相对稳定性：主要进行查询操作，只有少量的修改和删除操作（或是不删除）。
• 反映历史变化：记录了企业从过去某一时刻到当前各个阶段的信息，可对发展历程和未来趋势做定量分析和预测。

第7章 系统架构设计基础知识

ABSD

基于体系结构的软件设计（Architecture-Based Software Design Model）模型把整个基于体系结构的软件过程划分为：

1. 需求：获取用户需求，标识系统中要用到的构件。体系结构需求一般来自3个方面，分别是系统的质量目标、系统的商业目标和系统开发人员的商业目标。
2. 设计：迭代过程
3. 文档化：输出体系结构规格说明和测试体系结构需求的质量设计说明书
4. 复审：标识潜在的风险
5. 实现：用实体来显示出一个软件体系结构
6. 演化：满足新的需求

ABSD是一个自顶向下，递归细化的软件开发方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。

软件架构风格

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。

一个体系结构定义一个词汇表和一组约束。

• 词汇表：包含一些构件和连接件类型

• 约束：指出系统是如何将这些构件和连接件组合起来的。

• 数据流体系结构风格

  • 批处理体系结构风格：数据以整体的方式传递
  • 管道-过滤器体系结构风格：一个步骤的输出是另一个步骤的输入
    • 支持并发，性能高
    • 交互性差

• 调用/返回体系结构风格：分而治之的策略，提升可修改性

  • 主程序/子程序风格：构件即为主程序和子程序，过程调用充当连接件
  • 面向对象体系结构风格： 构件是对象，通过对象调用封装的方法和属性。效率高、性能好；灵活性差
  • 层次型体系架构风格：每一层为上一层提供服务，并作为下层的客户
  • 客户端/服务器体系结构风格
    • 两层CS：胖客户机
    • 三层CS：瘦客户机（加了一层应用服务器）
  • 以数据为中心的体系结构风格（IDE）
  • 仓库体系结构风格：中央数据结构说明当前数据的状态以及一组对中央数据进行操作的独立构件
    • 不支持并发，效率低
    • 容错性、健壮性好，交互性强
  • 黑板体系结构风格：黑板、知识源、控制模块

• 虚拟机体系结构风格：增加架构的灵活性，拓展性（自定义规则）

  • 解释器体系结构风格：灵活、跨平台、扩展性强；执行效率低
  • 规则系统体系结构风格：将业务逻辑中频繁变化的部分定义为规则，包括规则集、规则解释器、规则/数据选择器及工作内存。

• 独立构件体系结构风格：降低耦合度，提升灵活性

  • 进程通信体系结构风格：构件是独立的过程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点到点、异步或同步方式及远程过程调用等。
  • 事件系统体系结构风格（隐式调用风格）：不直接调用，而是通过触发或广播的形式（语法高亮、语法错误提示）

C2风格：通过连接件绑定在一起按照一组规则运作的并行构建网络（构件和连接件、顶部和底部）

闭环-过程控制：发出控制命令并接受反馈，循环往复打到平衡（汽车定速巡航、空调温度调节）

软件架构复用

• 机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。
• 系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。

复用的基本过程主要包括3个阶段：

1. 构造/获取可复用的软件资产
2. 管理可复用资产
3. 使用可复用资产

DSSA

DSSA(Domain Specific Software Architecture) 就是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构。

从功能覆盖的范围角度理解DSSA中领域的含义有两种方法：

（1）垂直域：定义了一个特定的系统族，导出在该领域中可作为系统的可行解决方案的一个通用软件架构。

（2）水平域：定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统的特定部分功能。

基本活动：

• 领域分析：获得领域模型
• 领域设计：获得DSSA
• 领域实现：是依据领域模型和DSSA 开发和组织可重用信息。

DSSA的建立过程是并发的、递归的和反复的，包括以下5个阶段：

• 定义领域范围
• 定义领域特定的元素
• 定义领域特定的设计和实现需求约束
• 定义领域模型和体系结构
• 产生、搜集可重用的产品单元

第8章 系统质量属性与架构评估

基于软件系统的生命周期，可以将软件系统 的质量属性分为开发期质量属性和运行期质量属性2个部分。

常见的质量属性

• 性能：系统的响应能力（优先级队列、资源调度）

• 可靠性：出错时维持系统基本功能的能力（MTTF, MTTR, MTBF）（冗余、心跳）

• 可用性：系统正常运行的时间比例（冗余、心跳）

• 安全性：向合法用户提供服务，并拒绝非法用户，记录操作便于审计（用户认证、追踪审计）

  • 机密性保证信息不泄露给未授权的用户、实体或过程；
  • 完整性保证信息的完整和准确，防止信息被非法修改；
  • 不可否认性是指防止发送方否认发送过信息；
  • 可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。

• 可修改性（抽象、信息隐蔽）

  • 可维护性：错误后修复的难易程度
  • 可扩展性：适应变化增加新功能的能力
  • 可移植性：在不同计算环境下运行的能力

• 功能性：系统完成所期望工作的能力

• 可变性：变更为新架构的能力

• 互操作性：交换数据、相互调用服务的能力

• 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力

• 可扩展性（灵活性）：软件因适应需求变化而增加新功能的能力

• 鲁棒性（健壮性或容错性）：在非正常情况下仍能够正常运行的能力。

质量属性场景

为了精确描述软件系统的质量属性，通常采用质量属性场景作为描述质量属性的手段。

• 刺激源：生成刺激的实体
• 刺激：刺激引发的具体事件
• 环境：系统运行环境（xx环境）
• 制品：被刺激的部分（系统或者系统某个部分）
• 响应：刺激达到时系统采取的行为反应
• 响应度量：衡量响应的指标

在架构评估中，场景是从风险承担者的角度对与系统交互的描述，一般采用刺激、环境、响应三方面来对场景进行描述。

架构评估

• 风险：架构决策中潜在的隐患
• 敏感点：为了实现某种特定的质量属性，一个或多个构件的所具有的特性
• 权衡点：影响多个质量属性的特性，是多个质量属性的敏感点

评估方法：

ATAM 方法

架构权衡分析方法(Architecture Tradeoff Analysis Method, ATAM)主要针对性能、安全性、可修改性和可用性，在系统开发之前，对这些质量属性进行评价和折中。

使用 质量属性效用树 对质量属性进行分类和优先级排序。

效用树的结构包括：树根—质量属性—属性分类—质量属性场景(叶子节点)。

第9章 软件可靠性基础知识

软件可靠性 (Software Reliability) 是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。

• 规定的条件是指直接与软件运行相关的使用该软件的计算机系统的状态和软件的输入条件，或统称为软件运行时的外部输入条件；
• 规定的时间区间是指软件的实际运行时间区间；
• 规定功能是指为提供给定的服务，软件产品所必须具备的功能。

容错设计技术：

• 恢复块设计：使软件包含有一系列的恢复块，一旦出现故障即替换
• N版本程序设计：设计多个模块或不同版本，实行多数表决
• 冗余设计：硬件冗余，软件冗余

系统配置技术：

• 双机热备技术
  • 双机热备模式：一个工作，一个准备
  • 双机互备模式：同时运行不同服务，出现故障接管对应服务
  • 双机双工模式：同时运行相同服务
• 服务器集群技术

第10章 软件架构的演化和维护

软件架构包括：

• 组件：基本要素和结构单元
• 连接件：组件之间的相互关系
• 约束：组件和连接件之间的拓扑关系和配置

第11章 未来信息综合技术

CPS

CPS（信息物理系统）的本质就是构建一套信息空间与物理空间之间基于数据自动流动的状态感知、实时分析、科学决策、精准执行的闭环赋能体系，解决生产制造、应用服务过程中的复杂性和不确定性问题，提高资源配置效率，实现资源优化。

体系架构：

• 单元级：不可分割的最小单元
• 系统级：多个单元级有机组合
• SoS级：多个系统级有机组合

第12章 信息系统架构设计理论与实践

信息系统架构

信息系统架构(ISA)是指对某一特定内容里的信息进行统筹、规划、设计、安排等一系列有机处 理的活动。

• 架构是对系统的抽象
• 架构由多个结构组成
• 任何软件都存在架构
• 元素及其行为的集合构成架构的内容
• 架构具有基础性
• 架构隐含决策

信息系统架构分类：

• 物理结构：硬件系统的空间分布情况
  • 集中式
  • 分布式
• 逻辑结构：各个功能子系统的综合体

子系统综合：

• 横向综合：同一管理层次的各种职能综合在一起
• 纵向综合：某种职能的各个管理层次的业务组织在一起
• 纵横综合：提取通用部分，建立系统公用数据库和统一的信息处理系统。

信息系统常用4种架构模型：

• 单机应用模式(Standalone)：运行在一台物理机器上的独立应用程序。
• 客户机/服务器(Client/Server)模式：即两层、三层C/S、B/S 模式、MVC模式等。
• 面向服务架构模式
• 企业数据交换总线：不同的企业应用之间进行信息交换的公共通道。

企业信息系统要集成信息系统架构，必须考虑企业中的四个方面：战略系统、业务系统、应 用系统和信息基础设施。

• 战略管理
  • 战略系统：企业中与战略制定、高层决策有关的管理活动和计算机辅助系统。
• 战术管理
  • 业务系统：企业中完成一定业务功能的各部分组成的系统。
  • 应用系统：信息系统中的应用软件部分。
• 运行管理
  • 信息基础设施：由信息设备、通信网络、数据库、系统软件和支持性软件等组成的环境。
    • 技术基础设施
    • 信息资源设施
    • 管理基础设施

信息系统架构设计方法

TOGAF：是一种开放式企业架构框架标准，确保从关键利益相关方 到团队成员的所有用户都使用相同的语言、避免被“锁定”到企业架构的专有解决方案、节省时间 和金钱更有效地利用资源、实现可观的投资回报。

TOGAF的关键是架构开发方法ADM

ADM 方法是由一组按照架构领域的架构开发顺序而排列成一个环的多个阶段所构成。

实现信息化就要构筑和完善6个要素：

• 开发利用信息资源
• 建设国家信息网络
• 推进信息技术应用
• 发展信息技术和产业
• 培育信息化人才
• 制定和完善信息化政策

完整的信息化内涵包括四方面内容：

• 信息网络体系
• 信息产业基础
• 社会运行环境
• 效用积累过程

信息化架构的两种模式：

• 数据导向架构：关注数据对象和数据对象之间的关系
• 流程导向架构：关注流程，架构本身的目的是为了端到端流程整合服务

信息系统的生命周期：

• 系统规划：初步调查（输出:可行性研究报告、系统设计任务书）
• 系统分析：详细调查（输出:系统说明书）
• 系统设计：设计系统的物理模型（输出:系统设计说明书）
• 系统实施：将设计的系统付诸实施（输出:实施进展报告、系统测试分析报告）
• 系统运行和维护：:系统投入运行后，需要经常进行维护和评价。

信息化需求包含三个层次：

• 战略需求
• 运作需求
• 技术需求

案例分析

价值模型核心的特征可以简化为三种基本形式：

1. 价值期望值：表示对某一特定功能的需求
2. 反作用力：实现某种价值期望值的难度
3. 变革催化剂：导致价值期望值发生变化的某种事件

反作用力和变革催化剂称为限制因素，把这三个统称为价值驱动因素。

体系结构挑战是因为一个或多个限制因素使得满足一个或多个期望值变得更困难。

其他

响应式 Web 设计：网页能够根据不同设备自动调整布局和样式

实现方式：

• 媒体查询：使用 CSS 中的 @media 语句针对不同屏幕尺寸应用不同样式
• 流式布局：使用百分比而不是固定像素
• 弹性图片：使用 max-width: 100% 等方式使图片不会超出容器

J2EE框架：

• 客户端：浏览器（HTML、Applet）
• Web：Web服务器（JSP、Servlet）
• EJB容器：简单Bean、会话Bean、实体Bean
• DB

第13章 层次式架构设计理论与实践

N层架构模式：表现层、中间层、数据访问层、数据层

特性：关注分离，每一层只负责本层的逻辑，为上层服务，并作为下层客户。

表现层

• MVC

  • 三个要素：（Model和View还是有联系的）

    • Model：提供数据

    • View：提供显示

    • Control：负责处理

  • EJB(Enterprise Java Beans)

    • 会话Beans：临时交互
    • 实体Beans：永久记录
    • 消息驱动Beans：消息监听

  • 好处：

    • 允许多种用户界面的扩展

    • 易于维护

    • 功能强大的功能界面

    • 将业务处理与显示分离，增加了应用的拓展性、强壮型及灵活性

• MVP：将MVC中的 Controller 替换成了 Presenter，来完全切断View和Model之间的联系

• MVVM：使用 ViewModel 实现视图和模型的分离，View 和 ViewModel 之间使用 DataBinding 及其事件进行通信。

中间层（业务逻辑层）

业务逻辑组件分为接口和实现两个部分。

数据访问层

5种数据访问模式：

• 在线访问
• DataAccess Object
• Data Transfer Object
• 离线数据模式
• 对象/关系映射 ORM：能够将程序中的数据转换成数据库中的记录，或将数据库中的记录转换成程序代码方便操作的对象。

工厂模式的应用：根据数据库不同，由类工厂决定实例化哪个类

物联网层次架构设计：感知层、网络层、应用层

第14章 云原生架构设计理论与实践

云原生架构旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性，具备轻量、敏捷、高度自动化的特点。

具备云原生架构的应用可以最大程度利用云服务和提升软件交付能力，进一步加快软件开发。

其特点包括：代码结构发生巨大变化、非功能性特性大量委托、高度自动化的软件交付。

云原生架构7大原则：

• 服务化原则：拆分为微服务架构，分别迭代。
• 弹性原则：系统的部署规模随着业务量变化而自动伸缩。
• 可观测原则：通过日志、链路跟踪和度量等手段，使得一次点击背后的多次服务调用的耗时、返回值和参数都清晰可见。
• 韧性原则：当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力。
• 所有过程自动化原则：一方面标准化企业内邵的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。
• 零信任原则：默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础，以身份为中心。
• 架构持续演进原则：云原生架构本身也必须是一个具备持续演进能力的架构。

主要架构模式：

• 服务化架构模式：以应用模块为颗粒度划分一个软件。

• Mesh化架构模式：将中间件框架从业务进程中分离，进一步解耦。

• Serverless模式：把应用的整个运行都委托给云

• 存储计算分离模式：数据云存储，实现存储计算分离

• 分布式事务模式：根据不同的场景选择合适的分布式事务模式，保证多服务之间的数据一致性。

• 可观测架构：包括日志，链路跟踪、度量。

• 事件驱动架构：基于事件触发相应

• SAAS：软件即服务

• PAAS：平台即服务

• IAAS：基础设施即服务

第15章 面向服务架构设计理论与实践

面向服务架构

面向服务的体系架构（SOA：Service-Oriented Architecture）是一种分布式软件架构风格，它将系统功能模块封装成一组可复用、松耦合的服务，通过统一协议进行通信，来支持跨平台、跨语言、跨组织的系统集成与协作。

ESB（企业服务总线，Enterprise Service Bus）是 SOA 中的核心基础设施组件之一，用于在不同服务之间实现松耦合、统一通信、路由、转换和管理的功能。集中式管理，支持同步/异步方式通信，可扩展性强。

业务流程是指为了实现某种业务目的行为所进行的流程或一系列动作。

BPEL（Business Process Execution Language，业务流程执行语言）：一种使用 Web 服务定义和执行业务流程的语言。

微服务架构

SOA 架构向更细粒度、更通用化程度发展，就成了所谓的微服务了。

主要区别：

• 更加精细，微服务独立运行，互不影响
• 接口方式更加通用化
• 分布式去中心化的部署方式（不再强调SOA架构中比较重要的ESB）

微服务架构是一种将应用系统按照业务功能划分为多个小型服务单元的架构风格。每个服务围绕特定的业务功能构建，独立部署、独立运行、独立扩展，服务之间通过轻量级的通信协议（如 HTTP/REST、gRPC、消息队列等）进行交互。

优点：

• 高内聚，低耦合：每个服务内聚程度高，服务间耦合程度低
• 技术选型灵活：每个服务可以根据自身业务需求选择合适的体系架构和风格
• 容错：某个服务发生故障不会影响整个系统

缺点：

• 复杂型高：需要应对服务间通信、数据一致性、版本控制等问题。
• 测试复杂：集成测试和端到端测试比单体架构更复杂。
• 部署运维繁琐：涉及大量服务的部署、注册、发现、配置和监控。

SOA 参考架构

以服务为中心的企业集成架构：

• 连接服务：企业服务总线
• 业务逻辑服务：整合已有应用、新开发应用、客户和业务伙伴
• 控制服务：数据整合、流程整合、用户访问整合
• 开发服务：为不同开发者的角色提供的功能
• 业务创新和优化：业务性能管理
• IT服务管理：为业务流程和服务提供安全、高效和健康的运行环境

SOA 主要协议和规范

SOA的实现方式：WebService

• SOAP（Simple Object Access Protocol, 简单对象访问协议）：描述传递信息的格式
• WSDL（Web Services Description Language, 网络服务描述语言）：描述如何访问具体的接口（服务做什么、如何访问服务和服务位于何处）
• UDDI（Universal Description Discovery and Integration, 通用描述、发现和集成服务）：管理、分发和查询 WebService

REST（Representational State Transfer，表述性状态转移）四要素：

1. 资源：以资源为中心构建
2. 表述：某一时间的状态
3. 状态转移：应用状态和资源状态
4. 超链接：建立联系

SOA 的设计原则

1. 无状态
2. 单一实例
3. 明确的接口定义
4. 自包含和模块化：服务可以独立运作，不依赖外部组件
5. 粗粒度
6. 服务之间的松耦合性
7. 重用能力
8. 互操作性、兼容和策略声明

SOA 的设计模式

• 服务注册表模式
• 企业服务总线模式
• 微服务模式

SOA 实施的过程

选择SOA 最佳的解决方案：

• 尽量选择能进行全局规划的方案
• 选择时充分考虑企业自身的需求
• 从平台实施等技术方面进行考查

业务流程分析：

• 建立服务模型
• 建立业务流程

第16章 嵌入式系统架构设计理论与实践

嵌入式系统(Embedded System)是为了特定应用而专门构建的计算机系统。

大多数嵌入式系统都具备实时特征，其典型架构可以概括为层次化模式架构和递归模式架构。

嵌入式系统软件架构原理与特征

嵌入式系统的典型架构可概括为两种模式：

• 层次化模式架构：高层的抽象概念与低层的更加具体的概念之间存在着依赖关系
• 递归模式架构：将一个非常复杂的系统进行分解

嵌入式操作系统分为：

• 嵌入式实时系统：VxWorks、Nucleus 等
• 时嵌入式操作系统：Android、iOS、 WinCE 等

嵌入式操作系统的一般架构：

• 整体结构
• 层次结构
• 客户服务器结构
• 面向对象结构

嵌入式操作系统的基本功能：

• 内核：核心部分，管理着系统的各种资源
• 任务管理：系统调度
  • 强实时性算法：最早截止时间优先、最低松弛度优先、单调速率调度算法
• 存储管理：解决多个用户使用主存的问题
• 任务间通信
  • 常用的通信方式：共享内存、信号量、消息队列

嵌入式数据库：

1. 基于内存方式：活动事务只与实时内存数据库的内存拷贝打交道（eXtremeDB）
2. 基于文件方式：按照一定格式储存在磁盘中（SQLite）
3. 基于网络方式：基于手机 4G/5G的移动通信基础之上的数据库系统

数据库服务器和嵌入式数据库对比如下：

• 允许开发人员对数据库进行操作；只允许应用程序对其进行访问和控制。
• 数据与程序分离；访问控制完全交给应用程序,
• 需要独立的安装、部署和管理；和应用程序一起发布

嵌入式系统软件架构设计方法

• 基于架构的软件设计开发方法ABSD
• 属性驱动的软件设计ADD
  • 七个阶段：评审、选择驱动因子、选择系统元素、选择设计概念、 实体化元素和定义接口、草拟视图和分析评价等
• 实时系统设计方法DARTS：是将实时系统分解为多个并发任务，并定义这些任务之间的接口。

案例分析

鸿蒙：

• 分层的层次化设计：内核层、系统服务层、框架层和应用层
• 4个技术特性：分布式架构、确定时延引擎和高性能 IPC 技术、微内核架构、统一 IDE 支撑一次开发

第17章 通信系统架构设计理论与实践

通信系统是利用各种通信线路将地理上分散的、具有独立功能的计算机系统和通信设备按不同的形式连接起来，依靠网络软件及通信协议实现资源共享和信息传递的系统。

通信系统网络架构

• 局域网：单一机构所拥有的专用计算机网络
  • 单核心架构：由一台核心二层或三层交换设备充当网络的核心设备（网络结构简单,可节省设备投资；网络地理范围受限）
  • 双核心架构：采用三层及以上交换机，网络内划分 VLAN 时,各 VLAN 之间访问需通过两台核心交换设备来完成。
  • 环型架构：采用三层或以上交换机，多台核心交换设备连接成双 RPR 动态弹性分组环,构建网络的核心。
  • 层次局域网架构（多层局域网）：由核心层交换设备、汇聚层交换设备、接入层交换设备，以及用户设备等组成。
• 广域网：多级网络，将分布在各地域的局域网互连起来
  • 单核心广域网：采用三层及以上交换机，由一台核心路由设备和各局域网组成。
  • 双核心广域网：采用三层及以上交换机，由两台核心路由设备和各局域网组成。
  • 环型广域网：采用三台以上核心路由器设备构成路由环路。
  • 半冗余广域网：由多台核心路由设备连接各局域网而形成的，任意核心路由设备至少存在两条以上连接至其他路由设备的链路。
  • 对等子域广域网：将广域网的路由设备划分成两个独立的子域，每个子域路由设备采用半冗余方式互连。两个子域之间通过一条或多条链路互连。
  • 层次子域广域网：多个较为独立的子域，每个子域内路由设备采用半冗余方式互连，多个子域之间存在层次关系。
• 移动通信网
  • 5GS与DN互连：5GS 在为移动终端用户(UE)提供服务时通常需要 DN(Data Network)网
    • 透明模式：5GS 通过UPF的N6 接口直接连至运营商特定的 IP 网络，然后通过防火墙或代理服务器连至DN。
    • 非透明模式：5GS 可直接接入 Intranet/ISP，或通过其他 IP 网络(如 Internet)接入 Internet/ISP。
  • 5G网络边缘计算：在靠近终端用户UE 的移动网络边缘部署 5G UPF 网元，结合在移动网络边缘部署边缘计算平台。
• 存储网络架构
  • 直连式存储DAS：指将存储设备通过SCSI接口直接连接到一 台服务器上使用
  • 网络连接存储NAS：通过网络接口与网络直接相连，由用户通过网络访问，有独立的存储系统
  • 存储区域网络SAN：通过专用交换机将磁盘阵列与服务器连接起来的高速专用子网
• 软件定义网络架构
  • 软件定义网络SDN：利用分层的思想，将网络分为控制层和数据层。
  • SDN网络架构：分为数据平面、控制平面和应用平面

第18章 安全架构设计理论与实践

安全架构概述

面临的威胁：

• 物理安全威胁：对系统所用设备的威胁，如自然灾害、电源故障、操作系统引导失败或数据库信息丢失、设备被盗/被毁造成数据丢失或信息泄露。
• 通信链路安全威胁：在传输线路上安装窃听装置或对通信链路进行干扰。
• 网络安全威胁：由于互联网的开放性、国际化的特点,人们很容易通过技术手段窃取互联网信息，对网络形成严重的安全威胁。
• 操作系统安全威胁：对系统平台中的软件或硬件芯片中植入威胁,如“木马”和“陷阱门”、BIOS 的万能密码。
• 应用系统安全威胁：对于网络服务或用户业务系统安全的威胁，也受到“木马”和“陷阱门”的 威胁。
• 管理系统安全威胁：由于人员管理上疏忽而引发人为的安全漏洞，如人为的通过拷贝、拍照、 抄录等手段盗取计算机信息。

安全架构是架构面向安全性方向上的一种细分，通常的产品安全架构、安全技术体系架构和审计架构可组成三道安全防线。

• 产品安全架构：构建产品安全质量属性的主要组成部分以及它们之间的关系。
• 安全技术体系架构：构建安全技术体系的主要组成部分以及它们之间的关系。
• 审计架构：独立的审计部门或其所能提供的风险发现能力。

安全模型

信息系统的安全目标是控制和管理主体(含用户和进程)对客体(含数据和程序)的访问。

安全模型是准确地描述安全的重要方面及其与系统行为的关系。

安全策略是从安全角度为系统整体和构成它的组件提出基本的目标。

安全模型提供了实现目标应该做什么,不应该做什么。

• 状态机模型：无论处于何种状态都是安全的系统。

• Bell-LaPadula 模型：使用主体、客体、访问操作(读、写、读/写)以及安全级别（绝密、机密、秘密）这些概念。

  • 核心：不读高，不写低（不能泄密）

  • 安全规则：

    • 简单安全规则：只能下读。

    • 星属性安全规则：只能上写。

    • 强星属性规则：不允许对另一级别读写。

    • 自主安全规则：使用访问控制矩阵来自定义。

• Biba模型：访问控制不是建立在安全级别上，而是建立在完整性级别上。防止数据从低完整性级别流向高完整性级别。

  • 核心：不读低，不写高（不能被污染）
  • 完整性的三个目标
    • 保护数据不被未授权用户更改
    • 保护数据不被授权用户越权修改(未授权更改)
    • 维持数据内部和外部的一致性
  • 安全规则
    • 星完整性规则：只能下写。
    • 简单完整性规则：只能上读。
    • 调用属性规则：表示一个完整性级别低的主体不能从级别高的客体调用程序或服务。

• Clark-Wilson 模型：将完整性目标、策略和机制融为一体的模型。

• Chinese Wall 模型：通过行政规定和划分、内部监控、IT 系统等手段防止各部门之间出现有损客户利益的利益冲突 事件。

  • 定理1：一个主体一旦访问过一个客体，则该主体只能访问位于同一公司数据集的客体或在不同利益组的客体。
  • 定理2：在一个利益冲突组中，一个主体最多只能访问一个公司数据集。

系统安全体系架构规划框架

安全技术体系架构是对组织机构信息技术系统的安全体系结构的整体描述。

安全技术体系架构的目标是建立可持续改进的安全技术体系架构的能力。

• 安全技术体系架构：5个层次的实体对象:应用、存储、主机、网络和物理。
• 信息系统安全体系：由技术体系、组织机构体系和管理体系三部分共同构成的。
• 信息系统安全规划框架
  • 信息系统安全规划依托企业信息化战略规划
  • 信息系统安全规划需要围绕技术安全、管理安全、组织安全考虑
  • 信息系统安全规划以信息系统与信息资源的安全保护为核心

信息安全整体架构设计

人、管理和技术手段是信息安全架构设计的三大要素。

WPDRRC(Waring/Protect/Detect/React/Restore/Counterattack)模型有6个环节和3大要素。

6个环节包括：预警、保护、检测、响应、恢复和反击。

3大要素包括：人员、策略和技术。人员是核心，策略是桥梁，技术是保证。

信息系统安全设计重点考虑两个方面：其一是系统安全保障体系；其二是信息安全体系架构。

• 系统安全保障体系是由安全服务、协议层次和系统单元等三个层面组成。

• 信息安全体系架构：包括物理安全、系统安全、网络安全、应用安全和管理安全。

网络安全体系架构设计

OSI 定义了7层协议，其中除第5层(会话层)外，每一层均能提供相应的安全服务。（物链路网输会示用）

实际上，最适合配置安全服务的是在物理层、网络层、运输层及应用层上，其他层都不宜配置安全服务。

OSI 开放系统互联安全体系的5类安全服务包括鉴别、访问控制、数据机密性、数据完整性和抗抵赖性。

将防御能力分布至整个信息系统中：

• 多点技术防御：对网络和基础设施、边界、计算环境这三个防御核心区域的防御

• 分层技术防御：在对手和目标间使用多个防御机制

• 支撑性基础设：为网络、边界和计算环境中信息保障机制运行基础的支撑性基础设施

• 认证框架

  • 鉴别(Authentication)的基本目的是防止其他实体占用和独立操作被鉴别实体的身份。
    • 实体由申请者来代表
    • 实体为验证者提供数据项来源

• 访问控制框架

  • 访问控制(Access Control)决定开放系统环境中允许使用哪些资源、在什么地方适合阻止未授权访问的过程。
  • ACI(访问控制信息)是用于访问控制目的的任何信息
  • ADF(访问控制判决功能)是一种特定功能，它通过对访问请求、ADI 以及该访问请求的上下文使用访问控制策略规则而做出访问控制判决。

• 机密性框架

  • 数据的机密性可以依赖于所驻留和传输的媒体。

• 完整性框架

  • 阻止对媒体访问的机制
  • 用以探测对数据或数据项序列的非授权修改的机制。

• 抗抵赖框架

  • 抗抵赖服务包括证据的生成、验证和记录，以及在解决纠纷时随即进行的证据恢复和再次验证。

数据库系统的安全设计

TCSEC 标准：

• D类：基本没有安全保护措施的产品
• C类：只提供了安全保护措施, 一般不称为安全产品
• B类：实行强制存取控制的产品，也是真正意义上的安全产品

安全产品均是指安全级别在B1 以上的产品

数据库完整性是指数据库中数据的正确性和相容性。

在实施数据库完整性设计时，需要把握以下基本原则：

• 根据数据库完整性约束的类型确定其实现的系统层次和方式
• 实体完整性约束、引用完整性约束是关系数据库最重要的完整性约束
• 要慎用目前主流 DBMS 都支持的触发器功能（开销大，难以控制，非用不可时尽量用Before型）
• 在需求分析阶段就必须制定完整性约束的命名规范
• 要根据业务规则对数据库完整性进行细致的测试
• 要有专职的数据库设计小组
• 应采用合适的CASE 工具来降低数据库设计各阶段的工作量

数据库完整性的作用：

• 够防止合法用户使用数据库时向数据库中添加不合语义的数据
• 基于DBMS 的完整性控制机制来实现业务规则
• 兼顾数据库的完整性和系统的效能
• 有助于尽早发现应用软件的错误

数据库完整性约束可分为6类：列级静态约束、元组级静态约束、关系级静态约束、列级动态约束、元组级动态约束和关系级动态约束。

系统架构的脆弱性分析

软件脆弱性是指由软件缺陷的客观存在所形成的一个可以被攻击者利用的实例。

每个脆弱性都由至少一个软件缺陷引起，但是一个软件缺陷也可能不产生任何脆弱性，而且不同的软件缺陷可能导致相同的脆弱性。

软件脆弱性的特点：

• 系统中隐藏的一个弱点，本身不会引起危害，但被利用后会产生严重的安全后果。
• 自觉或不自觉引入的逻辑错误是大多数脆弱性的根本来源。
• 系统环境的任何差异都有可能导致不同的脆弱性问题。
• 旧的脆弱性得到修补或纠正的同时可能引入新的脆弱性

生命周期：引入阶段->产生破坏效果阶段->修补阶段

典型软件架构的脆弱性分析：

• 分层架构：
  • 层间的脆弱性
  • 层间通信的脆弱性
• C/S架构
  • 客户端软件的脆弱性
  • 网络开放性的脆弱性
  • 网络协议的脆弱性
• B/S架构
  • 使用 HTTP 协议，比C/S架构更容易被病毒入侵
• 事件驱动架构
  • 组件的脆弱性
  • 组件间交换数据的脆弱性
  • 组件间逻辑关系的脆弱性
  • 事件驱动容易进入死循环
  • 高并发的脆弱性
  • 固定流程的脆弱性
• MVC架构
  • MVC架构的复杂性带来的脆弱性
  • 视图与控制器紧密连接的脆弱性
  • 视图对模型数据的低效率访问的脆弱性
• 微内核架构
  • 难以进行良好的整体化优化
  • 进程间通信开销也较单一内核系统要大得多
  • 通信损失率高
• 微服务架构
  • 分布式系统的复杂结构
  • 设计服务之间的通信机制
  • 服务管理的复杂性

第19章 大数据架构设计理论与实践

传统数据库存在数据过载问题

现代大数据处理技术主要有：

1. 基于分布式文件系统 Hadoop
2. 使用 Map/Reduce 或 Spark 数据处理技术
3. 使用 Kafaka 数据传输消息队列及Avro 二进制格式。

大数据的利用过程分为：采集、清洗、统计和挖掘。

Lambda架构

Lambda 架构设计目的在于提供一个能满足大数据系统关键特性的架构。整合离线计算和实时计算，具备强鲁棒性，提供低延迟和持续更新。

Lambda架构：

• 批处理层：存储数据集，处理离线数据，全体数据集，得到Batch View（Hadoop、HDFS）
• 加速层：处理增量数据流，得到Real-time View（Spark、Storm）
• 服务层：合并 Batch View 和 Real-time View 中的结果数据集到最终数据集。用于响应用户的查询请求（HBase、Cassandra）

优点：容错性好、查询灵活度高、易伸缩、易扩展。

缺点：全场景覆盖带来的编码开销。

Kappa架构

Kappa 架构在 Lambda 的基础上进行了优化，删除了 Batch Layer，将数据通道以消息队列进行替代。

输入数据直接由实时层的实时数据处理引擎对源源不断的源数据进行处理，再由服务层的服务后端进一步处理以提供上层的业务查询。

Kappa 架构与 Lambda 相比的区别：

• Kappa 不是 Lambda 的替代架构，而是其简化版本， Kappa 放弃了对批处理的支持，更擅长业务本身为增量数据写入场景的分析需求
• Lambda 直接支持批处理，因此更适合对历史数据分析查询的场景。

优点：将实时和离线代码统一起来，方便维护而且统一了数据口径。

缺点：

• 缓存的数据量和回溯数据有性能瓶颈
• 遇到大量不同的实时流进行关联时，非常依赖实时计算系统的能力。
• 抛弃了离线计算更加稳定可靠的特点。

第20章 系统架构设计师论文写作要点

字数建议：摘要300字+项目背景500字+正文主题1200字+结尾500字

不用写题目，选好写的题目即可

• 摘要300字
  • 项目背景：时间，名称，主要内容
  • 作者角色及工作内容
  • 技术简介
• 背景500字
  • 诞生背景
  • 主要内容 5W2H
    • when, where, who ,why, what
    • how much, how
• 正文1200字
  • 理论部分：对题干的应答，分论点基本描述（一般三个论点）
  • 实践部分：与理论部分相呼应，分论文的论述
• 结尾500字
  • 项目效果
  • 存在问题：小问题，已解决的