秒杀系统的设计,你值得拥有

常见的解决方案：

1.将秒杀系统独立部署，甚至使用独立域名，使其与网站完全隔离。物理业务隔离

2. 重新设计秒杀商品页面，不使用网站原来的商品详细页面，页面内容静态化， 用户请求不需要经过应用服务   3. 因为秒杀新增的网络带宽，必须和运营商重新购买或者租借。为了减轻网站服 务器的压力，需要将秒杀商品页面缓存在 CDN ，同样需要和 CDN 服务商临时租借新增的出 口带宽。  

秒杀架构原则

1.尽量将请求拦截在系统上游，传统秒杀系统之所以挂，请求都压到了后端数据层，数据 读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小

2.读多写少的场景多使用缓存这是一个典型的读多写少的应用场景

秒杀架构设计

1.秒杀系统为秒杀而设计，不同于一般的网购行为，参与秒杀活动的用户更关心的是如何 能快速刷新商品页面，在秒杀开始的时候抢先进入下单页面，而不是商品详情，因此秒杀系统的页面设计应尽可能简单 2.下单表单也尽可能简单，购买数量只能是一个且不可以修改，送货地址和付款方式都使用用户默认设置，没有默认也可以不填，允许等订单提交后修改；只有第一个提交的订单发送给网站的订单子系统，其       余 用户提交订单后只能看到秒杀结束页面

秒杀前端设计

1.静态资源存放到各 CDN 节点，把静态资源缓存到各 CDN 节点，用户可以就近访 问，加快访问速度 2.用户点击秒杀后，按钮置灰 3.js 限制 x 秒内只能提交一次  

秒杀站点设计

1.nginx 层做针对同一 ip 的访问频率限流

2.同一查询在站点层限制访问频率

秒杀服务层设计

服务层核心设计思想，尽量把大量的请求不要瞬时落到数据库层

1.读请求，cache 来扛，memcached，redis 单机扛 10W+应该没问题

2.写请求，用队列，由并行转串行，每次只放有限的写请求去数据库

高并发要吞吐量 or 系统保护

其实在正常非高并发的请求里面，也有类似的问题存在，业务请求接口异常响应极慢，久 而久之就会把整个服务器的可用连接数占满了，然而越是这种情况，越是系统不可用用户 点击越频繁，这台服务器有题，分流软件把流量导到其他服务器，导致其他服务器也崩 溃，将整个 web 系统拖垮，产生服务雪崩。   流量过大处理不过来的时候，就必须要有过载保护机制 例如秒杀场景，流量往往大到跟我们当初设计的不在一个量级，如果出现这种情况，可以 将流量拦截在站点层，比如在 nginx 层面就拦截掉，尽量不要把灾难引到服务层。  

系统安全的矛和盾

1.同一账号发送多次请求 这种加锁就可以解决， redis 锁，如果其中一个请求获取锁成功就允许秒杀，其他都拒绝   2.多个账号发送多次请求 黄牛党，僵尸号在秒杀开始的时候疯狂请求 可以做 ip 限制，如果某个 ip 请求频率过高，可以弹验证码或者实名验证，其实就是判断是否是活人。   3. 多个账号，不同 ip 这种必须要做业务限制，提高秒杀的参与门槛，比如只有星级用户、账号等级等等业务手段 来做限制。而僵尸账号往往账号等级和活跃度都不高