高并发-秒杀流程

秒杀系统解决高并发？

浏览器端(js)：

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

项目后端方案

1、web层

如果请求过多，判定web服务器的压力过大，增加前端的web服务器，做负载均衡

 

2、服务层

如果请求的静态页面不卡了，但是请求的动态数据还是卡，说明mysql处理的请求太多了，即当秒杀的用户量很大时，即使每个用户只有一个请求，到服务层的请求数量还是很大。比如我们有100W用户同时抢100台手机，服务层并发请求压力很大。这时可采用以下两种办法：

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

 

3、数据库层

数据库层是最脆弱的一层，一般在应用设计时在上游就需要把请求拦截掉，数据库层只承担“能力范围内”的访问请求，所以，上面通过在服务层引入队列或缓存，让最底层的数据库高枕无忧。若是还是不行，则数据库也可以做主从，读写分离增加其能力范围内的查询。

 

案例：利用消息中间件和缓存实现简单的秒杀系统

Redis是一个分布式缓存系统，支持多种数据结构，我们可以利用Redis轻松实现一个强大的秒杀系统。

我们可以采用Redis 最简单的key-value数据结构，用一个原子类型的变量值(AtomicInteger)作为key，把用户id作为value，库存数量便是原子变量的最大值。对于每个用户的秒杀，我们使用 RPUSH key value插入秒杀请求， 当插入的秒杀请求数达到上限时，停止所有后续插入。

然后我们可以在台启动多个工作线程，使用 LPOP key 读取秒杀成功者的用户id，然后再操作数据库做最终的下订单减库存操作。