1、秒杀系统部署
2、高并发项目整体架构部署（500万日活项目部署）
3、大体先梳理项目中的技术点（结合实验楼分析项目整体架构和技术点）
01.秒杀系统架构
1.1 超卖问题
1、1000件商品
2、第一步查询商品数量
3、查询商品：A 读 商品 1000 B 读 商品 1000
4、扣减库存：A : 1000-1 =999写入数据库，B：1000-1=999
5、卖了两件商品，商品数量：999
1.2 乐观锁和悲观锁如何解决超卖问题的
悲观锁解决的原理
1、A读商品数量是1000,如果要是悲观锁，A读完数量后商品就加锁（排它锁）了
2、B过来商品数量，A加的锁还没有释放，所以B要等待
3、只有当A卖完商品，商品数量减一，把商品数量为 999重新写入到数据库才释放锁
4、B获得商品时商品数据量是999而不是1000
乐观锁解决的原理
1、A读商品数量是1000,如果要是乐观锁这一刻乐观锁没有加锁
2、A进行商品扣减的时候会校验，现在的商品数量是否和开始数量一致
3、A扣减（排它锁）之后要不999写入到mysql中时会校验商品数量是否是1000
4、和A刚开始读的数据一致就写入，不一致重试
02 各层解决方案
2.1 分层结构图说明
2.2 网络层 CDN
1、特点：CDN服务器不需安装部署，不是一个真实的后端服务器，仅仅缓存了前端数据
2、作用：减轻源站的服务器压力，对于国外访问，可以更快速
3、CDN不是把我们的服务部署在全世界各地（成本太高）
4、CDN是静态资源的缓存（JS，Html、Css、图片、视频），不会变
5、网站提供是一个后端API接口
6、你从没过打开的商家的商品图片来美国的一台CDN服务器
7、但是请求的API接口，后端服务可能还是部署在中国
8、需要和数据库动态交互的，CDN没有任何作用
2.负载层（高可用）
nginx负责均衡：https://www.cnblogs.com/xiaonq/p/10468998.html
问题：只能解决高并发，不能解决高可用
keepalive和lvs、haproxy有了解（解决高可用问题）
keepalive：https://www.cnblogs.com/xiaonq/p/11694253.html
解决了单点故障
03.高并发架构各层能做的事情
1、应用层
浏览器本地缓存：缓存静态页面、缓存加入购物车的数据
2、网络层
CDN缓存静态资源：html/css/js/图片
3、负载层（高并发、高可用）
keepalive(haproxy)+nginx反向代理（腾讯云LB、阿里云的SLB）
4、服务层
动态页面静态化（比如Django的cache服务），减少查询数据库的次数
借助redis缓存解决大量的mysql查询压力
RabbitMQ+异步解决mysql的大量写入问题
5、限流：
抢购：nginx设置了保护功能，当流量过大自动丢弃（负载层就丢弃了）（nginx过载保护）
同一个设备、账号、出接口ip 一秒钟最多访问次数
6、数据库层
解决超卖问题：乐观锁、悲观锁解决数据安全
mysql一主多从，读写分离：写主库，读从库（所有数据库的数据一样）
数据一样的，那么当数据量太大的时候查询还是很慢
分库（根据用户id分库）
1、所有数据库的表结构一样，存储的数据完全不一样
2、真实环境以用户id进行分库，每一个库的数据都很小，查询起来就快了
3、无法解决问题：当一个数据库中表中量过大的时候，查询依然会慢
7、分表（根据时间分表）
当一个表中数据过大的时候，我们必须要对表拆分
购物清单表中有两千万数据
1、最近半年的购物数据时 一百万
2、半年到一年的数据有五百万
3、一年以前的数据有一千万