RDBMS | 青训营笔记

RDBMS | 青训营笔记

这是我参与「第三届青训营 -后端场」笔记创作活动的第 5 篇笔记

ACID

• Atomicity: 事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生
• Consistency: 数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性
• Isolation: 多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果
• Durability: 在事务完成以后，该事务所对数据库所做的更改便持久的保存在数据库之中，并不会被回滚

其他: Concurrency、Availability

SQL 执行过程

包含 SQL 引擎、存储引擎以及事务引擎

SQL 引擎

• Paser：经过词法分析、语法分析生成语法树，然后对语法树进行合法性校验
• Optimizer：根据 Parser 产生的语法树，根据规则或者代价产生执行计划树
• Executor：根据计划树进行执行，常见的执行方式是火山模型

存储引擎

存储引擎负责了数据的底层存储、管理和访问工作。

InnoDB：

• Buffer Pool：存储引擎位于内存中的重要结构，用于缓存数据，减少磁盘 IO 的开销
• Page：数据存储的最基本单位，一般为 16KB
• B+ Tree：InnoDB 中最常用的索引结构

---

事务引擎

事务引擎实现了数据库的 ACID 能力。主要看 InnoDB 通过什么方法实现了 ACID

• Atomicity：InnoDB 中通过 undo 日志实现了数据库的原子性，通过 Undo Log，数据库可以回滚到事务开始的状态；

• Isolation：通过 Undo Log 实现 MVCC（多版本并发控制），降低读写冲突

• Durability：通过 Redo Log（一种 WAL 实现方式）来保证事务在提交后一定能持久化到磁盘中

• Consistency：本质上是一种业务层的限制。

---

解决大流量、流量突增、高可靠

大流量 - Sharding

分析: 单节点写容易成为瓶颈；单机数据容量上限

• 解决方案：
  1. 业务数据进行水平拆分
  2. 代理层进行分片路由

流量突增 - 扩容

分析：活动流量上涨，集群性能不满足要求

• 解决方案：
  1. 扩容 DB 物理节点数量
  2. 利用影子表进行压力测试
• 结果：
  1. 数据库集群更高吞吐
  2. 保证集群可以承担预期流量

流量突增 - 代理连接池

分析：活动流量上涨 -> 大量建立数据库连接 -> 复杂变大，延时上升

• 解决方案：
  1. 业务侧预热连接池
  2. 代理侧预热连接池
  3. 代理侧支持连接队列
• 结果：
  1. 避免 DB 被突增的流量打死
  2. 避免代理和 DB 被突增的大量连接打死

稳定性&可靠性 - 3AZ 高可用

AZ（Availability Zone）

• 三机房部署

  • 机房级别容灾
  • 机房级别流量调度

• Proxy

  • 读写分离，分库分表
  • 限流，流量调度

• 监控报警

  • 实时监控集群运行状态
  • 提前上报集群风险

• HA（High Availability）

  • 实时监控 DB 运行状态
  • 宕机快速切换

稳定性&可靠性 - HA管理

分析：DB 所在机器宕机；DB 节点宕机

• 解决方案：
  1. HA 服务监管、切换宕机节点
  2. 代理支持配置热加载
  3. 代理自动屏蔽宕机读节点
• 结果：
  1. 读节点宕机秒级恢复
  2. 写节点宕机 30s 内恢复服务