这是我参与[第五届青训营]伴学笔记创作活动的第8天
一、经典案例
每年春节抖音红包雨
数据库所要执行的SQL语句，需要满足ACID特性，高并发，高可靠
BEGIN;
UPDATE account_table SET balance=balance-'小目标' where name ='抖音';
UPDATE account_table SET balance=balance+'小目标' where name ='羊老师';
COMMIT;
二、发展历史
1、前DBMS
人工管理——在现代计算机发明出来以前，通过人工的方式进行数据记录和管理
文件系统——1950s，现代计算机雏形基本出现。1956年IBM发布了第一个磁盘驱动器，从此数据存储进入磁盘时代，数据管理通过 文件系统来实现
DBMS时代：传统的文件系统不能满足人们的需要，数据库管理系统（DBMS）应运而生。DBMS即是按照某种数据模型来组织、存 储和管理数据的仓库。根据数据模型特点，传统的数据库管理系统可分成网状数据库、层次数据库和关系数据库三类
2、DBMS数据模型
网状模型
基于网状数据模型建立数据之间的联系，可以反映现实世界中消息的关联。
层次模型
用树形结构来描述实体及其之间关系
关系模型
使用表格表示实体和实体之间关系
三种数据模型的优劣比较
3、SQL语言
SQL(Structured Query Language)语言
语法风格接近自然原因呢
高度非过程化
面向集合的操作方式
语言简洁，易学易用
三、关键技术
1、一条SQL的一生
2、SQL引擎
Parse
解析器（Parser）一般分为词法分析，语法分析、语义分析等步骤
具体如下：
Optimizer（优化器）
基于规则的优化(RBO)
条件化简
表连接优化
总是小表先进行连接
Scan优化
唯一索引
普通索引
全表扫描
数据库索引：是数据库管理系统中辅助数据结构，以协助快速查询、更新数据库表中数据。目前数据库中最常用的索引是通过B+树实 现的
基于代价的优化（CBO）
一个查询有多种执行方案，CBO会选择其中代价最低的方案去真正的执行
Executor
火山引擎
每个Operator调用Next操作，访问下层Operator，获得下层Operator返回的一行数据，经过计算之后，将这行数据返回给上层
优点：每个算子独立抽象实现，相互之间没有耦合，逻辑结构简单
缺点：每计算一条数据有多次函数调用开销，导致CPU效率不高
解决方案：向量化、编译执行
向量化
每个Operator每次操作计算的不再是一行数据，而是一批数据（Batch N行数据），计算完成后向上层算子返回一个Batch
优点：函数调用次数降低为1/N
CPU cache命中率更高
可以利用CPU提供的SIMD（Single Instruction Multi Data）机制
编译执行：
将所有操作封装到一个函数里面，函数调用的代价也能大幅度降低
LLVM动态编译执行技术
3、存储引擎
InnoDB
Buffer Pool
Page
B+ Tree
页面内：
页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录
4、事务引擎
事务代码:
BEGIN;
UPDATE account_table SET balance=balance-'小目标' where name ='抖音';
UPDATE account_table SET balance=balance+'小目标' where name ='羊老师';
COMMIT;
Undo Log
可将数据库回退到修改之前的状态
Undo Log是逻辑日志，记录的是数据的增量变化。利用Undo Log可以进行事务回滚，从而保证事务的原子性。同时也实现了多版本并 发控制（MVCC），解决读写冲突和一致性读的问题。
Isolation
数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致
Isolation与MVCC
MVCC的意义：
读写互不阻塞
降低死锁概率
实现一致性读
Undo Log在MVCC的作用
每个事务有一个单增的事务ID
数据页的行记录中包含了DB_ROW_ID，DB_TRX_ID,DB_RoLL_PTR
DB_ROLL_RTR将数据行的所有快照记录都通过链表的结构串联了起来。
Durability与Redo Log
对数据的修改进行永久保存的方案
方案一：事务提交前页面写盘
方案二：WAL（Write-ahead logging）
redo log是物理日志，记录的是页面的变化，它的作用是保证事务持久化。如果数据写入磁盘前发生故障，重启MySQL后会根据redo log重做
四、企业实践
1、大流量-Sharding
问题背景
单节点写容易成为瓶颈
的那几数据容量上限
解决方案
业务数据进行水平拆分
代理层进行分片路由
实施效果
数据库写入性能线性拓展
数据库容量线性拓展
2、
问题背景
活动流量上涨
集群性能不满足要求
解决方案
扩容DB物理节点数量
利用影子表进行压测
实施效果
数据库集群提供更高的吞吐
保证集群可以承担预期流量
3、代理连接池
问题背景
突增流量导致大量建联
大量建联导致负载变大,延时上升
解决方案
业务侧预热连接池
代理侧预热连接池
代理侧支持连接队列
实施效果
避免DB被突增流量打死
避免代理和DB被大量建联打死
4、稳定性&可靠性-3AZ高可用
三机房部署
机房级别容灾
机房级别流量调度
proxy
读写分离，分库分表
限流，流量调度
监控报警
实时监控集群运行状态
提前上报集群风险
HA
High Availability
实时监控DB运行状态
宕机快速切换
5、稳定性&可靠性-HA管理
问题背景
db所在机器异常宕机
db节点异常宕机
解决方案
ha服务监管、切换宕机节点
代理支持配置热加载
代理自动屏蔽宕机读节点
实施效果
读节点宕机秒级恢复
写宕机30s内恢复服务
