这是我参与「第五届青训营 」伴学笔记创作活动的第18天
1.经典案例
1.1RDBMS（关系型数据库管理系统）事务ACID
事务(Transaction):是由一组SQL语句组成的一个程序执行单元(Unit)，它需要满足ACID特性.
ACID
- 原子性(Atomicity):事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生（不存在中间状态）
- 一致性(Consistency):数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性(操作必须是合法的)
- 隔离性(Isolation):多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果(应该表现的像串行效果)
- 持久性(Durability):在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚
2.发展历史
2.1前RDBMS时代-人工管理
在现代计算机发明出来以前，通过人工的方式进行数据记录和管理（效率低下）
2.2前RDBMS时代-文件系统
1950年，现代计算机的雏形基本出现。1956年IBM发布了第一个的磁盘动器——Model 305 RAMAC，从此数据存储进入磁盘时代。在这阶段，数据管理直接通过文件系统来实现。
2.3RDBMS时代
- 1960年，传统的文件系统已经不能满足人们的需要，数据库管理系统(DBMS)应运而生
- DBMS:按照某种数据模型来组织、存储和管理数据的仓库。
- 所以通常按照数据模型的特点将传统数据库系统分成网状数据库、层次数据库和关系数据库三类
2.3.1DBMS数据模型-网状模型
网状数据库所基于的网状数据模型建立的数据之间的联系，能反映现实世界中信息的关联，是许多空间对象的自然表达形式。1964年，世界上第一个数据库系统-集成数据存储(Integrated Data Storage ,IDS)诞生于通用电气公司。IDS是世界上第一个网状数据库，奠定了数据库发展的基础，在当时得到了广泛的应用。在1970年网状数据库系统十分流行，在数据库系统产品中占据主导地位
2.3.2DBMS数据模型-层次模型
1968年，世界上第一个层次数据库-信息管理系统(lnformation Management System,IMS) 诞生于IBM公司，这也是世界上第一个大型商用的数据库系统。层次数据模型，即使用树形结构来描述实体及其之间关系的数据模型。
2.3.3DBMS数据模型-关系模型
1970年，IBM的研究员E.FCodd博士发表了一篇名为"A Relational Model of Data for Large Shared Data Banks"的论文，提出了关系模型的概念，奠定了关系模型的理论基础。1979年Oracle首次将关系型数据库商业化，后续DB2,SAP Ssbase ASE,and informix等知名数据库产品也纷纷面世。（关系型数据就说所有的数据都是一张二维表）
2.3.4DBMS数据模型
| 网状模型 | 层次模型 | 关系模型 | |
| 优势 | 能直接描述现实世界、存取效率高 | 结构简单、查询效率高、可以提供较好的完整性支持 | 实体及实体之间的联系都通过二维表结构表示、可以方便的表示M:N的关系、数据访问路径对用户透明 |
| 劣势 | 结构复杂、用户不易使用、访问程序设计复杂 | 无法表示M:N的关系、插入删除限制多、遍历子节点必须经过父节点、访问程序设计复杂 | 关联查询效率不够高、关系必须规范化 |
2.3.5SQL语言
1974年IBM的Ray Boyce和Don Chamberlin将Codd关系数据库的12条准则的数学定义以简单的关键字语法表现出来，里程碑式地提出了SQL(Structured Query Language)语言。
- 语法风格接近自然语言
- 高度非过程化
- 面向集合的操作方式
- 语言简洁，易学易用
3.关键技术
3.1SQL引擎-Parser
解析器(Parser)一般分为词法分析 (Lexical analysis)、语法分析(Syntax analysis)、语义分析(Semantic analyzer) 等步骤。
3.2SQL引擎-Optimizer
3.2.1基于规则的优化(RBO Rule Base Optimizer)
- 条件化简
- 表连接优化：总是小表先进行连接
- scan优化：唯一索引、普通索引、全表扫描
数据库索引:是数据库管理系统中辅助数据结构，以协助快速查询、更新数据库表中数据。目前数据库中最常用的索引是通过B+树实现的。
3.2.2基于代价的优化(CBO Cost Base Optimizer)
3.2SQL引擎-Executor
3.3存储引擎-InnoDB
In-Memory：
- Buffer Pool
- Change Buffer
- Adaptive Hash Index
- Log Buffer
On-Disk:
- System Tablespace(ibdata1)
- General Tablespaces(xxxibd)
- Undo Tablespaces(xxxibu)
- Temporary Tablespaces(xxx.ibt)
- Redo Log(ib_logfileN)
3.4事务引擎
Atomicity与Undo Log
数据库回退到修改之前的状态（使用Undo Log） Undo Log是逻辑日志，记录的是数据的增量变化。利用Undo Log可以进行事务回滚，从而保证事务的原子性。同时也实现了多版本并发控制(MVCC)解决读写冲突和一致性读的问题
Isolation与锁
并发读使用share lock（共享锁） 并发写exclusive lock（排他锁） 并发读写
Isolation与MVCC
MVCC的意义
- 读写互不阻塞
- 降低死锁概率
- 实现一致性读
Durability与Redo Log
如何保证事务结束后，对数据的修改永久的保存?
方案一:事务提交前页面写盘（问题：随机IO、写放大）
方案二:WAL(Write-ahead logging)redo log是物理日志，记录的是页面的变化，它的作用是保证事务持久化。如果数据写入磁盘前发生故障，重启MySQL后会根据redo log重做。
4.企业实战
4.1春节红包雨挑战
- 大流量
- 流量突增
- 稳定性
4.2大流量-sharding
问题背景
- 单节点写容易成为瓶颈
- 单机数据容量上限
解决方案
- 业务数据进行水平拆分
- 代理层进行分片路由
实施效果
- 数据库写入性能线性扩展
- 数据库容量线性扩展
4.3突增流量
4.3.1-扩容
问题背景
- 活动流量上涨
- 集群性能不满足要求
解决方案
- 扩容DB物理节点数量
- 利用影子表进行压测
实施效果
- 数据库集群提供更高的吞吐
- 保证集群可以承担预期流量
4.3.2-代理连接池
问题背景
- 突增流量导致大量建联
- 大量建联导致负载变大，延时上升
解决方案
- 业务侧预热连接池
- 代理侧预热连接池
- 代理侧支持连接队列
实施效果
- 避免DB被突增流量打死
- 避免代理和DB被大量建联打死
4.4稳定性&可靠性
4.4.1-3AZ高可用
三机房部署
- 机房级别容灾
- 机房级别流量调度
proxy
- 读写分离，分库分表
- 限流，流量调度
监控报警
- 实时监控集群运行状态
- 提前上报集群风险
4.4.2-HA管理
问题背景
- db所在机器异常宕机
- db节点异常宕机
解决方案
- ha服务监管、切换宕机节点
- 代理支持配置热加载
- 代理自动屏蔽宕机读节点
