秒杀系统的设计思路（应对高并发，超卖等问题的解决思路）

首先我们先看一下设计秒杀系统时，我们应该考虑的问题。

解决方案：

一.页面静态化结合CDN内容分发

前端把能提前放入cdn服务器的东西都放进去，反正把所有能提升效率的步骤都做一下，减少真正秒杀时候服务器的压力。

秒杀活动的页面内容，大多数都是固定不变的。我们可以对秒杀页面做静态化处理，减少访问服务端的压力。在秒杀活动开始前，提前生成包含秒杀商品信息、倒计时等固定内容的静态 HTML 页面。这些页面可以根据秒杀活动的特点，例如开始时间、结束时间等来预先生成。

示例如下：

// 生成秒杀页面的HTML
public String generateSeckillPage(long goodsId) {GoodsVo goods = goodsService.getGoodsVoByGoodsId(goodsId);// 其他固定信息的获取// 生成HTML页面，包含秒杀商品信息、倒计时等String htmlContent = "<html><head>...</head><body>...</body></html>";// 将HTML页面保存到静态文件，或者存储到数据库中return htmlContent;
}

参与秒杀的用户可能分布在全国各地，地域不同，网速不同。为了让用户可以快速的进入到秒杀活动的页面，可以使用 CDN（Content Delivery Network,内容分发网络）让用户可以就近获取所需内容。将生成的静态 HTML 页面通过 CDN 分发，使用户可以就近获取所需内容。CDN 的作用是将页面的静态资源分发到全球不同的节点，用户访问时可以从离他们最近的节点获取内容，减少网络延迟，提高访问速度。

用户访问秒杀活动页面时，直接请求 CDN 上的静态 HTML 页面，不再需要服务端动态生成页面内容。这样可以减轻服务端的压力，提高页面加载速度，提升用户体验。

二.按钮置灰控制

秒杀活动开始前，按钮一般需要置灰。只有时间到了，才能变得可以点击。这防止，秒杀用户在时间快到的前几秒，疯狂请求服务器，然后秒杀时间点还没到，服务器就自己挂了。

三. 服务单一职责

我们都知道微服务设计思想，也就是各个功能模块拆分，功能那个类似放一起，再用分布式部署方式进行部署。

如用户登录相关，就设计个用户服务，订单相关就搞个订单服务等等。那么，秒杀相关业务逻辑也可以放到一起，搞个秒杀服务，单独给它搞个秒杀数据库。” 服务单一职责有个好处：如果秒杀没抗住高并发压力，秒杀库崩了，服务挂了，也不会影响到系统其他服。

四.秒杀地址加盐（url动态化）

链接如果明文暴露的话，会有人获取到请求 Url，提前秒杀了。因此，需要给秒杀链接加盐。可以让URL 动态化，如通过 MD5 加密算法加密随机字符串来生成，秒杀链接的URL。

时间校验： 通过获取商品的起始时间和结束时间，判断当前时间与秒杀活动的状态（未开始、进行中、已结束），从而判断用户是否可以参与秒杀。

 GoodsVo goods = goodsService.getGoodsVoByGoodsId(goodsId);long startAt = goods.getStartDate().getTime();long endAt = goods.getEndDate().getTime();long now = System.currentTimeMillis();int miaoshaStatus = 0;int remainSeconds = 0;if(now < startAt ) {//秒杀还没开始，倒计时miaoshaStatus = 0;remainSeconds = (int)((startAt - now )/1000);}else  if(now > endAt){//秒杀已经结束miaoshaStatus = 2;remainSeconds = -1;}else {//秒杀进行中miaoshaStatus = 1;remainSeconds = 0;}

但仅仅是这样的话还是不够的，如果我们的秒杀的真实地址被人知道了，就可以写一个脚本不断的获取北京时间，在秒杀开始的毫秒级别时就可以请求。而且机器能在短时间内发送大量的请求，绝对会对我们的秒杀活动造成巨大的影响。
那怎么办呢？
我们可以把我们的秒杀地址动态化，也就是通过MD5之类的加密算法去处理我们的秒杀地址，存入 redis缓存中，根据前端请求的url获取path。判断与缓存中的字符串是否一致，一致就认为请求是正常的。这就是秒杀链接加盐，用这样的方法来阻止恶意用户直接请求我们的秒杀地址。

@RequestMapping(value="/path", method=RequestMethod.GET)
@ResponseBody
public Result<String> getMiaoshaPath( MiaoshaUser user,@RequestParam("goodsId")long goodsId,@RequestParam(value="verifyCode", defaultValue="0")int verifyCode) {if(user == null) {return Result.error(CodeMsg.SESSION_ERROR);}boolean check = miaoshaService.checkVerifyCode(user, goodsId, verifyCode);if(!check) {return Result.error(CodeMsg.REQUEST_ILLEGAL);}String path  =miaoshaService.createMiaoshaPath(user, goodsId);return Result.success(path);}public String createMiaoshaPath(MiaoshaUser user, long goodsId) {if(user == null || goodsId <=0) {return null;}String str = MD5Util.md5(UUIDUtil.uuid()+"123456");redisService.set(MiaoshaKey.getMiaoshaPath, ""+user.getId() + "_"+ goodsId, str);return str;}

实现原理总结如下：

用户通过前端请求获取秒杀地址的path。
后端根据用户信息、商品ID等生成动态的秒杀地址。
将生成的地址通过加盐的加密算法处理，存入Redis缓存中，建立用户ID和商品ID的关联。
用户提交秒杀请求时，携带path参数，后端根据前端请求的URL获取path，再与Redis缓存中的地址进行比对，判断请求的合法性。

通过这种方法，成功防止了用户通过直接请求秒杀地址进行恶意操作，保障了秒杀活动的公正性和安全性。

五.接口限流进行防刷

一般有两种方式限流：nginx 限流和redis 限流。

为了防止某个用户请求过于频繁，我们可以对同一用户限流；

为了防止黄牛模拟几个用户请求，我们可以对某个 IP 进行限流；

为了防止有人使用代理，每次请求都更换 IP 请求，我们可以对接口进行限流。

1. Nginx 提供了基于令牌桶算法的限流机制，可以有效控制请求的流量。通过配置 ngx_http_limit_req_module 模块，可以设定每个 IP 或每个 URI 的请求频率上限。

http {limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;server {location /api {limit_req zone=one burst=5;# 其他配置}}
}

上述配置中，limit_req_zone 定义了一个名为 one 的限流区域，每个 IP 的请求速率为 1 次/秒，limit_req 用于限制每秒的请求数，burst 指定了可以超出速率的请求数

2.0为了防止瞬时过大流量压垮系统，还可以使用阿里Sentinel、Hystrix 组件进行限流。

六. 超卖问题解决思路

只要是一个秒杀系统，就必然会存在超卖问题。不同用户在读请求的时候，发现商品库存足够，然后同时发起请求，进行秒杀操作，减库存，导致库存减为负数。

1.0使用乐观锁解决

如果要使用乐观锁，那么我们就要给个商品库存一个版本号version字段，在每次我们读取库存的时候把版本号也读取出来，当这一个线程去执行扣减库存的操作的时候，去判断数据库当前的版本号是否是刚刚读取出来的版本号，如果不是则秒杀失败。

/*** 查询商品库存* @param id 商品id* @return*/@Select("SELECT * FROM goods WHERE id = #{id}")Goods getStock(@Param("id") int id);/*** 乐观锁方案扣减库存* @param id 商品id* @param version 版本号* @return*/@Update("UPDATE goods SET stock = stock - 1, version = version + 1 WHERE id = #{id} AND stock > 0 AND version = #{version}")int decreaseStockForVersion(@Param("id") int id, @Param("version") int version);

service层：

/*** 扣减库存* @param gid 商品id* @param uid 用户id* @return SUCCESS 1 FAILURE 0*/@Transactionalpublic int sellGoods(int gid, int uid) {// 获取库存Goods goods = goodsDao.getStock(gid);if (goods.getStock() > 0) {// 乐观锁更新库存int update = goodsDao.decreaseStockForVersion(gid, goods.getVersion());// 更新失败，说明其他线程已经修改过数据，本次扣减库存失败，可以重试一定次数或者返回if (update == 0) {return 0;}// 库存扣减成功，生成订单Order order = new Order();order.setUid(uid);order.setGid(gid);int result = orderDao.insertOrder(order);return result;}// 失败返回return 0;}

2.0使用redis分布式锁

用 Redis SET EX PX NX + 校验唯一随机值,再删除释放锁。

if (jedis.set(key_resource id, uni request id,"NX","Ex"，100s) == 1)[ //加锁try {do something //业务处理catch(){}finally {//判断是不是当前线程加的锁,是才释放if (uni_request id.equals(jedis.get(key_resource_ id))) {jedis.del(lockKey);}}
}