怎么解决高并发的后台秒杀问题

秒杀一般是电商或者网上一些活动的场景，这种秒杀一般存在着后台拥挤，服务器承受不了大量的客户端导致奔溃是经常的事情，我们今天来介绍一下解决高并发的后台秒杀问题。

操作方法

（01）我们遇到的秒杀一般是在电商网站举行一些活动或者节假日在12306网站上抢票时遇到，这些都给我们带来了很多的苦恼，而对于电商网站中一些稀缺或者特价商品，电商网站一般会在约定时间点对其进行限量销售，因为这些商品的特殊性，会吸引大量用户前来抢购，并且会在约定的时间点同时在秒杀页面进行抢购。因为狼多肉少的原因，导致服务器拥挤，大量的客户无功而返。

（02）解决这个一般有五步，第一步限流： 鉴于只有少部分用户能够秒杀成功，所以要限制大部分流量，只允许少部分流量进入服务后端。

（03）第二步削峰：对于秒杀系统瞬时会有大量用户涌入，以外卖为例，大量的外卖会在中午产生，商家推出满减活动更是火热。所以在抢购一开始会有很高的瞬间峰值。高峰值流量是压垮系统很重要的原因，所以如何把瞬间的高流量变成一段时间平稳的流量也是设计秒杀系统很重要的思路。实现削峰的常用的方法有利用缓存和消息中间件等技术。

（04）第三步异步处理：秒杀系统是一个高并发系统，采用异步处理模式可以极大地提高系统并发量，其实异步处理就是削峰的一种实现方式。

（05）第四步内存缓存：秒杀系统最大的瓶颈一般都是数据库读写，由于数据库读写属于磁盘IO，性能很低，如果能够把部分数据或业务逻辑转移到内存缓存，效率会有极大地提升。充分利用缓存，利用缓存可极大提高系统读写速度。

（06）最后一步可拓展：当然如果我们想支持更多用户，更大的并发，最好就将系统设计成弹性可拓展的，如果流量来了，拓展机器就好了。像淘宝、京东等双十一活动时会增加大量机器应对交易高峰。消息队列可以削峰，将拦截大量并发请求，这也是一个异步处理过程，后台业务根据自己的处理能力，从消息队列中主动的拉取请求消息进行业务处理。

（07）可以采用Redis 最简单的key-value数据结构，用一个原子类型的变量值(AtomicInteger)作为key，把用户id作为value，库存数量便是原子变量的最大值。对于每个用户的秒杀，我们使用 RPUSH key value插入秒杀请求， 当插入的秒杀请求数达到上限时，停止所有后续插入。然后我们可以在台启动多个工作线程，使用 LPOP key 读取秒杀成功者的用户id，然后再操作数据库做最终的下订单减库存操作。