系统设计

参考：

秒杀设计

• 一、什么是流量削峰？如何解决秒杀业务的削峰场景
  
• 二、双11秒杀系统如何设计？
  
• 三、电商网站秒杀与抢购的系统架构
  
• 四、高并发场景下秒杀系统的设计思路
  
• 五、电商“秒杀系统”设计思路和实现方法
  
• 六、秒杀系统架构分析与实战
  

系统设计

1. 高并发解决方案
   
2. java服务器雪崩的场景与解决方案
   

秒杀系统的设计方案

1、常见的互联网分层架构

（1）客户端层：手机或PC端操做的客户端页面，域名经过DNS解析路由到Nginx

（2）反向代理层：通常经过Nginx做为反向代理，将客户端请求均衡路由到后端站点服务，Nginx 也能够水平扩展为多实例，且每一个实例可单独部署为主从的高可用方案。

（3）站点层：站点层可水平扩展为多个实例部署，以此来均衡来自客户端请求产生的高并发负载，多个web server之间的session信息可集中存储于分布式缓存服务（Redis，MemCache）中。

（4）服务层：服务层也可水平扩展为多个实例部署，即时下最火的微服务方式

（5）数据库层：数据库层的常见部署方式，如读写分离，分库分表等

2、秒杀架构设计思路：

（一）、前端设计方案

• 页面静态化：将活动页面上的全部能够静态的元素所有静态化，并尽可能减小动态元素。经过CDN来抗峰值。
• 禁止重复提交：用户提交以后按钮置灰，禁止重复提交
• 用户限流：在某一时间段内只容许用户提交一次请求，好比能够采起IP限流

（二）、后端设计方案

• 服务端控制器层(网关层)
• 限制uid（UserID）访问频率：咱们上面拦截了浏览器访问的请求，但针对某些恶意攻击或其它插件，在服务端控制层须要针对同一个访问uid，限制访问频率。
• 服务层

上面只拦截了一部分访问请求，当秒杀的用户量很大时，即便每一个用户只有一个请求，到服务层的请求数量仍是很大。好比咱们有100W用户同时抢100台手机，服务层并发请求压力至少为100W。

1. 采用消息队列缓存请求：既然服务层知道库存只有100台手机，那彻底没有必要把100W个请求都传递到数据库啊，那么能够先把这些请求都写到消息队列缓存一下，数据库层订阅消息减库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束。
2. 利用缓存应对读请求：好比双11秒杀抢购，是典型的读多写少业务，大部分请求是查询请求，因此能够利用缓存分担数据库压力。
3. 利用缓存应对写请求：缓存也是能够应对写请求的，好比咱们就能够把数据库中的库存数据转移到Redis缓存中，全部减库存操做都在Redis中进行，而后再经过后台进程把Redis中的用户秒杀请求同步到数据库中。

（三）、数据库层

数据库层是最脆弱的一层，通常在应用设计时在上游就须要把请求拦截掉，数据库层只承担“能力范围内”的访问请求。因此，上面经过在服务层引入队列和缓存，让最底层的数据库高枕无忧。