架构设计系列（五）：数据存储_参数存储比较好用的程序架构-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_31366767/article/details/145668269

一、概述

在技术选择中，数据存储方案的选择极其重要。为自己的项目选择适合的数据存储是一项复杂的任务。不同的数据库的诞生是为了解决现实存在的业务场景，市面上的数据库产品众多，这样子也会导致在做技术选型的时候产生决策疲劳。
下图是关于云服务中不同数据库的详细列表：
在这里插入图片描述

在数据存储的中，不同数据类型（如数值、字符串、地理坐标等）需要差异化处理机制。系统负载特征（写入密集型或读取密集型）也是关键考量因素，根据不同的实际应用场景，数据库采用的存储策略也不同，可以选择内存索引或磁盘存储策略。
在这里插入图片描述
以下是当前主流的索引数据结构实现方案：

下图是sql在数据库中执行的流程：
在这里插入图片描述

sql通过网络层协议（eg：tcp）发送到数据库服务
当数据库服务接收到sql语句以后将会在命令分析器进行对的语法分析，其解析过程分为三个过程：
- 词法解析：将sql 语句解析为token，主要是识别sql 语法中的关键字，判断是否有拼写及其他错误的用法。
- 语法分析：分析语句的语法生成对应的抽象语法树（AST），其主要功能是识别语句是否合法，例如 form 后面是否带表明，或者是否以select。。等开头等。
命令解析完成以后根据其生成的语法数，数据库将对sql语句进行查询优化，生成对应的执行计划
在做完一系列的解析以后，执行器会根据执行计划去调用对应存储引擎的执行方法操作数据库。
Access methods 提供获取数据的所需的逻辑处理，并从存储引擎中检索数据。
Access methods在数据检索时会先判断命令是否为查询语句，如果是则调用缓存管理器处理，缓存管理器会在缓存或数据文件中查找数据。
如果是UPDATE or INSERT等语句，则开始调用事务管理器，开启事务。
在事务开启期间，数据的操作处于上锁状态，事务管理器复杂锁的管理，这也是为了确保数据的ACID。

在计算机科学中CAP是一个著名的定律，对于该定律我想不同开发者有不同的理解。
在这里插入图片描述
分布式系统无法同时满足一致性（C）、可用性（A）和分区容错性（P）。

三选二原则在实际中很常用，但是简单化的描述会带来误解。

定理核心约束
- 分布式系统无法同时满足一致性（C）、可用性（A）和分区容错性（P）
- 网络分区（Partition）的必然性：
  - 物理网络故障（链路中断、交换机故障）
  - 逻辑分区（高延迟、丢包）
系统设计权衡分析
- CP系统（一致性+分区容错性）
  - 强一致性（Linearizability）
  - 分区时拒绝写入（Unavailable）
  - 实际应用：
    - ZooKeeper：ZAB协议（ZooKeeper Atomic Broadcast）
    - etcd：Raft共识算法
    - HBase：基于HDFS的强一致性存储
  - 实际业务场景：
    - 金融交易系统
    - 分布式锁服务
    - 配置管理中心
- AP系统（可用性+分区容错性）
  - 最终一致性（Eventual Consistency）
  - 分区时继续服务（Available）
  - 实际应用：
    - Cassandra：Gossip协议+Quorum机制
    - DynamoDB：向量时钟（Vector Clock）冲突解决
    - Riak：CRDTs（无冲突复制数据类型）
  - 实际业务场景：
    - 社交网络
    - 内容分发网络（CDN）
    - 实时推荐系统
- CA系统（一致性+可用性）
  - 仅适用于单数据中心（非分布式）
  - 无法容忍网络分区
  - 实际应用
    - 单机数据库（如MySQL单实例）
    - 传统关系型数据库（无分布式扩展）
  - 实际业务场景：
    - 小型应用系统
    - 非关键业务存储
- CAP与分布式协议