这是我参与「第五届青训营 」笔记创作活动的第16天

前言

RDBMS（关系型数据库）是目前使用最为广泛的数据库之一，同时也是整个信息化时代的基石。本节课程通过生活中常见的场景向大家介绍RDBMS的作用、发展历程及其核心技术，最后以字节为例，展示了RDBMS的企业级实践。

经典案例

抖音红包雨

RDBMS-事务ACID

• 事务（Transaction）：是由一组SQL语句组成的一个程序执行单元（Unit），它需要满足ACID特性。
  • 子性(Atomicity)：事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生。
  • 一致性(Consistency)：数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。
  • 隔离性(Isolation)：多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。
  • 持久性(Durability)：在事务完成以后，该事务所对数据库所做的更改便持久的保存在数据库之中，并不会被回滚。

发展历史

前DBMS时代

• 人工管理（效率太低）

  • 结绳记事
  • 清代钱庄账本
  • 用于18901年人口普查的霍列瑞斯式的打孔机

• 文件系统（写到纸上变成写到文件里，变了个马甲）

  • 1950s，现代计算机雏形基本出现。1956年IBM发布了第一个的磁盘驱动器--Model 305 RAMAC,从此数据存储进入磁盘时代。在这个阶段，数据管理直接通过文件系统来实现。

DBMS时代

• 数据库发展最初过程中，诞生过3种数据模型，最终关系型模型成为了应用最为广泛的数据库模型。

  • 网状模型：用有向图表示实体和实体之间的联系的数据结构模型称为网状数据模型。
  • 层次模型：层次数据模型是用树状<层次>结构来组织数据的数据模型。
  • 关系模型：使用表格表示实体和实体之间关系的数据模型称之为关系数据模型。

	网状模型	层次模型	关系模型
优势	能直接描述现实世界 存取效率较高	结构简单 查询效率高 可以提供较好的完整性支持	实体及实体间的的联系都通过二维表结构表示 可以方便的表示M:N关系 数据访问路径对用户透明
劣势	结构复杂 用户不易使用 访问程序设计复杂	无法表示M:N的关系 插入、删除限制多 遍历子节点必须经过父节点 访问程序设计复杂	关联查询效率不够高 关系必须规范化

SQL语言

• 1974年IBM的Ray和Don Chamberlin将Codd关系数据库的12条准则以简单的关键字语法表现出来，里程碑式地提出了SQL（Structured Query Language）语言。
  • 语法风格接近自然语言
  • 高度非过程化
  • 面向集合的操作方式
  • 语言简洁，易学易用

关键技术

SQL 执行流程

• 在SQL执行过程中，需要经历SQL引擎、存储引擎、以及事务引擎等模块。而其中SQL引擎又分为Parser、Optimizer、Executor几个部分：

SQL 引擎

• SQL引擎包括了：

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

存储引擎

• 存储引擎负责了数据的底层存储、管理和访问工作。各大RDBMS存储引擎的设计都有不少的差异，这里选择MySQL的InnoDB存储引擎来向大家做一个介绍：

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

事务引擎

• 事务引擎实现了数据库的ACID能力，这里还是以MySQL的InnoDB为例来介绍数据库内部是通过哪些技术来实现ACID：

  • Atomicity：InnoDB中通过undo日志实现了数据库的原子性，通过Undo Log，数据库可以回滚到事务开始的状态；
  • Isolation：通过Undo Log实现MVCC（多版本并发控制），降低读写冲突。
  • Durability：通过Redo Log（一种WAL实现方式）来保证事务在提交后一定能持久化到磁盘中。
  • Consistency：一致性本质上是一种业务层的限制。

企业实践

抖音春节红包雨挑战

• 流量大
• 流量突增
• 稳定性

大流量

• Sharding
  • 问题背景
    • 单节点写容易成为瓶颈
    • 单机数据容量上限
  • 解决方案
    • 业务数据进行水平拆分
    • 代理层进行分片路由
  • 实施效果
    • 数据库写入性能线性扩展
    • 数据库容量线性扩展

流量突增

两种方案

• 扩容

  • 问题背景
    • 活动流量上涨
    • 集群性能不满足要求
  • 解决方案
    • 扩容DB物理节点数量
    • 利用影子表进行压测
  • 实施效果
    • 数据库集群提供更高的吞吐
    • 保证集群可以承担预期流量

• 代理连接池

  • 问题背景
    • 突增流量导致大量建联
    • 大量建联导致负载变大，延时上升
  • 解决方案
    • 业务侧预热连接池
    • 代理测预热连接池
    • 代理测支持连接队列
  • 实施效果
    • 避免DB被突增流量打死
    • 避免代理和DB被大量建联打死

稳定性&可靠性

• 3AZ高可用

  • 三机房部署
    • 机房级别容灾
    • 机房级别流量调度
  • proxy
    • 读写分离，分库分表
    • 限流，流量调度
  • 监控报警
    • 实时监控集群运行状态
    • 提前上报集群风险
  • HA
    • High Availability
    • 实时监控DB运行状态
    • 宕机快速切换

• HA管理

  • 问题背景
    • db所在机器异常宕机
    • db节点异常宕机
  • 解决方案
    • ha服务监管，切换宕机节点
    • 代理支持配置热加载
    • 代理自动屏蔽宕机读节点
  • 实施效果
    • 读节点宕机秒级恢复
    • 写节点宕机30s内恢复服务

引用

• 字节内部课：MySQL - 深入理解RDBMS