系统设计

秒杀设计

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

系统设计

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

秒杀系统的设计方案

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

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

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

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

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

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

二、秒杀架构设计思路：

（一）、前端设计方案

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

（二）、后端设计方案

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

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

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

（三）、数据库层

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