对于秒杀架构的设计，需要遵循以下个原则：
东西不能超卖、
下单成功的订单数据不能丢失、
服务器和数据库不能挂
尽量不让机器人抢走
整体的思路
秒杀架构的设计方案就是一个不断过滤请求的过程，从系统架构层面来说，秒杀系统的分层思路如下。
在这里插入图片描述秒杀系统的架构设计目标就是尽可能把上层的用户请求处理掉。
下面我们通过业务的流程来设计秒杀的架构
一、浏览页面
对于PC网站，首先必选前后端分离，然后静态资源放到CDN上。例如我们平时访问的请求是
https://static.xxx.jpg。我们可以将这个staticxxx这个域名解析交给CDN服务商，因CDN服务商在全国各地都有服务器，服务器中存放着我们想要的静态资源的缓存。CDN收到这个域名后，首先会寻找一台响应最快的服务器，并指向这个服务器的IP。使用CDN好处是不浪费自己的服务器资源和带宽，且响应速度快。这样就可以把静态资源的压力拦截在系统分层的外面。
二、下单页面
1、进入下单页面
为了防止别人通过爬虫抓取页面信息，给服务器增加压力，防止恶意请求重复提交，可以做已下两层防护。
第一，页面URL后台动态获取：按照正常的活动设计流程，用户只有在秒杀活动开启后才可进入下单页，但难免有人在开启前就直接获取下单页的URL并不断刷新，这样就给后台服务器增加了压力，这个时候，我们要把下单页面URL做处理（不把它放到静态页面里，而是通过后台动态获取）。用JS判断秒杀开始时间，秒杀时间一到，就可以通过另一个请求获取URL。
第二，用户点击下单页的购买按钮后，按钮就置位disable，防止用户不断点击购买按钮。
2、订单提交
对于订单提交，我们做以下两方面设计：
第一，网关层面过滤请求，可以有以下三种方式，
（1）限定每个用户访问频率，比如每5秒下单1次。
（2）限定每个IP访问频率。
（3）把一个时间段内的请求拦截掉一个百分比，或者只允许特定数量的请求进入后台服务器（可以使用限流的漏桶或者令牌桶算法）
第二，后台服务器过滤请求，到了后台的请求，就不能是过滤请求了，而是保证秒杀商品不被超卖，以及特价商品订单数据准确。
具体实现，可以通过以下三种方式,
（1）商品库存放入缓存Redis中，如果每个请求都查询数据库库存，那数据库必然扛不住，所以我们要把库存放到缓存中，这样每次用户下单前，如果Redis的库存扣减后<0，说明秒杀失败，如果Redis库存扣减后>=0，说明秒杀成功，开始创建订单。
（2）对于生成的订单，可以写入缓存中，对于订单数据我们可以先放到缓存中，然后每隔一段时间批量插入数据库。在用户下单后，会进入一个等待页面，然后这个页面向后台定时轮询订单数据。轮询订单数据的过程中，后台先在 Redis 中查询订单数据，查不到说明已经落库，再去数据库查询订单数据，查到后直接返回给用户，用户收到消息通知后可以直接进入付款页面支付了。在数据库查询订单数据时，查不到说明秒杀失败。
（3）订单批量落库，定期将订单批量落库，且在订单落库的时扣减数据库中的库存。
三、付款页面
在付款页面，基本不需要再过滤用户请求了。在这个环节，除了保障数据的一致性，还需要注意一个要点：如果业务逻辑上出现一个订单未及时付款而被取消，记得把数据库及 Redis 的库存加回去。
为了保证秒杀系统的高可用，需要对静态资源服务器、网关、后台服务器都进行配置负载均衡，而缓存 Redis 和数据库均需要配置集群模式。
对于网关的限流 和如何应对某台服务器宕机，避免其他服务雪崩 （熔断）
