这是我参与【第五届青训营】伴学笔记创作活动的第14天
经典案例
RDBMS 事务 ACID
事务（Transaction）：是由一组SQL语句组成的一个程序执行单元（Unit），它需要满足ACID特性。
- 原子性Atomicity：事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生
- 一致性Consisitency：数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性
- 隔离型Isolation：可以隔离多个并发事务，避免影响
- 持久性Durability：事务一旦提交成功，数据保持持久性，不会被回滚
红包雨与ACID
case1：抖音的账户上扣了一个亿之后，假设服务器挂了，还没来得及给用户账户加上一个亿
两个事务要么同时成功。要么同时失败，不存在中间状态
case2：假设抖音的账户上只有0.5个亿，但是减扣一个亿的操作成功了
每个操作都必须是合法的，账户信息应该从一个有效的状态变成另一个有效的状态
case3：用户从抖音抢了一个亿红包，又从头条抢了一个亿，两个转账同时进行，假设他们都以为是从零开始更新用户的账户余额，用户最后得到了一个亿
两个操作在对同一个账户并发进行操作时，应该是相互不影响，表现得像是串行操作
case4：抖音得账户上扣了一个亿，然后用户账户上加了一个亿，但还没有写到磁盘上，这个时候服务器挂了
操作更新成功之后，更新得结果应该永久性的保留下来，不会因为宕机等问题而丢失
高并发
全国14亿人，假设有10亿人同时开抢红包，每秒处理一个请求，那需要31年才能完成
高可靠
除夕晚上大家都在抖音上抢红包，这个时候服务挂掉了，程序员花费了一个多小时，终于修好了服务，“抖音宕机”上热搜
关键技术
一条SQL的一生
- SQL 引擎
- 存储引擎
- 事务引擎
SQL引擎
Parser
解析器（Parser）一般分为词法分析（Lexical analysis）、语法分析（Syntax analysis）、语义分析（Semantic analyzer）等步骤。
Optimizer
为什么需要优化器（Optimizer）？
基于规则的优化（RBO Rule Base Optimizer）
- 条件化简
- 表连接优化
SELECT * FROM A,B,C WHERE A.a1 = B.b1 and A.a1 = C.b1;
-
Scan优化
- 唯一索引
- 普通索引
- 全表扫描
数据库索引：是数据库管理系统中辅助数据结构，以协助快速查询、更新数据库表中数据。目前数据库中最常用的索引是通过B+树实现的
基于代价的优化（CBO Cost Base Optimizer）
一个查询有多种执行方案，CBO会选择其中代价最低的方案去真正的执行
企业实践
红包雨挑战
共计发放红包20亿元——活动钱包: 400w/s
总计发放卡券24亿张——发红包: 300w/s
拜年红包补贴12.9亿——发奖券: 400w/s
- 流量大
- 流量突增
- 稳定性
大流量 — Sharding
问题背景
- 单节点写容易成为瓶颈
- 单机数据容量上限
解决方案
- 业务数据进行水平拆分
- 代理层进行分片路由
实施效果
- 数据库写入性能线性扩展
- 数据库容量线性扩展
流量突增 — 扩容
问题背景
- 活动流量上涨
- 集群性能不满足要求
解决方案
- 扩容DB物理节点数量
- 利用影子表进行压测
实施效果
- 数据库集群提供更高的吞吐
- 保证集群可以承担预期流量
流量突增 — 代理连接池
问题背景
- 突增流量导致大量建联
- 大量建联导致负载变大，延时上升
解决方案
- 业务侧预热连接池
- 代理侧预热连接池
- 代理侧支持连接队列
实施效果
- 避免DB被突增流量打死
- 避免代理和DB被大量建联打死
稳定性&可靠性
3AZ高可用
HA管理
