这是我参与「第五届青训营」伴学笔记创作活动的第 18 天
课程1-RDBMS 基本情况介绍
RDBMS：关系型数据库
事务：由一组SQL语句组成的一个程序执行单元（Unit），满足ACID特性
ACID：
a.原子性(A)
b.一致性(C)
c.隔离性(I)
d.持久性(D)
网状数据库->层次模型->关系模型
课程2-RDBMS 关键技术分析
SQL引擎
Parser：词法分析、语法分析、语义分析
Opimizer：RBO【基于规则的优化】、CBO【基于代价的优化】
Executor：
- 火山模型；优点：每个算子独立抽象实现，相互之间没有耦合，逻辑结构简单；缺点：没计算一条数据有多次函数调用开销导致CPU效率不高。
- 向量化：优点：函数调用次数降低为1/N；CPU cacche命中率更高；可以利用CPU提供的SIMD
- 编译执行：将所有逻辑代码写到一个代码中，使用LLVM动态编译执行技术。
存储引擎-InnoDB
BufferPool
B+树做索引【可以从叶子结点进行范围查询】
事务引擎
Automatic与Undo Log：逻辑日志，记录的是数据的增量变化。利用Undo Log可以进行事务回滚
isolation与锁：有隔离级别；MVCC含义：读写互不阻塞，降低死锁概率，实现一致性读
Durability与Redo Log：保障事务结束后，对数据的修改的永久保存；
方案1:事务提交前页面写盘，存在随机IO，写放大的问题
方案2：WAL【Write-ahead-logging】；redo log是物理日志，记录页面的变化，保证事务持久化；如果数据写入磁盘前发生故障，重启MYSQL之后会根据redo log重做
课程3-RDBMS 企业实践案例
- 解决大流量：sharding
问题背景：单机点写容易成为瓶颈；单机数据容量上限
解决方案：业务数据进行水平拆分【数据按hash进行分布式存储】；单代理层分片路由【对用户来说看起来是单点服务】
实施效果：数据库写入性能的线性扩展；数据库容量线性扩展
- 流量突增：扩容
问题背景：活动流量上涨；集群性能不满足要求
解决方案：扩容DB物理结点数量；利用影子表进行压测
实施效果：数据库集群提供更高的吞吐；保证集群可以承担预期流量
- 流量突增：代理连接池
问题背景：突增流量导致大量建立连接；大量建立连接导致负载变大；延时上升
解决方案：业务侧预热连接池；代理测预热连接池；代理池支持连接队列
实施效果：避免DB被突增的流量打死；避免代理和DB被大量建连打死
- 稳定性；可靠性：3AZ高可用
三机房部署：在不同城市建立独立的机房；机房级容灾；机房级别流量调度
Proxy：通过代理分布请求；读写分离；分库分表；限流，流量调度
监控报警：实时监控集群运行状态；提前上报集群风险
- 稳定性；可靠性：HA【高可用】管理
问题背景：db所在机器异常；db结点异常宕机
解决方案：ha服务监管，切换宕机结点；代理支持热配置加载；代理自动屏蔽宕机读结点
