这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天。
01. 经典案例
1.2 RDBMS事务ACID
ACID：
- 原子性（Atomicity）：事务是一个不可在分割的工作单元，事务中的操作要么都发生，要么都不发生。
- 一致性（Consistency）：数据库事务不能破坏关系数据的完整性以及业务上的一致性。
- 隔离性（Isolation）：多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其他事务运行效果。
- 持久性（Durability）：在事务完成以后，该事务对事务所作的更改便持久地保存在数据库之中，并不会回滚。
02. 发展历史
文件系统
2.3.2 DBMS数据模型
- 网状模型
- 层次模型
- 关系模型
2.5 SQL语言
03. 关键技术
3.1 一条SQL的一生
3.2 SQL引擎 - Parser
解析器（Parser）一般分为词法分析（Lexical analysis）、语法分析（Syntax analysis）、语义分析（Semantic analyzer）等步骤。
3.2 SQL引擎 - Optimizer
为什么需要一个优化器（Optimizer）？
基于规则的优化（RBO Rule Base Optimizer）
- Scan优化
唯一索引
普通索引
全表扫描
数据库索引：是数据库管理系统中的辅助数据结构，以协助快速查询，更新数据库表中数据。目前数据库中最常用的索引是通过B+树实现的。
基于代价的优化（CBO Cost Base Optimizer）
SQL引擎 - Executor
3.4 事务引擎 Atomicity与Undo Log
Undo Log是逻辑日志，记录的是数据的增量变化。利用Undo Log可以进行事务回滚，从而保证事务的原子性，同时也实现了多版本并发控制（MVCC），解决读写冲突和一致性读的问题。
Isolation与锁
Isolation与MVCC
Durability与Redo Log
如何保证事务结束后，对数据的修改永久地保存？
方案一：事务提交前页面写盘
方案二：WAL（Write-ahead logging）
redo log是物理日志，记录地是页面的变化，它的作用是保证事务持久化。如果写入磁盘前发生故障，重启MySQL后会根据redo log重做。
04. 企业实践
挑战：流量大、流量突增、稳定性
4.2 大流量 - Sharding
问题背景
- 单节点写容易成为瓶颈
- 单机数据容量上限
解决方案
- 业务数据进行水平拆分
- 代理层进行分片路由
实施效果
- 数据库写入性能线性扩展
- 数据库容量线性扩展
4.3 流量突增 - 扩容
问题背景
- 活动流量上涨
- 集群性能不满足要求
解决方案
- 扩容DB物理节点数量
- 利用影子表进行压测试
实施效果
- 数据库集群提供更高的吞吐
- 保证集群可以承担预期流量
4.4 流量突增 - 代理连接池
问题背景
- 突增流量导致大量建联
- 大量建联导致负载变大，延时上升
解决方案
- 业务侧预热连接池
- 代理侧预热连接池
- 代理侧支持连接队列
实施效果
- 避免DB被突增流量打死
- 避免代理和DB被大量建联打死
4.5 稳定性&可靠性 - 3AZ高可用
- 三机房部署
- proxy
- 监控报警
HA管理
问题背景
- DB所在机器异常宕机
- DB节点异常宕机
解决方案
- HA服务监管、切换宕机节点
- 代理支持配置热加载
- 代理自动屏蔽宕机读节点
