针对秒杀场景，以下几个需要解决的问题点：
- 瞬时流量的承接
- 防止超卖
- 预防黑产
- 避免对正常服务的影响
- 兜底方案
瞬时流量的承接
1.限流（nginx-----sentinel限流 ------网关层限流）
2.缓存加速（先将库存等信息预热到redis）（前端的静态文件可以提前缓存到CDN）
3.同步变异步（下单等操作可以抽成异步）
一般情况下，秒杀的流量特性就是持续性短和大。流量集中在活动即将开始的时候，会有很多用户开始持续性地刷新页面。前端资源的访问也需要损耗大量的资源，因此需要利用 CDN 缓存秒杀页面的一些静态资源，将这部分压力给到 CDN 厂商。并且静态资源放在 CDN 厂商那之后，地理位置也距离用户更近，用户访问也就更快，体验上也更好！
CDN 是 "内容分发网络（Content Delivery Network）" 的缩写，简单说就是把网站的静态资源（比如图片、视频、网页文件）存到分布在各地的服务器上，用户访问时会自动连接离自己最近的服务器，既能加快加载速度，也能减轻原网站的流量压力。
1.CDN缓存一下前端的静态资源
2.nginx限流-----sentinel限流
防止超卖
使用redis+Lua脚本 原子性操作实现 redis 库存不会超卖
后续写入mysql的时候可以利用MySQL的乐观锁实现mysql不会超卖
异步写入
假如有10种优惠卷-就在redis提前建立10个对应优惠卷的领取记录-可以用一个hash结构 Key为秒杀的优惠卷编号--key为用户id--value 为优惠卷id或者活动id
并且开启10个线程每个线程就只负责一个优惠卷数据的定时同步 一对一 同步进行
流量隔离
将秒杀服务独立部署，使用独立的数据库和缓存，避免秒杀流量影响其他业务。
示例：使用不同的数据库连接池
兜底策略
熔断机制
当依赖的服务出现故障时，快速返回兜底数据，避免请求积压。
针对秒杀，其实最简单的方案就是加个开关：关闭秒杀，直接返回秒杀结束。这个兜底是为了避免极端情况发生，严重影响正常业务的进行或产生资损。因为秒杀对用户而言本身是一个可以接受失败的场景，没抢到很正常。只要用户来参加我们的活动，营销目的也达到了，所以在严重影响正常业务进行或者发现代码出现漏洞，被人薅羊毛的情况下，关闭秒杀是最好的选择！