整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
文是“Java秒杀系统实战系列文章”的第四篇，从这篇文章开始我们将进入该秒杀系统相关业务模块的代码实战！本文将首先从最简单的业务模块入手，即如何实现“获取待秒杀商品的列表以及查看待秒杀的商品详情”功能！
对于“待秒杀商品列表及其详情的展示”这一功能，我们将采用目前比较流行的mvc开发模式来实现！值得一提的是，这一功能模块涉及的主要数据库表为“商品信息表item”、“待秒杀商品信息item_kill”。
1、首先是在 ItemController控制器中开发“获取待秒杀商品列表”的请求方法，其源代码如下所示：
//获取商品列表
@RequestMapping(value={"/","/index",prefix+"/list",prefix+"/index.html"},method=RequestMethod.GET)
public String list(ModelMap modelMap){
try {
//获取待秒杀商品列表
List<ItemKill> list=itemService.getKillItems();
modelMap.put("list",list);
log.info("获取待秒杀商品列表-数据：{}",list);
}catch(Exception e){
log.error("获取待秒杀商品列表-发生异常：",e.fillInStackTrace());
return "redirect:/base/error";
}
return"list";
}
控制器的这一方法在获取到待秒杀商品的列表信息后，将通过modelMap的形式将数据列表返回给到前端的页面list.jsp中进行渲染！其中，itemService.getKillItems() 主要用于获取待秒杀商品的列表信息，其源代码如下所示：
@Autowired
private ItemKillMapper itemKillMapper;
//获取待秒杀商品列表
@Override
public List<ItemKill> getKillItems() throwsException {
return itemKillMapper.selectAll();
}
2、紧接着是开发 itemKillMapper.selectAll() 方法，其主要是基于Mybatis在配置文件中写动态Sql，该Sql的作用在于“获取待秒杀商品的列表”，其源代码如下所示：
<!--查询待秒杀的活动商品列表--> <select id="selectAll"resultType="com.debug.kill.model.entity.ItemKill"> SELECT a.*, b.name AS itemName, ( CASE WHEN (now() BETWEEN a.start_time AND a.end_time AND a.total > 0) THEN 1 ELSE 0 END ) AS canKill FROM item_kill AS a LEFT JOIN item AS b ON b.id=a.item_id WHERE a.is_active=1 </select>
在这里的Sql，Debug是采用了Left Join左关联查询的方式获取列表信息，目的是为了获取“商品信息表”中的商品信息，如“商品名称”等等。
值得一提的是，在这里Debug还使用了一个小技巧，即采用一个字段 canKill 来表示当前“待秒杀的商品”是否可以被秒杀/被抢购！其判断的标准为：
当待秒杀的商品的剩余数量/库存，即 total 字段的取值大于0时，并且 “当前的服务器时间now()处于待秒杀商品的抢购开始时间 和 抢购结束时间的范围内”时，canKill的取值将为1，即代表可以被抢购或者被秒杀。否则canKill的取值将为0。
3、至此，“待秒杀商品列表”这一功能模块的后端代码开发已经完成了！前端发起请求后，请求将首先到达controller，通过请求路径url映射到某个方法进行调用，controller的方法首先会进行最基本的数据校验，然后通过调用service提供的接口获取真正的业务数据，最后是在service中执行真正的dao层层面的数据查询或者数据操作逻辑，最终完成整个业务流的操作。
4、接下来是开发一个页面list.jsp用于展示“待秒杀商品列表的信息”，下面展示了该页面的部分核心源码，如下图所示：
从该代码中可以看出，当canKill字段取值为1时，将可以点击“详情”进行查看；否则，将会提示相应的信息！即“判断是否可以秒杀”的逻辑Debug是将其放在了后端来实现！
5、至此，“获取待秒杀商品列表”这一功能模块的前后端代码实战已经完毕了，点击运行整个项目，将整个系统运行在外置的tomcat服务器中，观察控制台的输出信息，如果没有报错，这说明整个系统的代码在语法级别层面是木有问题的。如下图所示为整个秒杀系统、项目在运行起来之后的首页：
虽然不是很美观，但是Debug觉得还是凑合着用吧 哈哈！！
1、接下来是点击“详情”，查看“待秒杀商品的详情信息”，对于这个功能模块，其实还是比较简单的，其核心主要是根据“主键”进行查询。
同样的道理，首先需要在ItemController控制器中开发接收前端请求的功能方法，其源代码如下所示：
/**
* 获取待秒杀商品的详情
* @return
*/
@RequestMapping(value=prefix+"/detail/{id}",method=RequestMethod.GET)
public String detail(@PathVariable Integer id,ModelMap modelMap){
if(id==null || id<=0){
return "redirect:/base/error";
}
try {
ItemKill detail=itemService.getKillDetail(id);
modelMap.put("detail",detail);
}catch(Exception e){
log.error("获取待秒杀商品的详情-发生异常：id={}",id,e.fillInStackTrace());
return "redirect:/base/error";
}
return"info";
}
该控制器的方法在获取到待秒杀商品的详情后，将通过modelMap把详情信息塞回info.jsp前端页面中进行渲染展示！
2、紧接着是itemService.getKillDetail(id) 的开发，即用于获取“待秒杀商品的详情”，其源代码如下所示：
/**
* 获取待秒杀商品详情
*/
@Override
public ItemKill getKillDetail(Integer id) throws Exception{
ItemKill entity=itemKillMapper.selectById(id);
if(entity==null){
throw new Exception("获取秒杀详情-待秒杀商品记录不存在");
}
return entity;
}
其中，itemKillMapper.selectById(id);主要是基于Mybatis在配置文件中写动态Sql，该Sql的主要功能为根据主键查询待秒杀商品的详情，其源代码如下所示：
<!--获取秒杀详情-->
<select id="selectById" resultType="com.debug.kill.model.entity.ItemKill">
SELECT
a.*,
b.name AS itemName,
(
CASE WHEN (now() BETWEEN a.start_time AND a.end_time AND a.total > 0)
THEN 1
ELSE 0
END
) AS canKill
FROM item_kill AS a LEFT JOIN item AS b ON b.id=a.item_id
WHERE a.is_active=1 AND a.id=#{id}
</select>
从该Sql中不难看出，其实就是在“获取待秒杀商品列表”的Sql中加入“主键的精准查询”！
3、最后是在页面info.jsp渲染展示该详情信息，如下图所示为该页面的部分核心源代码：
从该页面的部分核心源代码中可以看出，为了避免有人“跳过页面的请求，直接恶意刷后端接口”，在该页面仍然再次进行了一次判断（在后面执行“抢购/秒杀”请求时，后端接口还会再次进行判断的，所有这些都是为了安全考虑！）
4、至此，关于“待秒杀商品的详情展示”的功能的前后端代码实战已经完成了！再次将整个系统/项目运行在外置的tomcat服务器中，点击列表页中的“详情”按钮，可以看到待秒杀商品的详情信息，如下图所示：
至此，本文所要分享介绍的内容已经完成了，即主要分享介绍了“获取待秒杀商品的列表”和“查看待秒杀商品的详情”功能！
Debug有话说
1、目前，这一秒杀系统的整体构建与代码实战已经全部完成了，完整的源代码数据库地址可以来这里下载：
https://gitee.com/steadyjack/SpringBoot-SecondKill
记得Fork跟Star啊！！！
2、由于相应的博客的更新可能并不会很快，故而如果有想要快速入门以及实战整套系统的，可以考虑联系Debug获取这一“Java秒杀系统”的完整视频教程（课程是收费的！），当然，大家也可以点击下面这个链接 ：
https://gitee.com/steadyjack/SpringBoot-SecondKill
联系Debug或者加入相应的技术交流群进行交流！
3、实战期间有任何问题都可以留言或者与Debug联系、交流。
推荐阅读
Java商城秒杀系统的设计与实战教程（SpringBoot版）
Java秒杀系统实战系列-构建SpringBoot多模块项目
Java秒杀系统实战系列-整体业务流程介绍与数据库设计
Java秒杀系统实战系列-待秒杀商品列表与详情功能开发
者：因为热爱所以坚持ing来源： 苏三说技术
高并发下如何设计秒杀系统?这是一个高频面试题。这个问题看似简单，但是里面的水很深，它考查的是高并发场景下，从前端到后端多方面的知识。
秒杀一般出现在商城的促销活动中，指定了一定数量(比如：10个)的商品(比如：手机)，以极低的价格(比如：0.1元)，让大量用户参与活动，但只有极少数用户能够购买成功。这类活动商家绝大部分是不赚钱的，说白了是找个噱头宣传自己。
虽说秒杀只是一个促销活动，但对技术要求不低。下面给大家总结一下设计秒杀系统需要注意的9个细节。
一般在秒杀时间点(比如：12点)前几分钟，用户并发量才真正突增，达到秒杀时间点时，并发量会达到顶峰。
但由于这类活动是大量用户抢少量商品的场景，必定会出现狼多肉少的情况，所以其实绝大部分用户秒杀会失败，只有极少部分用户能够成功。
正常情况下，大部分用户会收到商品已经抢完的提醒，收到该提醒后，他们大概率不会在那个活动页面停留了，如此一来，用户并发量又会急剧下降。所以这个峰值持续的时间其实是非常短的，这样就会出现瞬时高并发的情况，下面用一张图直观地感受一下流量的变化：
像这种瞬时高并发的场景，传统的系统很难应对，我们需要设计一套全新的系统。可以从以下几个方面入手：
活动页面是用户流量的第一入口，所以是并发量最大的地方。
如果这些流量都能直接访问服务端，恐怕服务端会因为承受不住这么大的压力，而直接挂掉。
活动页面绝大多数内容是固定的，比如：商品名称、商品描述、图片等。为了减少不必要的服务端请求，通常情况下，会对活动页面做静态化处理。用户浏览商品等常规操作，并不会请求到服务端。只有到了秒杀时间点，并且用户主动点了秒杀按钮才允许访问服务端。
这样能过滤大部分无效请求。
但只做页面静态化还不够，因为用户分布在全国各地，有些人在北京，有些人在成都，有些人在深圳，地域相差很远，网速各不相同。
如何才能让用户最快访问到活动页面呢?
这就需要使用CDN，它的全称是Content Delivery Network，即内容分发网络。
使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。
大部分用户怕错过秒杀时间点，一般会提前进入活动页面。此时看到的秒杀按钮是指纹，不可点击的。只有到了秒杀时间点那一时刻，秒杀按钮才会自动点亮，变成可点击的。
但此时很多用户已经迫不及待了，通过不停刷新页面，争取在第一时间看到秒杀按钮的点亮。
从前面得知，该活动页面是静态的。那么我们在静态页面中如何控制秒杀按钮，只在秒杀时间点时才点亮呢?
没错，使用js文件控制。
为了性能考虑，一般会将css、js和图片等静态资源文件提前缓存到CDN上，让用户能够就近访问秒杀页面。
看到这里，有些聪明的小伙伴，可能会问：CDN上的js文件是如何更新的?
秒杀开始之前，js标志为false，还有另外一个随机参数。
当秒杀开始的时候系统会生成一个新的js文件，此时标志为true，并且随机参数生成一个新值，然后同步给CDN。由于有了这个随机参数，CDN不会缓存数据，每次都能从CDN中获取最新的js代码。
此外，前端还可以加一个定时器，控制比如：10秒之内，只允许发起一次请求。如果用户点击了一次秒杀按钮，则在10秒之内置灰，不允许再次点击，等到过了时间限制，又允许重新点击该按钮。
在秒杀的过程中，系统一般会先查一下库存是否足够，如果足够才允许下单，写数据库。如果不够，则直接返回该商品已经抢完。
由于大量用户抢少量商品，只有极少部分用户能够抢成功，所以绝大部分用户在秒杀时，库存其实是不足的，系统会直接返回该商品已经抢完。
这是非常典型的：读多写少 的场景。
如果有数十万的请求过来，同时通过数据库查缓存是否足够，此时数据库可能会挂掉。因为数据库的连接资源非常有限，比如：mysql，无法同时支持这么多的连接。
而应该改用缓存，比如：redis。
即便用了redis，也需要部署多个节点。
通常情况下，我们需要在redis中保存商品信息，里面包含：商品id、商品名称、规格属性、库存等信息，同时数据库中也要有相关信息，毕竟缓存并不完全可靠。
用户在点击秒杀按钮，请求秒杀接口的过程中，需要传入的商品id参数，然后服务端需要校验该商品是否合法。
大致流程如下图所示：
根据商品id，先从缓存中查询商品，如果商品存在，则参与秒杀。如果不存在，则需要从数据库中查询商品，如果存在，则将商品信息放入缓存，然后参与秒杀。如果商品不存在，则直接提示失败。
这个过程表面上看起来是OK的，但是如果深入分析一下会发现一些问题。
比如商品A第一次秒杀时，缓存中是没有数据的，但数据库中有。虽说上面有如果从数据库中查到数据，则放入缓存的逻辑。
然而，在高并发下，同一时刻会有大量的请求，都在秒杀同一件商品，这些请求同时去查缓存中没有数据，然后又同时访问数据库。结果悲剧了，数据库可能扛不住压力，直接挂掉。
如何解决这个问题呢?
这就需要加锁，最好使用分布式锁。
当然，针对这种情况，最好在项目启动之前，先把缓存进行预热。即使先把所有的商品，同步到缓存中，这样商品基本都能直接从缓存中获取到，就不会出现缓存击穿的问题了。
是不是上面加锁这一步可以不需要了?
表面上看起来，确实可以不需要。但如果缓存中设置的过期时间不对，缓存提前过期了，或者缓存被不小心删除了，如果不加速同样可能出现缓存击穿。
其实这里加锁，相当于买了一份保险。
如果有大量的请求传入的商品id，在缓存中和数据库中都不存在，这些请求不就每次都会穿透过缓存，而直接访问数据库了。
由于前面已经加了锁，所以即使这里的并发量很大，也不会导致数据库直接挂掉。
但很显然这些请求的处理性能并不好，有没有更好的解决方案?
这时可以想到布隆过滤器。
系统根据商品id，先从布隆过滤器中查询该id是否存在，如果存在则允许从缓存中查询数据，如果不存在，则直接返回失败。
虽说该方案可以解决缓存穿透问题，但是又会引出另外一个问题：布隆过滤器中的数据如何更缓存中的数据保持一致?
这就要求，如果缓存中数据有更新，则要及时同步到布隆过滤器中。如果数据同步失败了，还需要增加重试机制，而且跨数据源，能保证数据的实时一致性吗?
显然是不行的。
所以布隆过滤器绝大部分使用在缓存数据更新很少的场景中。
如果缓存数据更新非常频繁，又该如何处理呢?
这时，就需要把不存在的商品id也缓存起来。
下次，再有该商品id的请求过来，则也能从缓存中查到数据，只不过该数据比较特殊，表示商品不存在。需要特别注意的是，这种特殊缓存设置的超时时间应该尽量短一点。
对于库存问题看似简单，实则里面还是有些东西。
真正的秒杀商品的场景，不是说扣完库存，就完事了，如果用户在一段时间内，还没完成支付，扣减的库存是要加回去的。
所以，在这里引出了一个预扣库存的概念，预扣库存的主要流程如下：
扣减库存中除了上面说到的预扣库存和回退库存之外，还需要特别注意的是库存不足和库存超卖问题。
使用数据库扣减库存，是最简单的实现方案了，假设扣减库存的sql如下：
update product set stock=stock-1 where id=123; 这种写法对于扣减库存是没有问题的，但如何控制库存不足的情况下，不让用户操作呢?
这就需要在update之前，先查一下库存是否足够了。
伪代码如下：
int stock=mapper.getStockById(123);
if(stock > 0) {
int count=mapper.updateStock(123);
if(count > 0) {
addOrder(123);
}
} 大家有没有发现这段代码的问题?
没错，查询操作和更新操作不是原子性的，会导致在并发的场景下，出现库存超卖的情况。
有人可能会说，这样好办，加把锁，不就搞定了，比如使用synchronized关键字。
确实，可以，但是性能不够好。
还有更优雅的处理方案，即基于数据库的乐观锁，这样会少一次数据库查询，而且能够天然地保证数据操作的原子性。
只需将上面的sql稍微调整一下：
update product set stock=stock-1 where id=product and stock > 0; 在sql最后加上：stock > 0，就能保证不会出现超卖的情况。
但需要频繁访问数据库，我们都知道数据库连接是非常昂贵的资源。在高并发的场景下，可能会造成系统雪崩。而且，容易出现多个请求，同时竞争行锁的情况，造成相互等待，从而出现死锁的问题。
redis的incr方法是原子性的，可以用该方法扣减库存。伪代码如下：
boolean exist=redisClient.query(productId,userId);
if(exist) {
return -1;
}
int stock=redisClient.queryStock(productId);
if(stock <=0) { return 0; }
redisClient.incrby(productId, -1);
redisClient.add(productId,userId);
return 1; 代码流程如下：
估计很多小伙伴，一开始都会按这样的思路写代码。但如果仔细想想会发现，这段代码有问题。
有什么问题呢?
如果在高并发下，有多个请求同时查询库存，当时都大于0。由于查询库存和更新库存非原则操作，则会出现库存为负数的情况，即库存超卖。
当然有人可能会说，加个synchronized不就解决问题?
调整后代码如下：
boolean exist=redisClient.query(productId,userId);
if(exist) { return -1; }
synchronized(this) {
int stock=redisClient.queryStock(productId);
if(stock <=0) {
return 0;
}
redisClient.incrby(productId, -1);
redisClient.add(productId,userId);
}
return 1; 加synchronized确实能解决库存为负数问题，但是这样会导致接口性能急剧下降，每次查询都需要竞争同一把锁，显然不太合理。
为了解决上面的问题，代码优化如下：
boolean exist=redisClient.query(productId,userId);
if(exist) { return -1; }
if(redisClient.incrby(productId, -1)<0) {
return 0;
}
redisClient.add(productId,userId);
return 1; 该代码主要流程如下：
该方案咋一看，好像没问题。
但如果在高并发场景中，有多个请求同时扣减库存，大多数请求的incrby操作之后，结果都会小于0。
虽说，库存出现负数，不会出现超卖的问题。但由于这里是预减库存，如果负数值负得太多的话，后面万一要回退库存时，就会导致库存不准。
那么，有没有更好的方案呢?
我们都知道lua脚本，是能够保证原子性的，它跟redis一起配合使用，能够完美解决上面的问题。
lua脚本有段非常经典的代码：
StringBuilder lua=new StringBuilder();
lua.append("if (redis.call('exists', KEYS[1])==1) then");
lua.append(" local stock=tonumber(redis.call('get', KEYS[1]));");
lua.append(" if (stock==-1) then"); lua.append(" return 1;");
lua.append(" end;"); lua.append(" if (stock > 0) then");
lua.append(" redis.call('incrby', KEYS[1], -1);");
lua.append(" return stock;");
lua.append(" end;");
lua.append(" return 0;");
lua.append("end;");
lua.append("return -1;"); 该代码的主要流程如下：
之前我提到过，在秒杀的时候，需要先从缓存中查商品是否存在，如果不存在，则会从数据库中查商品。如果数据库中，则将该商品放入缓存中，然后返回。如果数据库中没有，则直接返回失败。
大家试想一下，如果在高并发下，有大量的请求都去查一个缓存中不存在的商品，这些请求都会直接打到数据库。数据库由于承受不住压力，而直接挂掉。
那么如何解决这个问题呢?
这就需要用redis分布式锁了。
使用redis的分布式锁，首先想到的是setNx命令。
if (jedis.setnx(lockKey, val)==1) {
jedis.expire(lockKey, timeout);
} 用该命令其实可以加锁，但和后面的设置超时时间是分开的，并非原子操作。
假如加锁成功了，但是设置超时时间失败了，该lockKey就变成永不失效的了。在高并发场景中，该问题会导致非常严重的后果。
那么，有没有保证原子性的加锁命令呢?
用redis的set命令，它可以指定多个参数。
String result=jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
return false; 其中：
由于该命令只有一步，所以它是原子操作。
接下来，有些朋友可能会问：在加锁时，既然已经有了lockKey锁标识，为什么要需要记录requestId呢?
答：requestId是在释放锁的时候用的。
if (jedis.get(lockKey).equals(requestId)) {
jedis.del(lockKey);
return true;
}
return false; 在释放锁的时候，只能释放自己加的锁，不允许释放别人加的锁。
这里为什么要用requestId，用userId不行吗?
答：如果用userId的话，假设本次请求流程走完了，准备删除锁。此时，巧合锁到了过期时间失效了。而另外一个请求，巧合使用的相同userId加锁，会成功。而本次请求删除锁的时候，删除的其实是别人的锁了。
当然使用lua脚本也能避免该问题：
if redis.call('get', KEYS[1])==ARGV[1] then
return redis.call('del', KEYS[1])
else return 0
end 它能保证查询锁是否存在和删除锁是原子操作。
上面的加锁方法看起来好像没有问题，但如果你仔细想想，如果有1万的请求同时去竞争那把锁，可能只有一个请求是成功的，其余的9999个请求都会失败。
在秒杀场景下，会有什么问题?
答：每1万个请求，有1个成功。再1万个请求，有1个成功。如此下去，直到库存不足。这就变成均匀分布的秒杀了，跟我们想象中的不一样。
如何解决这个问题呢?
答：使用自旋锁。
try { Long start=System.currentTimeMillis();
while(true) {
String result=jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
long time=System.currentTimeMillis() - start;
if (time>=timeout) {
return false;
}
try {
Thread.sleep(50);
}
catch (InterruptedException e) {
e.printStackTrace();
}
}
}
finally{
unlock(lockKey,requestId);
}
return false; 在规定的时间，比如500毫秒内，自旋不断尝试加锁，如果成功则直接返回。如果失败，则休眠50毫秒，再发起新一轮的尝试。如果到了超时时间，还未加锁成功，则直接返回失败。
除了上面的问题之外，使用redis分布式锁，还有锁竞争问题、续期问题、锁重入问题、多个redis实例加锁问题等。
这些问题使用redisson可以解决，由于篇幅的原因，在这里先保留一点悬念，有疑问的私聊给我。后面会出一个专题介绍分布式锁，敬请期待。
我们都知道在真实的秒杀场景中，有三个核心流程：
而这三个核心流程中，真正并发量大的是秒杀功能，下单和支付功能实际并发量很小。所以，我们在设计秒杀系统时，有必要把下单和支付功能从秒杀的主流程中拆分出来，特别是下单功能要做成mq异步处理的。而支付功能，比如支付宝支付，是业务场景本身保证的异步。
于是，秒杀后下单的流程变成如下：
如果使用mq，需要关注以下几个问题：
秒杀成功了，往mq发送下单消息的时候，有可能会失败。原因有很多，比如：网络问题、broker挂了、mq服务端磁盘问题等。这些情况，都可能会造成消息丢失。
那么，如何防止消息丢失呢?
答：加一张消息发送表。
在生产者发送mq消息之前，先把该条消息写入消息发送表，初始状态是待处理，然后再发送mq消息。消费者消费消息时，处理完业务逻辑之后，再回调生产者的一个接口，修改消息状态为已处理。
如果生产者把消息写入消息发送表之后，再发送mq消息到mq服务端的过程中失败了，造成了消息丢失。
这时候，要如何处理呢?
答：使用job，增加重试机制。
用job每隔一段时间去查询消息发送表中状态为待处理的数据，然后重新发送mq消息。
本来消费者消费消息时，在ack应答的时候，如果网络超时，本身就可能会消费重复的消息。但由于消息发送者增加了重试机制，会导致消费者重复消息的概率增大。
那么，如何解决重复消息问题呢?
答：加一张消息处理表。
消费者读到消息之后，先判断一下消息处理表，是否存在该消息，如果存在，表示是重复消费，则直接返回。如果不存在，则进行下单操作，接着将该消息写入消息处理表中，再返回。
有个比较关键的点是：下单和写消息处理表，要放在同一个事务中，保证原子操作。
这套方案表面上看起来没有问题，但如果出现了消息消费失败的情况。比如：由于某些原因，消息消费者下单一直失败，一直不能回调状态变更接口，这样job会不停地重试发消息。最后，会产生大量的垃圾消息。
那么，如何解决这个问题呢?
每次在job重试时，需要先判断一下消息发送表中该消息的发送次数是否达到最大限制，如果达到了，则直接返回。如果没有达到，则将次数加1，然后发送消息。
这样如果出现异常，只会产生少量的垃圾消息，不会影响到正常的业务。
通常情况下，如果用户秒杀成功了，下单之后，在15分钟之内还未完成支付的话，该订单会被自动取消，回退库存。
那么，在15分钟内未完成支付，订单被自动取消的功能，要如何实现呢?
我们首先想到的可能是job，因为它比较简单。
但job有个问题，需要每隔一段时间处理一次，实时性不太好。
还有更好的方案?
答：使用延迟队列。
我们都知道rocketmq，自带了延迟队列的功能。
下单时消息生产者会先生成订单，此时状态为待支付，然后会向延迟队列中发一条消息。达到了延迟时间，消息消费者读取消息之后，会查询该订单的状态是否为待支付。如果是待支付状态，则会更新订单状态为取消状态。如果不是待支付状态，说明该订单已经支付过了，则直接返回。
还有个关键点，用户完成支付之后，会修改订单状态为已支付。
通过秒杀活动，如果我们运气爆棚，可能会用非常低的价格买到不错的商品(这种概率堪比买福利彩票中大奖)。
但有些高手，并不会像我们一样老老实实，通过秒杀页面点击秒杀按钮，抢购商品。他们可能在自己的服务器上，模拟正常用户登录系统，跳过秒杀页面，直接调用秒杀接口。
如果是我们手动操作，一般情况下，一秒钟只能点击一次秒杀按钮。
但是如果是服务器，一秒钟可以请求成上千接口。
这种差距实在太明显了，如果不做任何限制，绝大部分商品可能是被机器抢到，而非正常的用户，有点不太公平。
所以，我们有必要识别这些非法请求，做一些限制。那么，我们该如何现在这些非法请求呢?
目前有两种常用的限流方式：
基于nginx限流
基于redis限流
为了防止某个用户，请求接口次数过于频繁，可以只针对该用户做限制。
限制同一个用户id，比如每分钟只能请求5次接口。
有时候只对某个用户限流是不够的，有些高手可以模拟多个用户请求，这种nginx就没法识别了。
这时需要加同一ip限流功能。
限制同一个ip，比如每分钟只能请求5次接口。
但这种限流方式可能会有误杀的情况，比如同一个公司或网吧的出口ip是相同的，如果里面有多个正常用户同时发起请求，有些用户可能会被限制住。
别以为限制了用户和ip就万事大吉，有些高手甚至可以使用代理，每次都请求都换一个ip。
这时可以限制请求的接口总次数。
在高并发场景下，这种限制对于系统的稳定性是非常有必要的。但可能由于有些非法请求次数太多，达到了该接口的请求上限，而影响其他的正常用户访问该接口。看起来有点得不偿失。
相对于上面三种方式，加验证码的方式可能更精准一些，同样能限制用户的访问频次，但好处是不会存在误杀的情况。
通常情况下，用户在请求之前，需要先输入验证码。用户发起请求之后，服务端会去校验该验证码是否正确。只有正确才允许进行下一步操作，否则直接返回，并且提示验证码错误。
此外，验证码一般是一次性的，同一个验证码只允许使用一次，不允许重复使用。
普通验证码，由于生成的数字或者图案比较简单，可能会被破解。优点是生成速度比较快，缺点是有安全隐患。
还有一个验证码叫做：移动滑块，它生成速度比较慢，但比较安全，是目前各大互联网公司的首选。
上面说的加验证码虽然可以限制非法用户请求，但是有些影响用户体验。用户点击秒杀按钮前，还要先输入验证码，流程显得有点繁琐，秒杀功能的流程不是应该越简单越好吗?
其实，有时候达到某个目的，不一定非要通过技术手段，通过业务手段也一样。
12306刚开始的时候，全国人民都在同一时刻抢火车票，由于并发量太大，系统经常挂。后来，重构优化之后，将购买周期放长了，可以提前20天购买火车票，并且可以在9点、10、11点、12点等整点购买火车票。调整业务之后(当然技术也有很多调整)，将之前集中的请求，分散开了，一下子降低了用户并发量。
回到这里，我们通过提高业务门槛，比如只有会员才能参与秒杀活动，普通注册用户没有权限。或者，只有等级到达3级以上的普通用户，才有资格参加该活动。
这样简单的提高一点门槛，即使是黄牛党也束手无策，他们总不可能为了参加一次秒杀活动，还另外花钱充值会员吧?
时光飞逝，两周过去了，是时候继续填坑了，不然又要被网友喷了。
本文是秒杀系统的第三篇，通过实际代码讲解，帮助你了解秒杀系统设计的关键点，上手实际项目。
本篇主要讲解秒杀系统中，关于抢购（下单）接口相关的单用户防刷措施，主要说两块内容：
当然，这两个措施放在任何系统中都有用，严格来说并不是秒杀系统独特的设计，所以今天的内容也会比较的通用。
此外，我做了一张流程图，描述了目前我们实现的秒杀接口下单流程：
欢迎关注我的个人公众号获取最全的原创文章：后端技术漫谈（二维码见文章底部）
妈妈再也不用担心只会看文章不会实现啦：
https://github.com/qqxx6661/miaosha
可以翻阅该系列的第一篇文章，这里不再回顾：
零基础上手秒杀系统（一）：防止超卖
在前两篇文章的介绍下，我们完成了防止超卖商品和抢购接口的限流，已经能够防止大流量把我们的服务器直接搞炸，这篇文章中，我们要开始关心一些细节问题。
对于稍微懂点电脑的，又会动歪脑筋的人来说，点击F12打开浏览器的控制台，就能在点击抢购按钮后，获取我们抢购接口的链接。（手机APP等其他客户端可以抓包来拿到）
一旦坏蛋拿到了抢购的链接，只要稍微写点爬虫代码，模拟一个抢购请求，就可以不通过点击下单按钮，直接在代码中请求我们的接口，完成下单。所以就有了成千上万的薅羊毛军团，写一些脚本抢购各种秒杀商品。
他们只需要在抢购时刻的000毫秒，开始不间断发起大量请求，觉得比大家在APP上点抢购按钮要快，毕竟人的速度又极限，更别说APP说不定还要经过几层前端验证才会真正发出请求。
所以我们需要将抢购接口进行隐藏，抢购接口隐藏（接口加盐）的具体做法：
大家先停下来仔细想想，通过这样的办法，能够防住通过脚本刷接口的人吗？
能，也不能。
可以防住的是直接请求接口的人，但是只要坏蛋们把脚本写复杂一点，先去请求一个验证值，再立刻请求抢购，也是能够抢购成功的。
不过坏蛋们请求验证值接口，也需要在抢购时间开始后，才能请求接口拿到验证值，然后才能申请抢购接口。理论上来说在访问接口的时间上受到了限制，并且我们还能通过在验证值接口增加更复杂的逻辑，让获取验证值的接口并不快速返回验证值，进一步拉平普通用户和坏蛋们的下单时刻。所以接口加盐还是有用的！
下面我们就实现一种简单的加盐接口代码，抛砖引玉。
代码还是使用之前的项目，我们在其上面增加两个接口：
由于之前我们只有两个表，一个stock表放库存商品，一个stockOrder订单表，放订购成功的记录。但是这次涉及到了用户，所以我们新增用户表，并且添加一个用户张三。并且在订单表中，不仅要记录商品id，同时要写入用户id。
整个SQL结构如下，讲究一个简洁，暂时不加入别的多余字段：
-- ----------------------------
-- Table structure for stock
-- ----------------------------
DROP TABLE IF EXISTS `stock`;
CREATE TABLE `stock` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(50) NOT NULL DEFAULT '' COMMENT '名称',
`count` int(11) NOT NULL COMMENT '库存',
`sale` int(11) NOT NULL COMMENT '已售',
`version` int(11) NOT NULL COMMENT '乐观锁，版本号',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
-- ----------------------------
-- Records of stock
-- ----------------------------
INSERT INTO `stock` VALUES ('1', 'iphone', '50', '0', '0');
INSERT INTO `stock` VALUES ('2', 'mac', '10', '0', '0');
-- ----------------------------
-- Table structure for stock_order
-- ----------------------------
DROP TABLE IF EXISTS `stock_order`;
CREATE TABLE `stock_order` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`sid` int(11) NOT NULL COMMENT '库存ID',
`name` varchar(30) NOT NULL DEFAULT '' COMMENT '商品名称',
`user_id` int(11) NOT NULL DEFAULT '0',
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
-- ----------------------------
-- Records of stock_order
-- ----------------------------
-- ----------------------------
-- Table structure for user
-- ----------------------------
DROP TABLE IF EXISTS `user`;
CREATE TABLE `user` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`user_name` varchar(255) NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4;
-- ----------------------------
-- Records of user
-- ----------------------------
INSERT INTO `user` VALUES ('1', '张三');SQL文件在开源代码里也放了，不用担心。
该接口要求传用户id和商品id，返回验证值，并且该验证值
Controller中添加方法：
/**
* 获取验证值
* @return
*/
@RequestMapping(value = "/getVerifyHash", method = {RequestMethod.GET})
@ResponseBody
public String getVerifyHash(@RequestParam(value = "sid") Integer sid,
@RequestParam(value = "userId") Integer userId) {
String hash;
try {
hash = userService.getVerifyHash(sid, userId);
} catch (Exception e) {
LOGGER.error("获取验证hash失败，原因：[{}]", e.getMessage());
return "获取验证hash失败";
}
return String.format("请求抢购验证hash值为：%s", hash);
}UserService中添加方法：
@Override
public String getVerifyHash(Integer sid, Integer userId) throws Exception {
// 验证是否在抢购时间内
LOGGER.info("请自行验证是否在抢购时间内");
// 检查用户合法性
User user = userMapper.selectByPrimaryKey(userId.longValue());
if (user == null) {
throw new Exception("用户不存在");
}
LOGGER.info("用户信息：[{}]", user.toString());
// 检查商品合法性
Stock stock = stockService.getStockById(sid);
if (stock == null) {
throw new Exception("商品不存在");
}
LOGGER.info("商品信息：[{}]", stock.toString());
// 生成hash
String verify = SALT + sid + userId;
String verifyHash = DigestUtils.md5DigestAsHex(verify.getBytes());
// 将hash和用户商品信息存入redis
String hashKey = CacheKey.HASH_KEY.getKey() + "_" + sid + "_" + userId;
stringRedisTemplate.opsForValue().set(hashKey, verifyHash, 3600, TimeUnit.SECONDS);
LOGGER.info("Redis写入：[{}] [{}]", hashKey, verifyHash);
return verifyHash;
}一个Cache常量枚举类CacheKey：
package cn.monitor4all.miaoshadao.utils;
public enum CacheKey {
HASH_KEY("miaosha_hash"),
LIMIT_KEY("miaosha_limit");
private String key;
private CacheKey(String key) {
this.key = key;
}
public String getKey() {
return key;
}
}代码解释：
可以看到在Service中，我们拿到用户id和商品id后，会检查商品和用户信息是否在表中存在，并且会验证现在的时间（我这里为了简化，只是写了一行LOGGER，大家可以根据需求自行实现）。在这样的条件过滤下，才会给出hash值。并且将Hash值写入了Redis中，缓存3600秒（1小时），如果用户拿到这个hash值一小时内没下单，则需要重新获取hash值。
下面又到了动小脑筋的时间了，想一下，这个hash值，如果每次都按照商品+用户的信息来md5，是不是不太安全呢。毕竟用户id并不一定是用户不知道的（就比如我这种用自增id存储的，肯定不安全），而商品id，万一也泄露了出去，那么坏蛋们如果再知到我们是简单的md5，那直接就把hash算出来了！
在代码里，我给hash值加了个前缀，也就是一个salt（盐），相当于给这个固定的字符串撒了一把盐，这个盐是HASH_KEY("miaosha_hash")，写死在了代码里。这样黑产只要不猜到这个盐，就没办法算出来hash值。
这也只是一种例子，实际中，你可以把盐放在其他地方， 并且不断变化，或者结合时间戳，这样就算自己的程序员也没法知道hash值的原本字符串是什么了。
用户在前台拿到了验证值后，点击下单按钮，前端携带着特征值，即可进行下单操作。
Controller中添加方法：
/**
* 要求验证的抢购接口
* @param sid
* @return
*/
@RequestMapping(value = "/createOrderWithVerifiedUrl", method = {RequestMethod.GET})
@ResponseBody
public String createOrderWithVerifiedUrl(@RequestParam(value = "sid") Integer sid,
@RequestParam(value = "userId") Integer userId,
@RequestParam(value = "verifyHash") String verifyHash) {
int stockLeft;
try {
stockLeft = orderService.createVerifiedOrder(sid, userId, verifyHash);
LOGGER.info("购买成功，剩余库存为: [{}]", stockLeft);
} catch (Exception e) {
LOGGER.error("购买失败：[{}]", e.getMessage());
return e.getMessage();
}
return String.format("购买成功，剩余库存为：%d", stockLeft);
}OrderService中添加方法：
@Override
public int createVerifiedOrder(Integer sid, Integer userId, String verifyHash) throws Exception {
// 验证是否在抢购时间内
LOGGER.info("请自行验证是否在抢购时间内,假设此处验证成功");
// 验证hash值合法性
String hashKey = CacheKey.HASH_KEY.getKey() + "_" + sid + "_" + userId;
String verifyHashInRedis = stringRedisTemplate.opsForValue().get(hashKey);
if (!verifyHash.equals(verifyHashInRedis)) {
throw new Exception("hash值与Redis中不符合");
}
LOGGER.info("验证hash值合法性成功");
// 检查用户合法性
User user = userMapper.selectByPrimaryKey(userId.longValue());
if (user == null) {
throw new Exception("用户不存在");
}
LOGGER.info("用户信息验证成功：[{}]", user.toString());
// 检查商品合法性
Stock stock = stockService.getStockById(sid);
if (stock == null) {
throw new Exception("商品不存在");
}
LOGGER.info("商品信息验证成功：[{}]", stock.toString());
//乐观锁更新库存
saleStockOptimistic(stock);
LOGGER.info("乐观锁更新库存成功");
//创建订单
createOrderWithUserInfo(stock, userId);
LOGGER.info("创建订单成功");
return stock.getCount() - (stock.getSale()+1);
}代码解释：
可以看到service中，我们需要验证了：
如此，我们便完成了一个拥有验证的下单接口。
我们先让用户1，法外狂徒张三登场，发起请求：
http://localhost:8080/getVerifyHash?sid=1&userId=1得到结果:
控制台输出：
别急着下单，我们看一下redis里有没有存储好key：
木偶问题，接下来，张三可以去请求下单了！
http://localhost:8080/createOrderWithVerifiedUrl?sid=1&userId=1&verifyHash=d4ff4c458da98f69b880dd79c8a30bcf得到输出结果：
法外狂徒张三抢购成功了！
假设我们做好了接口隐藏，但是像我上面说的，总有无聊的人会写一个复杂的脚本，先请求hash值，再立刻请求购买，如果你的app下单按钮做的很差，大家都要开抢后0.5秒才能请求成功，那可能会让脚本依然能够在大家前面抢购成功。
我们需要在做一个额外的措施，来限制单个用户的抢购频率。
其实很简单的就能想到用redis给每个用户做访问统计，甚至是带上商品id，对单个商品做访问统计，这都是可行的。
我们先实现一个对用户的访问频率限制，我们在用户申请下单时，检查用户的访问次数，超过访问次数，则不让他下单！
我们使用外部缓存来解决问题，这样即便是分布式的秒杀系统，请求被随意分流的情况下，也能做到精准的控制每个用户的访问次数。
Controller中添加方法：
/**
* 要求验证的抢购接口 + 单用户限制访问频率
* @param sid
* @return
*/
@RequestMapping(value = "/createOrderWithVerifiedUrlAndLimit", method = {RequestMethod.GET})
@ResponseBody
public String createOrderWithVerifiedUrlAndLimit(@RequestParam(value = "sid") Integer sid,
@RequestParam(value = "userId") Integer userId,
@RequestParam(value = "verifyHash") String verifyHash) {
int stockLeft;
try {
int count = userService.addUserCount(userId);
LOGGER.info("用户截至该次的访问次数为: [{}]", count);
boolean isBanned = userService.getUserIsBanned(userId);
if (isBanned) {
return "购买失败，超过频率限制";
}
stockLeft = orderService.createVerifiedOrder(sid, userId, verifyHash);
LOGGER.info("购买成功，剩余库存为: [{}]", stockLeft);
} catch (Exception e) {
LOGGER.error("购买失败：[{}]", e.getMessage());
return e.getMessage();
}
return String.format("购买成功，剩余库存为：%d", stockLeft);
}UserService中增加两个方法：
@Override
public int addUserCount(Integer userId) throws Exception {
String limitKey = CacheKey.LIMIT_KEY.getKey() + "_" + userId;
String limitNum = stringRedisTemplate.opsForValue().get(limitKey);
int limit = -1;
if (limitNum == null) {
stringRedisTemplate.opsForValue().set(limitKey, "0", 3600, TimeUnit.SECONDS);
} else {
limit = Integer.parseInt(limitNum) + 1;
stringRedisTemplate.opsForValue().set(limitKey, String.valueOf(limit), 3600, TimeUnit.SECONDS);
}
return limit;
}
@Override
public boolean getUserIsBanned(Integer userId) {
String limitKey = CacheKey.LIMIT_KEY.getKey() + "_" + userId;
String limitNum = stringRedisTemplate.opsForValue().get(limitKey);
if (limitNum == null) {
LOGGER.error("该用户没有访问申请验证值记录，疑似异常");
return true;
}
return Integer.parseInt(limitNum) > ALLOW_COUNT;
}使用前文用的JMeter做并发访问接口30次，可以看到下单了10次后，不让再购买了：
大功告成了。
且慢，如果你说你不愿意用redis，有什么办法能够实现访问频率统计吗，有呀，如果你放弃分布式的部署服务，那么你可以在内存中存储访问次数，比如：
不知道大家的设计模式复习的怎么样了，如果没有复习到状态模式，可以先去看看状态模式的定义。状态模式很适合实现这种访问次数限制场景。
我的博客和公众号（后端技术漫谈）里，写了个《设计模式自习室》系列，详细介绍了每种设计模式，大家有兴趣可可以看看。【设计模式自习室】开篇：为什么要有设计模式？
这里我就不实现了，毕竟咱们还是分布式秒杀服务为主，不过引用一个博客的例子，大家感受下状态模式的实际应用：
https://www.cnblogs.com/java-my-life/archive/2012/06/08/2538146.html
考虑一个在线投票系统的应用，要实现控制同一个用户只能投一票，如果一个用户反复投票，而且投票次数超过5次，则判定为恶意刷票，要取消该用户投票的资格，当然同时也要取消他所投的票；如果一个用户的投票次数超过8次，将进入黑名单，禁止再登录和使用系统。
public class VoteManager {
//持有状体处理对象
private VoteState state = null;
//记录用户投票的结果，Map<String,String>对应Map<用户名称，投票的选项>
private Map<String,String> mapVote = new HashMap<String,String>();
//记录用户投票次数，Map<String,Integer>对应Map<用户名称，投票的次数>
private Map<String,Integer> mapVoteCount = new HashMap<String,Integer>();
/**
* 获取用户投票结果的Map
*/
public Map<String, String> getMapVote() {
return mapVote;
}
/**
* 投票
* @param user 投票人
* @param voteItem 投票的选项
*/
public void vote(String user,String voteItem){
//1.为该用户增加投票次数
//从记录中取出该用户已有的投票次数
Integer oldVoteCount = mapVoteCount.get(user);
if(oldVoteCount == null){
oldVoteCount = 0;
}
oldVoteCount += 1;
mapVoteCount.put(user, oldVoteCount);
//2.判断该用户的投票类型，就相当于判断对应的状态
//到底是正常投票、重复投票、恶意投票还是上黑名单的状态
if(oldVoteCount == 1){
state = new NormalVoteState();
}
else if(oldVoteCount > 1 && oldVoteCount < 5){
state = new RepeatVoteState();
}
else if(oldVoteCount >= 5 && oldVoteCount <8){
state = new SpiteVoteState();
}
else if(oldVoteCount > 8){
state = new BlackVoteState();
}
//然后转调状态对象来进行相应的操作
state.vote(user, voteItem, this);
}
}public class Client {
public static void main(String[] args) {
VoteManager vm = new VoteManager();
for(int i=0;i<9;i++){
vm.vote("u1","A");
}
}
}结果：
本项目的代码开源在了Github，大家随意使用：
https://github.com/qqxx6661/miaosha
最后，感谢大家的喜爱。
希望大家多多支持我的公主号：后端技术漫谈。
我是一名后端开发工程师。
主要关注后端开发，数据安全，物联网，边缘计算方向，欢迎交流。
公众号：后端技术漫谈.jpg
如果文章对你有帮助，不妨收藏，转发，在看起来~
*请认真填写需求信息，我们会在24小时内与您取得联系。
