系统架构设计综合知识与案例分析

system-architect

  软考高级-系统架构设计师-综合知识与案例分析：软件工程、网络工程、结构化分析方法、面向对象分析方法、软件质量数量、传统数据库、分布式数据库、系统架构等。

---

—— 2025 年 3 月 20 日 甲辰年二月二十一 春分

1、计算机基础知识

1.1、网络工程

• 常用协议：

  • 邮件：
    • POP3：110 端口，邮件收取。
    • SMTP：25 端口，邮件发送。
  • FTP：20 数据端口，21 控制端口，文件传输协议。
  • HTTP：80 端口，超文本传输协议，网页传输。
  • DHCP：67 端口，ip 地址自动分配。
  • SNMP：161 端口，简单网络管理协议。
  • DNS：53 端口，域名解析协议，记录域名与 ip 映射关系。
  • TCP：可靠的传输层协议，可依据端口号将报文交付给上层的某一进程，可对应用进程进行寻址。
  • UDP：不可靠的传输层协议。
  • ICMP：因特网控制协议，ping 命令来自该协议。
  • IGMP：组播协议。
  • ARP：地址解析协议，ip 地址转换为 mac 地址。
  • RARP：反向地址解析协议，mac 地址转换为 ip 地址。

• 七层模型：

  层次	名称	主要功能	主要设备及协议
  7	应用层	实现具体的应用功能	POP3、SMTP、FTP、HTTP、Telnet、DHCP、SNMP、DNS
  6	表示层	数据格式的表达、加解密、解压缩	同上
  5	会话层	建立、管理、终止会话	同上
  4	传输层	端到端的连接	TCP、UDP
  3	网络层	分组传输和路由选择	三层交换机、路由器、IP、ICMP、IGMP、ARP、RARP
  2	数据链路层	传输以帧为单位的信息	网桥、网卡、交换机（多端口网桥）PPTP、L2TP、SLIP、PPP
  1	物理层	二进制传输	中继器、集线器（多端口的中继器）

• TCP 与 UDP：

  • TCP：
  • UDP：

1.2、软件工程

• 开发模型：
  • 瀑布模型：结构化方法。开发阶段性、需求明确、文档齐全、风险控制弱、因果关系紧密相连。
  • 原型模型：迭代方法。分为原型开发和目标软件开发。适用于需求不明确。
  • 螺旋模型：迭代方法。瀑布与原型（演化）模型结合体。适用于大型、复杂、风险项目。
    • 计划制定、风险分析、工程实施、客户评估。
  • 喷泉模型：面向对象方法。复用好、开发过程无间隙、节省时间。
  • V模型：开发与测试结合。
  • 变换模型：适用于形式化开发。
  • 智能模型：适用于基于规则的专家系统。
  • 快速应用开发（RAD）：基于构件的开发方法。用户参与、开发或复用构件、模块化要求高、不适用新技术。
  • 统一过程（RUP/UP）：用例驱动、架构为中心、迭代、增量。
    • 起始阶段、细化阶段、构建阶段、交付阶段和生产阶段。
  • 可重用构件模型：基于构件的开发方法。开发或复用构件。
• 三层需求：业务需求、用户需求、功能需求。
  • 业务需求：指组织结构或客户对系统或产品的高层次的目标要求。
  • 用户需求：指用户使用产品必须要完成的任务，是用户对该软件产品的期望。二者共同组成了用户原始需求内容。
  • 功能需求：指软件开发人员必须要实现的功能，使得用户可以完成他们的任务，从而满足业务需求。
• 设计模式：
  • 创建型：用于描述怎样创建对象，将对象的创建和使用分离。单例、原型、工厂方法、抽象工厂、建造者。
  • 结构型：用于描述如何将类或对象按照某种布局组合成更大的结构。代理、适配、桥接、装饰、外观、享元、组合。
  • 行为型：用于描述类或对象之间怎样写作来共同完成单个对象无法单独完成的任务，以及怎样分配职责。
• 软件设计：
  • 数据设计：将模型转换成数据结构的定义，好的数据设计将改善程序结构和模块划分，降低过程复杂性。
  • 软件/体系结构设计：定义软件系统各主要部件之间的关系。
  • 接口设计（人机界面设计）：软件内部、软件和操作系统之间，以及软件和人之间如何通信。
  • 过程设计：系统结构部件转换成软件的过程描述。
• 内聚类型：
  • 偶然内聚：模块中的代码无法定义其不同功能的调用，但它使该模块能执行不同的功能，称为巧合强度模块。
  • 逻辑内聚：把几种相关的功能组合在一起，每次调用时由传递的参数决定提供那种功能。
  • 时间内聚：把需要同时执行的动作组合在一起。
  • 过程内聚：构件或者操作的组合方式是，允许在调用前面的构件或操作之后，马上调用后面的构件或操作，即使两者之间没有数据进行传递。
  • 通信内聚：即模块内所有处理元素都在同一个数据结构上。
  • 顺序内聚：即模块内所有处理元素都顺序执行。
  • 功能内聚：即模块内所有元素共同完成同一个功能，联系紧密，缺一不可。
• 耦合类型：
  • 非直接耦合：两个模块之间没有直接联系，联系完全通过主模块的控制和调用实现。
  • 数据耦合：一组模块借助参数表传递简单数据。
  • 标记耦合：一组模块通过参数表传递记录信息（数据结构）。
  • 控制耦合：模块之间传递的信息包含用于控制模块内部逻辑的信息。
  • 外部耦合：一组模块都访问同一全局简单变量（非全局数据结构），并且不是通过参数表传递该变量信息。
  • 公共耦合：多个模块都访问同一个公共数据环境（如全局数据结构、共享的通信区、内存的公共覆盖区等）。
  • 内容耦合：一个模块直接访问另一个模块的内部数据；一个模块不通过正常入口直接访问另一个模块的内部数据；两个模块有一部分程序代码重叠；
• MVC：
  • 模型（Model）：表示待展示的对象。
  • 视图（View）：负责模型的展示，并能接收用户的输入数据，但它不进行任何实际的业务处理。
  • 控制器（Controller）：负责把用户的动作转成对模型的操作。模型通过更新视图的数据来反映自身的变化。
• EJB：
  • Session Bean：维护一个短暂的会话，当客户端执行结束，Session Bean 和其数据会消失。
  • Entity Bean：维护一行持久稳固的数据，当客户端终止或会话结束，底层服务会将 Entity Bean 数据持久化。
  • Message-Driven Bean：结合了 Session Bean 和 JMS，允许异步接收消息。
• JSON：
  • 数据存储：首先，json 语法简洁明了，易于阅读和编写，降低了数据存储的复杂性。其次，json 支持多种数据类型，如字符串、数字、布尔值和对象等，使其可以方便的表示复杂的数据结构。此外，json 允许空值和可选字段，增加了数据的灵活性，缩小了所占空间。
  • 修改：json 基于文本的格式，可直接被程序解析和修改，也可直接通过文本编辑器进行查看和修改，便于开发调试。
  • 传输：json 格式紧凑，便于传输和存储，同时支持跨平台和跨语言的数据交换，这使得在不同系统或编程语言之间进行数据传输变得简单。
• 软件需求：
  • 业务需求：指组织机构或客户对系统或产品高层次的目标要求。
  • 用户需求：指用户使用产品必须要完成的任务，是用户对该软件产品的期望。这两者共同组成了用户最原始的需求内容。
  • 功能需求：也包括非功能需求，指软件开发人员必须要实现的功能，使用户能够完成他们的任务，从而满足业务需求。

2、结构化分析方法

• 流程图：以图形化的方式表示应用程序从数据输入到获得输出结果的逻辑过程，描述处理过程的控制流。
• 数据字典：用于建立业务概念有组织的集合，是模型核心库，有组织的系统相关数据元素列表，使涉众对模型中元素有共同的理解。
  • 数据模型：E-R 图。
  • 功能模型：DFD（数据流图）。
  • 行为模型/状态模型：状态转换图。
  • 在设计阶段：
    • 利用数据流图来初始化系统结构图。
    • 利用数据字典来建立数据库存储设计。
• 数据流图：说明业务处理过程、系统边界内所包含的功能和系统中的数据流。
  • 数据流图与流程图区别：
    • 数据流图展现系统的数据流，流程图展现系统的控制流。
    • 数据流图适用于系统分析的逻辑建模阶段，流程图适用于系统设计的物理建模阶段。
    • 数据流图的处理过程可并行，流程图在某一个时间点只能处于一个处理过程。
    • 数据流图展现全局处理过程，过程之间遵循不同的计时标准；流程图过程之间遵循一致的计时标准。
  • 高质量数据流图三原则：
    • 复杂性最小化原则：DFD 分层结构就是把信息划分为小且相对独立的一大批子集例子，这样就可以单独考查每一个 DFD。若想要了解某一个过程的详细信息，则跳转到其下一层即可；若想要了解某一个 DFD 如何与其它 DFD 相互关联，则跳转到其上一层考查即可。
    • 接口最小化原则：是复杂性最小化原则的一个具体规则。在设计模式时，应使得模型中各元素之间的接口数或连接数最小化。
    • 数据流一致性原则：一个过程和它的过程分解在数据流内容中是否存在差异？是否存在有数据流入但无数据流出的加工？是否存在无数据流入但有数据流出的加工？
  • 常见问题：
    • 黑洞：只进不出。
    • 奇迹：只出不进，无中生有。
    • 灰洞：无法加工的数据流。
    • 父图与子图不匹配：指父图中的加工的输入和输出与子图中的对应部分不一致。
    • 数据存储之间存在直接数据流。
    • 外部实体之间存在直接数据流。
    • 外部实体与数据存储之间存在直接数据流。

3、面向对象分析方法

• 对象模型、动态模型、功能模型：
  • 对象模型用于描述系统的数据结构，动态模型用于描述系统的控制结构，功能模型用于描述系统功能。三者都涉及数据、控制和操作等共同概念，但侧重点不同，从不同侧面反映了系统的实质性内容，综合起来全面反映了对目的系统的需求。
  • 功能模型指明了做什么，动态模型明确规定什么时候做，对象模型则定义了做事情的实体。
• 实体与类：
  • 实体用于数据建模，类用于面向对象建模。
  • 实体只有属性，类有属性和操作。
• 类关系：依赖、泛化、实现、聚合、组合、关联。
  • 依赖：一个事务的变化会影响另一个事务。
  • 泛化：特殊与一般，即继承。
  • 实现：接口与类，即抽象与实现。
  • 聚合：整体与部分生命周期不同，即部分脱离整体可以存在。
  • 组合：整体与部分生命周期相同，即部分脱离整体不能存在。
  • 关联：描述了一组链，链是对象之间的连接。
• 设计类：实体类、边界类、控制类
  • 实体类：用于映射需求中的每个实体，实体类保存需要持久化的信息。
  • 边界类：用于封装在用例内、外流动的信息或数据流。
  • 控制类：用于控制用例工作的类，一般是由动宾结构的短语（动词+名词或名词+动词）转化来的名词。
  • 设计类和分析类：
    • 分析类主要在需求分析和架构设计阶段产生。
    • 设计类主要在概要设计阶段产生。
• 利用用例与用例图表示需求，用例可以用交互图实现。从用例中提炼形成领域模型，从用例图和领域模型形成类图，从类图与包图形成体系结构图。
• 用例图：
  • 参与者：表示存在于系统外部并与系统进行交互的任何事物。既可以是使用系统的用户，也可以是其它外部系统或设备等外部实体。
  • 用例：表示系统所提供的服务。它定义了参与者是如何使用系统的，描述了参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
  • 通信关联：表示参与者与用例、或用例与用例之间的关系。箭头表示在这一关系中，哪一方是对话的主动发起者，哪一方是对话的被动接受者，其中箭头所指方为被动接受者，箭尾所指方为主动发起者。若不想强调主动与被动关系，则可使用不带箭头的关联实线。
  • 基础用例与抽象用例：
    • 基础用例：Real Use Cases，是实实在在与用户需求有对应关系的用例，是从用户需求获取的渠道得到的。
    • 抽象用例：Essential Use Cases，是从基础用例中抽取的用例的公共部分，是为了避免重复、优化结构而提出的用例。
  • 构建用例模型四阶段：识别参与者、合并需求获得用例、细化用例描述和调整用例模型。
• 顺序图/时序图/序列图：用于表示对象之间的交互，这些对象是按时间顺序排列的，其着重描述对象按时间顺序的消息交换。
  • 参与者：系统外参与交互的元素。
  • 对象：系统中参与交互的元素。
  • 时间线：由参与者或对象延伸出的一条时间线，表示个体在交互过程中的状态，虚线表示挂起，空心矩形表示激活。
  • 消息：对象之间的通信，可以传递消息并期望相关动作被执行。
    • 消息类型：同步消息、异步消息、返回消息、自关联消息。
  • 序列片段：为序列图增加一定程度的逻辑处理。
• 协作图（通信图）：用于表示系统行为是如何由系统成分实现的，其着重描述系统成分如何协同工作。
• 状态图：初始状态、终止状态、状态、事件、转换、动作、守护条件等。
• 活动图：
  • 并发分叉：将流程拆分为多个并行路径，表示多个活动可同时进行，提高处理效率。
  • 并发汇合：将多个并行路径重新合并，确保所有并发活动完成后再继续后续流程，保证流程完整性。
  • 泳道：将活动图中的活动按角色或实体分类，清晰展示参与者的职责与交互。
  • 监护表达式：在分支结构中使用的条件判断，决定流程在何种条件下选择特定路径，增加流程灵活性。
  • 分支：表示在某个活动的执行过程中，根据条件的不同选择不同的执行路径，是决策点。
  • 活动图与流程图：
    • 活动图是面向对象的；流程图是面向过程的。
    • 活动图可以表示并发活动的情形；流程图不能。
    • 活动图描述的是对象活动的顺序关系所遵循的规则，其着重表现系统的行为；流程图以图形化的方式表示应用程序从数据输入到获得输出结果的逻辑过程，其着重表示系统处理过程的控制流。

4、软件质量属性（架构评估）

• 质量属性：性能、可用性、可靠性、安全性、可修改性、易用性、可测试性、健壮性、互操作性等。
• 质量属性效用树：性能、安全性、可用性、可修改性。
  • 性能：指系统的响应能力，即要在多长时间内才能对某个事件做出响应，或在某个时间内能响应的事件的个数。
    • 增加计算资源、减少计算开销、引入优先级队列、引入并发机制、采用资源调度等。
  • 可用性：指系统能够正常运行的时间比例。
    • 心跳、ping/echo、主动冗余、被动冗余、选举、集群等。
  • 可靠性：指系统在发生错误或故障情况下，能够维持系统功能特性的能力。
    • 主动冗余、集群等（提高可靠性其实是提高了可用性，故可靠性策略也属于可用性策略）。
    • 成熟性、容错性、易恢复性、可靠性的依从性。
    • 冗余技术：
    • 软件容错技术：异常处理、事务机制等
    • 双机容错技术：
    • 集群技术：
    • 软硬件可靠性差异：
      • 从硬件角度分析，由于硬件一旦生产完成，其可靠性指标将会随着使用时间延长而逐步老化，从而带来可靠性降低，即呈现失效率服从浴缸曲线；而软件不存在随时间延长而老化的现象，因此，在不考虑软件演化的情况下，失效率在统计上是非增的。
      • 由于硬件是由多种电子器件组成，即使不使用，材料劣化也会导致失效；而软件就不同了，软件一旦调试完成，固化到设备中，在不考虑存储介质的老化因素的前提下，即使不使用该软件，软件也永远不会发生失效。
      • 由于硬件存在可更换性，其硬件通过维修，可恢复原始状态；而对于软件而言，一旦需要维护，必然是存在需求更改、程序存在bug等现象，其维护必然会创建新的软件代码。
      • 一般而言，硬件失效存在一个发展过程，在发生故障之前必然会有报警现象出现，而软件失效之前很少会有警告。
  • 安全性：指系统在向合法用户提供服务的同时能够拒绝非法用户使用系统的能力。
    • 信息安全五要素：机密性、完整性、可用性、可控性、可审查性
      • 机密性：确保数据不暴露给未授权的实体或进程。
      • 完整性：只有被授权的实体才可修改数据，并能判定出数据是否已被篡改。
      • 可用性：确保被授权的实体在需要时可访问数据，即攻击者不能使用所有资源阻碍被授权者的使用。
      • 可控性：可以控制授权范围内的信息刘向和行文方式。
      • 可审查性：对出现信息安全的问题提供调查的依据和手段。
    • 入侵检测、用户认证、用户授权、追踪审计等。
  • 可修改性：指能够快速地以较高的性能价格比对系统进行变更的能力。包括可维护性、可扩展性、可移植性、结构重组。软件模块泛化、限制模块之间通信、使用中介、延迟绑定等。
    • 可维护性：修复缺陷
    • 可扩展性：扩展系统
    • 可移植性：平台无关性，或为了适配新平台而做出的适当修改
    • 结构重组：重构
  • 易用性：指用户使用系统完成指定任务的难易程度。
  • 可测试性：指系统发现故障并隔离、定位故障的能力。
  • 健壮性：指在处理或环境中，系统能够承受压力或变更的能力。
  • 互操作性：指系统与外界或系统与系统之间的互作用能力。
• 质量属性场景 6 要素：刺激源、刺激、环境、制品、响应、响应度量。
  • 敏感点、权衡点、风险点、非风险点.
  • 敏感点：指一个或多个构件的特性，它能影响系统的某个质量属性。
  • 权衡点：指影响多个质量属性，并对多个质量数量来说都是敏感点的系统属性。
  • 风险点：指架构设计中存在潜在问题的架构决策所带来的隐患。
  • 非风险点：指不会带来隐患的分析或描述。
• ATAM（架构权衡分析法）架构评估方法：
  • 活动领域：场景和需求收集、架构视图和场景实现、属性模型构造和分析、架构决策与折中。
  • 主要过程：
    • 描述和介绍阶段：描述 ATAM 方法，描述业务动机，描述架构。
    • 调查和分析阶段：确定架构方法，生成质量属性效用树，分析架构方法。
    • 测试阶段：讨论场景和对场景分级，分析架构方法。
    • 最终阶段：描述评估结果。

5、数据库

5.1 传统数据库

• SQL 注入攻击：指将 SQL 命令插入到 web 表单提交、输入域名或页面请求的查询字符串中，最终达到欺骗服务器执行恶意 SQL 的命令。

  • 1、使用 PreparedStatement。
  • 2、使用存储过程。
  • 3、验证输入/过滤输入。
  • 4、使用专业的安全产品。

• 主从、主主：

  • 主从：
    • 优点：部署简单、读写分离、数据备份、高可用。
    • 缺点：主库崩溃后从库不会主动升级为主库，需要人工干预。
    • 适用场景：读多写少、数据备份。
  • 主主：
    • 优点：双主双写、故障自动切换。
    • 缺点：数据冲突风险、需要应用层处理冲突。
    • 适用场景：双向同步、小规模可靠。

• Hibernate、MyBatis、Mybatis-Plus

  维度	Hibernate	Mybatis	Mybatis-Plus
  ORM 类型	全自动	半自动	半自动（增强版）
  SQL 控制	自动生成，灵活性低	完全手动，灵活性高	手自（CRUD）一体
  性能	复杂查询性能低	高性能（优化方便）	高性能
  开发效率	高（简单场景）	低（需写 SQL）	高（内置 CRUD）
  适用场景	快速开发，数据库无关	复杂 SQL，高性能需求	快速 CURD，业务系统

• mysql 与 nosql

  维度	mysql	nosql
  数据模型	关系模型	列式存储，灵活可扩展
  可伸缩性	垂直或有限水平扩展	线性扩展，支持大规模集群
  一致性模型	强一致性	弱一致性（最终一致性）
  适用场景	复杂查询、事务处理	高并发写入、分布式系统、大数据场景

• mysql 与 es

  维度	mysql	es
  搜索引擎原理	基于 SQL 的查询引擎	基于 Lucene 的搜索引擎
  索引机制	B+树等	分词，倒排索引
  数据模型	关系模型	以文档模型为主的灵活的数据模型
  高可用模式	默认单机，可配置主从高可用模式	内置集群，默认支持分布和高可用模式
  适用场景	小规模数据的复杂查询、事务处理	大规模数据的全文搜索、实时数据分析和日志分析等

• mysql 与 neo4j（图数据库）

  维度	mysql	neo4j
  数据模型	关系模型	图模型
  查询复杂度	高（多表 join）	低（通过关系路径直接查询）
  一致性模型	强一致性	弱一致性（或最终一致性）
  适用场景	复杂查询、事务处理	多对多关系分析、社交网络查询

5.3 分布式数据库

• CAP 定理及一致性协议（分布式算法）：分布式理论与分布式算法

• 定义：指用计算机网络将物理上分散的多个数据单元连接起来组成的一个在逻辑上统一的数据库，每个被连接起来的数据单元称为站点或节点。

• 读写分离、数据分片、数据索引、数据缓存、负载均衡等。

• 主要特点：

  • 数据分布性：数据在物理上分布于不同的节点。
  • 逻辑整体性：数据在逻辑上是相互关联的统一整体。
  • 节点自治性：每个节点可以独立处理本地数据。
  • 使用透明性：用户无需知道数据存储在哪个节点上。

• 分布式数据库模式：

  • 全局概念模式：定义分布式数据库中数据的整体逻辑结构，数据就如同根本没有分布一样，可使用传统的集中式数据库所采用的方法进行定义。
  • 全局外模式：是全局应用的用户视图，是全局概念模式的子集，该层直接与用户交互。
  • 局部概念模式：是局部数据库的概念模式。
  • 局部内模式：是局部数据库的内模式。
  • 分片模式：讲一个关系模式分解成多个数据片。
  • 分布模式：定义分片模式的处理结果的存放节点，即数据分布在不同的物理位置。

• 分布模式：

  • 共享磁盘（存储）架构（Shared-Disk）：所有节点共享统一存储设备，但计算资源独立。其优点是数据一致性易维护，缺点是存在单点故障风险且扩展受限。适用于读多写少、小规模、低并发场景。
  • 无共享架构（Shared-Nothing）：每个节点独立存储和处理本地请求，节点间通过消息传递写作。其优点是容错性高易扩展、大数据量高并发，缺点是引入了数据一致性问题、数据分片问题和事务处理的复杂性。适用于分布式、大规模、高并发场景。
  • 多主复制（分片）架构（Sharding）：数据按特定规则划分为多个分片，分布到不同节点，多节点共同提供读写服务。其优点是高可用、高负载，缺点是数据冲突和一致性问题，且实现复杂。别用。

• 分片模式：

  • 水平分片：
    • 哈希分片：对分片字段（如用户 id）进行哈希，将数据均匀分配到多个节点上，适用于均匀分布的数据。
    • 范围分片：按分片字段（一般为时间字段）将数据以时间范围为条件分配到多个节点上。适用于时间性较强的数据。
  • 垂直分片：按特定列的字段值切分，通常用于逻辑上的分片。如根据地区或部门切分。
  • 混合分片：结合水平分片与垂直分片，应该对复杂业务需求。

• 数据复制：

  • 主从复制：一主多从，主节点负责处理写请求，并将写操作结果同步到从节点，多从节点负责处理读请求。其优点是实现简单、易于理解，读写分离、提高性能；缺点是单点故障需手动升级主节点，主从同步可能存在延迟，导致数据不一致。
    • 全同步复制：主库完成一个事务后，会等待所有从库完成同步再返回。数据一致性高但性能较低。
    • 半同步复制：主库完成一个事务后，会等待至少一个从库完成同步再返回。牺牲了一定性能但提高了数据安全性。
    • 异步复制：主库完成一个事务后立即返回，不会等待从库完成同步。性能高但数据一致性差。
  • 多主复制：多个主节点同时处理写请求，并将写操作结果同步给各自从节点。其优点是无单点故障、写入性能高；缺点是数据冲突与实现复杂。
  • 链式复制：节点以链式结构存在。写请求先由头节点处理，然后依次传递给后继节点，读请求由链中任意节点处理。其优点是数据一致性强、且避免了数据冲突，缺点写操作延迟较高（尤其是链较长时）、链中单节点故障会导致链中断。适用于读多写少且对数据一致性要求高的场景。

• 一致性模型：

  • 强一致性：
    • 线性一致性：写入的值在调用和完成之间可以被其它节点读取出来，即不会读到数据转换的过程和中间未完成的状态。
    • 顺序一致性：
  • 弱一致性：
    • 因果一致性：
    • 最终一致性：副本之间的数据复制完全是异步的，即写操作执行完后，会以异步的方式在一段时间后同步到其余副本，这段时间可以是毫秒、数天、甚至永远，总之最终它一定会同步的。
    • 客户端一致性：

• 事务处理：

  • 见下文 分布式事务。

• 查询优化：

  • 数据库定位优化：分片裁剪（只访问当前节点分片规则内的数据）、全局索引（维护分片键与物理位置的映射）、本地索引（各分片维护自己的索引）。
  • 连接操作优化：广播连接（将小表复制到所有节点）、重分布连接（按连接键重新分布数据，即将连接键相关的一组数据分布到同一节点上）、本地化连接（同一分片上的表直接连接）。
  • 聚合操作优化：各节点执行局部聚合，合并节点执行全局聚合。
  • 并行执行优化：流水线并行（不同操作阶段重叠执行）、分区并行（不同数据分区并行处理）、操作符并行（单个操作符内部分解为子任务）。
  • 网络传输优化：列式传输（只传输查询需要的列）、数据压缩（减少网络传输量）、批处理（合并多个小请求为批量请求）。

• 挑战：

  • CAP 权衡：分布式系统中 p 不可避免，故只能在 cp 和 ap 二者之间抉择，如金融系统选强一致性，社交网络选高可用性。
  • 事务处理：跨多个节点事务处理。
  • 查询优化：数据分片导致。
  • 运维管理：复杂度提高。

• 主流分布式数据库对比：

  数据库	类型	一致性模型	特点	适用场景
  Google Spanner	NewSQL	强一致性	全球时钟同步	金融、跨洲际强一致性
  CockroachDB	NewSQL	强一致性（线性）	兼容 pgSQL、自动分片	全球化部署、HTAP
  TiDB	NewSQL	强一致性（线性）	兼容 MySQL、HTAP 架构	实时分析、高并发事务
  Cassandra	NoSQL	最终一致性	高写入吞吐、多数据中心复制	社交网络、时序数据
  MongoDB	NoSQL	可调一致性	灵活文档模型、自动分片	内容管理、物联网

6、系统架构

• 架构风格：描述某一特定应用领域中系统组织方式的惯用模式。

  • 虚拟机：适用于根据自身状态和外界环境进行动态调整的系统。

    • 规则系统：适用于根据自身状态和外部环境或事件进行改变的系统，将业务逻辑中频繁变化的部分定义为规则。如扫地机器人系统。也适用于专家系统。
    • 解释器：适用于在系统运行期间变更系统行为和能力的系统。如玩家自定义游戏地图。

  • 黑板：适用于专家系统，解空间很大，需要知识推理。如语音识别系统。

  • 过程控制：适用于控制系统。如车辆定速巡航。

  • 数据仓储：集成开发环境。

  • 管道过滤器：上一个构件的输出结果作为下一个构件的输入。如传统编译器（现代编译器采用数据共享风格）。

    • 每个构件都有一组输入和输出，构件接受输入的数据流，经过内部处理，产生输出的数据流，可以并行处理。

  • Rest：资源抽象，将系统中的每一个实体抽象成一种资源。

  • 批处理：串行执行，强调顺序执行，数据以整体的方式传递。

  • 隐式调用：即异步。

  • C2：通过连接件绑定在一起的按照一组规则运行的并行构件网络。系统组织规则如下：系统中的构件和连接件都有一个顶部和底部，构件的顶部应该连接到某连接件的底部，构件的底部应该连接到某连接件的顶部，构件之间不允许直接连接，一个连接件可以和任意数目的其他构件或连接件连接，当两个连接件进行连接时，必须由其中一个的顶部到另一个的底部。

• 微服务架构：

  • 微服务是一种架构风格，是分布式架构的一种解决方案，是由 SOA 架构演化而来。其作用是将一个大型应用以业务为界限划分为多个小型应用，每个小型应用可独立开发、部署和维护，且具有自治性，即分散能力。
  • 优点：服务独立性与可扩展性、技术多样性、容错与隔离性、可维护性、团队自治性
  • 缺点：架构复杂度高、网络性能与延迟、安全性挑战、运维负担、成本上升、服务拆分风险。
  • 关键原则：单一职责松耦合、独立部署可伸缩、注册发现自治性、接口明确容错性。
  • 应用网关作用：路由与负载均衡、认证与授权、请求过滤与转换、监控与日志、限流与降级。
  • 微服务架构如何保证数据一致性和高可用性：
    • 数据一致性：
      • 分布式事务：使用两阶段提交（2PC）、三阶段提交（3PC）或基于 SAGA 的分布式事务解决方案，确保跨多个服务的数据一致性。但分布式事务可能会引入额外的复杂性和性能开下，因此需谨慎使用。
      • 最终一致性：在不要求强一致性的场景下，可使用最终一致性模型。使用事件驱动架构（EDA）或消息队列等方式异步地更新数据，使数据在一定时间后达到一致状态。这种方式可提高系统的可用性和性能。
    • 高可用性：
      • 熔断与降级：为防止某个服务的故障影响到整个系统，可使用服务熔断机制。当某个服务调用失败率达到一定阈值后，自动熔断该服务，以防止进一步的失败扩散。同时，可实施服务降级策略，在资源不足或系统负载过高时，提供简化的服务响应。
      • 数据复制与缓存：通过数据复制与缓存技术，来提高数据的可用性和访问速度。如通过数据库的主从复制来确保数据的可用性，通过数据缓存来减少数据库访问压力同时提高数据访问速度。

• 反规范化设计：增加冗余列、增加派生列、表重组、表分割。

• 持久层：根据分层思想，通过建立逻辑数据操作接口，采用一定的对象/关系映射策略，隐藏数据库访问代码细节，向业务逻辑开发人员提供透明的对象持久化操作机制。

  • 分离业务逻辑层和数据层，降低两者之间的耦合。
  • 通过对象/关系映射向业务逻辑提供面向对象的数据访问。
  • 简化数据层访问，隐藏数据库连接、读写命令和事务管理等细节。

• 反规范化设计：

  • 增加冗余列：
  • 增加派生列：
  • 表重组：
  • 表分割：

• 列式数据库优点：

  • 列式数据库将数据存储为列族，对于特定列的查询能够更快的定位到数据，提高了查询效率。
  • 列式数据库支持分布式存储和并发处理，能够处理PB级别的数据，且易扩展。
  • 列式数据库提供了高效的数据压缩和存储介质，降低了存储成本。
  • 列式数据库能够与Hadoop等大数据处理平台无缝集成，系统负责度低。

• 分布式文件系统（HDFS）:

  • 数据可靠性：通过数据冗余存储（默认3副本）和自动容错机制（数据块复制、心跳检测和数据块扫描）来保证数据的可靠性。
  • 可伸缩性：通过增加更多的节点来线性扩展存储容量，能够支持 PB 级数据的存储。
  • 性能：通过数据本地化、优化读写路径和利用硬件特性（如磁盘并行读写）来提高数据传输和处理效率。

• 消息队列：解耦、削峰填谷、异步、发布订阅、可伸缩性、容错性、持久化、低延迟、生态系统支持。

  • 优点：
    • 解耦：提高系统可扩展性和灵活性。
    • 削峰填谷：平衡系统负载。
    • 异步：异步处理，提高系统吞吐量。
    • 发布订阅：实现消息的订阅和选择性传递。
    • 可伸缩性：通过增加更多节点来线性伸缩，以适应不断增长的数据量。
    • 容错性：通过数据复制和分区机制来提供强大的容错能力。
    • 持久化：允许用户根据需要调整数据的保留策略和副本因子，以适应不同的业务场景。
    • 生态系统支持：强大的生态系统和丰富的 api，可无缝集成到现有系统或框架中。
  • 缺点：
    • 消息队列设计管理较复杂。
    • 可能出现消息丢失、重复或乱序问题。
    • 需要处理消息队列延迟和吞吐量瓶颈。

• RESTful 与 gRPC：

  • 前者基于 http 文本协议，后者基于 http 二进制协议。
  • 前者性能较低，后者性能极高。
  • 前者使用文本格式（如 json、xml）进行编码，可读性强；后者使用二进制（Protocol Buffers）编码，高效紧凑。
  • 前者跨平台、跨语言和易用性高；后者灵活性低、耦合度高。

• ES：

  • 分词原理：将输入的文本字符串切分成独立的词汇，以便在索引和查询时进行有效地匹配。分词过程通常包括字符过滤（如去除标点符号、停用词等）、词汇切分和词汇归一化（如大小写转换等）等步骤。
  • 自定义分词器：通过 ES 的插件机制或配置自定义分析器实现。自定义分析器可包括自定义字符过滤器、分词器和词汇过滤器。此外，还可以根据业务需求调整分词策略，如基于统计的分词方法和基于规则的分词方法。
  • mysql 数据同步 es：
    • 基于 binlog 的同步方法：其优点是灵活性高，可精确控制要同步的数据。常见的工具有 LogStash、Canal 等。
    • 基于 mysql 的插件同步方法：一些插件能够直接在 mysql 中捕获数据变更，并将其同步至 es，如 go-mysql-es。
    • 同步双写方法：在 mysql 中进行数据修改操作时，将这些修改写入 es。
    • 异步双写方法：在 mysql 中进行数据修改时，先将这些修改写入 MQ 等消息中间件，然后再由消息中间件写入 es。
    • 定时任务同步方法：通过定时任务结合 SQL 查询与批量导入实现数据的定期同步。
  • es 与 自建 redis 集群区别：
    • 成本：前者提供按需付费的云服务，初期成本低，但随着业务增长后期成本高；后者需要自行承担硬件和维护成本，但长期成本可控。
    • 灵活性：前者提供了多种配置项，但可能受限于云服务商的设定；后者可根据业务需要自行配置和优化。
    • 扩展性：前者支持自动扩展，但可能受限于云服务商的扩展策略；后者可通过增加节点和重新分片来灵活扩展。

• 容器化技术的优势：

  • 环境一致性：容器化技术将微服务及其所有依赖项打包成一个独立的运行单元，确保其在不同环境中（开发、测试、生产）运行的一致性。
  • 资源隔离性：容器化技术将微服务封装在自己的容器中，实现了资源（如 CPU、内存和网络等）的隔离，避免了服务之间的资源竞争和冲突。
  • 快速部署与伸缩：容器化技术使得微服务的部署和扩展变得更加简单高效，可通过容器编排工具，实现自动化的部署、伸缩和管理。
  • 简化运维：容器化技术简化了运维操作。可通过容器编排工具轻松实现监控服务、重启服务、日志收集、故障排查等，提高了运维效率。

1. 数据迁移准备工作：

   1. 待迁移数据源的详细说明，包括数据存储方式、数据量和时间跨度。
   2. 建立新旧系统数据库的数据字典，对现有系统的历史数据进行质量分析，对新旧系统的数据格式进行差异分析。
   3. 对新旧系统的代码数据进行差异分析。
   4. 建立新旧系统数据库表的映射关系，对不能映射的数据库字段建立处理关系。
   5. 编写数据转换的测试计划的校验程序。
   6. 指定数据转换的应急措施。

2. rest 与 rpc：

   1. 前者基于 http 的文本协议；后者基于 http 的二进制协议。
   2. 前者性能较低；后者性能极高。
   3. 前者使用文本格式（如 json、xml等）进行编码，可读性强；后者使用二进制（Protocol Buffers）进行编码，高效紧凑。
   4. 前者跨平台、跨语言、易用性高；后者灵活性低、耦合度高。
   5. rest 风格设计原则：
      1. 网络上的所有资源都被抽象为资源，每个资源都有唯一的资源标识。
      2. 通过通用的连接件接口对资源进行操作，对资源的操作不会改变资源标识。
      3. 所有操作都是无状态的。

3. 数字信封加密：

   1. 加密过程：首先生成一个对称密钥，然后使用用户公钥对对称密钥进行加密并将加密结果存储在文件头中，最后使用对称密钥对文件内容进行加密。
   2. 解密过程：使用用户私钥对文件头中被加密的对称密钥进行解密，然后使用解密得到的对称密钥对文件内容进行解密。

4. 数据库敏感字段加密：

   1. 加密 api：由数据库管理系统提供的可在 sql 中使用的加解密 api，对数据进行安全防护。灵活性强，但构建和管理复杂。
   2. 透明加密：由安全管理员为敏感字段选择加密方式和密钥强度，应用访问数据时只需要使用口令打开或关闭密钥表，实际对数据的加解密由数据库管理系统实现。管理简单，应用程序负担轻，但灵活性差。

5. SSH：

   1. Struts 框架由于其组件在页面显示的粗粒度和框架类的限制，在很多情况下会表现的过于死板，给表现层的开发带来额外的代码开销。
   2. Spring 框架通过依赖注入使得它可以轻易实现 bean 的装配，且提供了简洁的 aop 特性并据此实现事务功能，但其缺点是不支持分布式事务。
   3. Hibernate 是一个对象关系映射框架，其对 jdbc 进行了轻量级的封装，使其可以在任何使用 jdbc 的场景下，完成对数据持久化的重任。
   4. 轻量级框架：侧重于减小开发复杂度，提高开发效率，相应的它的处理能力将有所减弱，如事务能力，分布式处理能力，适用于开发中小型企业应用。
   5. 重量级框架：强调高可伸缩性，适用于开发大型企业应用。

6. 数据整合-信息服务：

   1. 联邦服务：提供将各种类型的数据聚合能力，它可以是关系型数据，也可以是非关系型数据，同时，各类数据仍然按照自己本身的方式管理。
   2. 复制服务：提供远程数据本地访问的能力。它通过自动实时的数据转换，在本地维护一个远程数据源的副本。本地数据和数据源在技术实现上可以实独立的。
   3. 数据转换：将数据源数据格式转换为目标数据格式，可以是批量的也可以是基于记录的。
   4. 搜索能力：提供对企业数据的检索能力，可以是关系型数据，也可以是非关系型数据。

7. 逆向工程：软件重构、设计恢复、重构工程。

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

8. 软件重构：

   1. 重构三类别：代码重构、模块重构、架构重构。
   2. 常见重构方法：重新组织函数、重新组织对象、重新组织数据、简化条件表达式、简化函数调用、处理概括关系。

9. 索引过多副作用：

   1. 索引过多会占用大量存储空间。
   2. 索引过多会降低插入和更新效率，因为 insert 和 update 可能会重建索引。
   3. 索引过多会导致查询优化器需要评估的组合增多。
   4. 每个索引都有对应的统计信息，索引越多则需要统计的信息就越多。
   5. 聚集索引的变化导致非聚集索引的同步变化。

10. 层次架构优点：

    1. 良好的复用性。
    2. 可维护性好。
    3. 可扩展性好。
    4. 合理的分层可降低系统耦合度。
    5. 将相同的逻辑和抽象层次放在同一层，便于理解。

11. 数据库扩展：

    1. 集中式：向上扩展，硬件扩容（增加 CPU 数量、内存容量、磁盘容量）和硬件升级（更换性能更高的硬件）。
    2. 分布式：向外扩展，如数据复制、数据垂直切分或水平切分、缓存和全文检索等。

12. 提升数据访问性能：

    1. 减少数据访问：即减少磁盘访问。反规范式、冗余、派生、缓存。
    2. 减少网络传输：分页、字段裁剪、请求合并、批量请求。
    3. 减少 CPU 开销：优化业务逻辑。
    4. 利用更多资源：主从复制、读写分离。