关系型数据库RDBMS | 字节青训营笔记

一、经典案例

1、红包雨案例

每年春节，抖音都会有红包雨获得

2、事务

事务(Transaction): 是由一组SQL语句组成的一个程序执行单元(Unit)，它需要满足ACID特性

BEGIN;
UPDATE account table SET balance = balance - '小目标 WHERE name =“抖音';
UPDATE account_table SET balance = balance +'小目标' WHERE name =杨洋';
COMMIT;

ACID

• 原子性(Atomicity): 事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生
• 一致性(Consistengy): 数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性
• 隔离性(solation): 多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果
•  持久性(Durability): 在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚

3、红包雨与ACID

原子性：当抖音已经已经扣除一个亿，但是羊老师还没有加上，服务器挂了，那么就抖音亏一个亿，羊老师也没加上，所以必须保证同时成功或同时失败。

一致性：假设抖音只剩0.5亿，但又扣除一个亿，那么就为负了。这样是不合法的，所以必须要保证每个操作都是合法的，从一个有效的状态变到另一个有效状态。

隔离性：如果羊老师从抖音和头条同时强了1个亿，那么他们同时给老师转1个亿，结果老师却只加了1个亿，因为两个操作互相影响了。两个操作在同个账户并发进行，应该是互不影响的，表现是串行操作。

持久性：如果你已经成功拿到抖音一个亿了，抖音也扣了一个亿。但是服务器挂机了，没持久化数据，那么最后还是没有拿到。所以必须保证在操作成功之后，更新的结果被永久保留下来，不会因为宕机而丢失。

高并发：全国14亿人抢红包，如果1秒只执行1个请求，那么要31年才能完成。所以必须得支持高并发，每秒执行1000w请求，只需要1分多钟

高可靠：假设除夕晚上大家正在愉快的从抖音身上“羊毛”，这时候服务器挂了，程序员花了一个小时，头发都掉光了，终于修好了。"抖音宕机"秒上热搜，所以，必须保证高可靠。

二、企业实践

1、红包雨挑战

这种获得一般流量大，流量是短暂时间突增的，这段时间很大，过段时间就冷了，而且要保证系统的稳定性。

2、大流量问题-Sharding 

问题背景：

• 单节点写容易成为瓶颈
• 单机数据容量上限

解决方案：

• 业务数据进行水平拆分，比如一个业务拆分成几个数据库来存储
• 代理层进行分片路由，多一个代理层来转发请求，所有请求都发到代理层，让代理层来转发到各个服务器，起到一个中转站的作用，用户是不用管存到哪台服务器的，只需要发请求给代理层。

实施效果

• 数据库写入性能线性扩展
• 数据库容量线性扩展

3、浏览突增-扩容

问题背景

• 获得流量上涨，活动持续一段时间，不可能一年365都扩容
• 集群性能不满足要求

解决方案

• 扩容DB物理节点数量
• 利用影子表进行压测、

实施效果

• 数据库集群提供更高的吞吐
• 保证集群可以承担预期流量

4、流量突增-代理连接池

问题背景

• 流量突增导致大量建立连接
• 大量建立连接导致负载变大，延时上升

解决方案

• 业务侧预热连接池
• 代理侧预热连接池，代理层会提前缓存100个连接，当用户来的时候就不用重新简历连接，用已经建立好的连接。
• 代理侧支持连接队列

实施效果

• 避免DB被突增流量打死
• 避免代理和DB被大量建连打死

5、稳定性&可靠性-3AZ高可靠

当员工删库跑路，或者硬件事故。我们怎么保证数据稳定和可靠？

字节跳动采用3AZ高可靠的解决方案

在3个不同城市分别部署数据库，三机房部署，机房级别容灾，机房级别流量调度。

proxy读写分离，分库分表限流，流量调度

监控报警，实时监控集群运行状态，提前上报集群风险