一、经典案例
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读写分离，分库分表限流，流量调度
监控报警，实时监控集群运行状态，提前上报集群风险
