电商秒杀流程和业务分析总结
1.秒杀，流程，高并发压测，定向优化，流量自适应
秒杀特点：
1.瞬间流量高峰，非线性流量
2.即时性要求高，
3.对抗恶意刷单，类ddoc攻击
4.内部防御
2.症状:数据库卡死，服务器down，超卖
3.思路：
1.高频请求尽量复用，避免动态响应，详情页；
2.必须动态响应的靠redis
3.控制库存较给原子性的redis
4.rabbitmq过滤无效请求
5.限制请求，（单人多次/总请求限流）
4.要流程演示，设计：
1.全页面静态，CDN，反省代理
2.动态数据来自redis
3.网关限流
4.二维码验证--》动态path-->写入redis(防暗箭），防刷
5.验证码独立服务处理TODO
6.校验通过后，获取唯一订单连接
5.redis特点：
redis命令具有原子性操作：任意时刻只有一个线程在操作，不会有线程安全问题；不会有并发，incr,decr一个命令，单线程，同一时克只有一个线程在工作，
redis它自己做了一个事务封装了给你调用而已
redis 缓存库存商品，数量，价格
redis缓存用户二维码，path，用户是否有秒杀信息，已秒杀，不能在秒杀
6.秒杀流程：
验证码通过--》消耗redis库存--》任务放第rabbitmq--》等待后台处理--成功生成订单--发布订单好到延时取消服务（5分钟每付款取消订单）--数据库一致性，前端才能轮询数据库--》 抢成功。
没有付款成功 延时取消
首次加载多数据库库存数量到redis,秒杀完了redis库存后，有加了数据库库存，则继续读数据库添加的库存到redis，继续执行秒杀；
把一个一对一的交易拆成了两个，用户到nosql是一个，然后nosql到数据库是一个
总结：
1.一切高并发的流量，都跟数据库绝缘；
2.支持水平扩展，根据瓶颈来优化；
3.数据的一致性还是数据库保证。
架构逻辑清楚
业务逻辑清楚
jement 压测
redis6.5 几十万每秒
redis 集群分片，id-hash
lua 脚本
redis 每秒100m吞吐量，是按数据量来的，不是按条的；
rabbitmq 每秒100m吞吐量，是按数据量来的，不是按条的；