这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天
RDBMS(关系型数据库)
RDBMS事务
事务：由一组SQL语句组成的一个程序执行单元，需要满足ACID特性
原子性：操作同时发生，不多展开
一致性：每一个操作都是合法的，比如转账，我只有1元，但是我要给你转2元，此时我的账户金额变成负一元，这是不合法的，这种操作违背了一致性（注重业务逻辑的合法性）
隔离性：两个操作在对一个账户并发操作时，应该是互不影响的，表现得像似串行操作
持久性：操作的结果应该永久保留，不会因为其他原因丢失
前DBMS时代
人工管理（低效）->文件系统（存储介质变化）
DBMS时代
DBMS：按照某种数据类型来组织、存储和管理数据的仓库
网状数据库（第一个数据库）： 父子节点的关系，且父子节点之间是多对多的关系 m：n
层次模型：树形结构，父子节点的关系，每个父节点可以有多个子结点，但是每个子结点只有一个父节点，1：n
关系模型：用关系描述数据特征，所有的数据都是一张二维表，每一行代表一个数据实体，每一列代表一条属性
模型对比
| 网状模型 | 层次模型 | 关系模型 | |
|---|---|---|---|
| 优势 | 直接描述现实世界、存取效率高 | 结构简单、查询效率高、提供较好的完整性支持 | 实体与实体间的联系都是通过二位表结构表示、可以方便的表示M：N关系、数据访问路径对用户透明 |
| 劣势 | 结构复杂、用户使用困难、访问程序设计复杂 | 无法表示M：N关系、插入删除限制多、遍历子节点必须经过父节点、访问程序设计复杂 | 关系查询效率不够高、关系必须规范化 |
SQL语言（结构化查询语言）
语法风格接近自然语言、高度非过程化、面向集合的操作方式、语言简洁，易学易用
c++等是详细的过程化语言，与SQL不同
一条SQL的一生
客户端发送一条请求（request）到router（路由），路由转发SQL语句到数据库，数据库解析SQL语句，如下
Parser（语法解析器）把SQL语言转化为AST（语法树）传到Optimizer（优化器），Optimizer根据AST生成Plan（树状结构）交给Executor（执行器），Executor根据Plan读写Data File（数据文件）并写入 Log File（日志文件），然后将执行结果返回到数据库然后一级一级返回到客户端
其中，Parser、Optimizer、Executor都是SQL引擎、Data File、 Log File都是存储引擎
SQL引擎
Parser一般分为词法分析（提取词组）、语法分析（形成结构）、语义分析（合法性校验）三个步骤
Optimizer，基于规则优化（RBO）、基于代价的优化（CBO），代价一般指时间，此外还有IO、CRU、NET、MEM等
Executor，火山模型使用最多（投影->过滤->扫描->存储引擎）优点（每个算子独立抽象实现，相互之间没有耦合，逻辑结构简单），缺点（每计算一次有多次函数调用开销，导致CPU效率不高）、向量化模型、编译执行模型
存储引擎
内存态：数据缓存（访问内存的代价和访问磁盘的代价差距很大，所以要做数据缓存）
数据态：存储数据元信息、存储用户真实数据、存储事务日志
事务引擎
Undo Log：逻辑日志，记录数据的增量变化，可以进行事务的回滚，保证事务的一致性原则，同时支持MVCC（多版本并发控制），解决读写冲突和一致性读的问题
存在读写并发问题时，因为读使用共享锁，写使用排他锁，并发执行会导致阻塞
MVCC：读写互不阻塞、降低死锁概率、实现一致性读，其原理是，让写用于新版本数据，读用于老版本数据
大流量问题
Sharding
解决方案：业务数据进行水平拆分、代理层进行分片路由
实施效果：数据库写入性能线性增长、数据库容量线性扩展
流量突增问题
扩容
解决方案：扩容DB物理节点数量、利用影子表进行压测
实施效果：数据库集群提供更高的吞吐、保证集群可以承担预期流量
代理连接池
解决方案：业务侧预热连接池、代理测预热连接池、代理测支持连接池
实施效果：避免DB被突增流量打死、避免代理和DB被大量建联打死
稳定性和可靠性
3AZ高可用
三机房部署：机房级别容灾、机房级别流量调度
proxy：读写分离、分库分表、限流、流量调度
监控报警：实时监控集群运行状态、提前上报集群风险
HA管理
解决宕机问题
解决方案：ha服务监管、切换宕机节点、代理支持配置热加载、代理自动屏蔽宕机读节点
