软件测试商城项目优惠券超发问题该怎么测试？

在拼夕夕面试中，面试官问了一连串经典的问题：“优惠券库存是怎么扣减的？开发为了解决超发优惠券问题而设计的方案，你了解过吗？你又是如何测试的呢？”

当时听到这些问题还挺懵的，没遇到过超发问题啊？开发设计的方案我怎么知道？现在想起来还挺幼稚的，其实现在想想电商中有很多类似的问题，比如商品超卖，归根究底，就是一个问题，那就是并发安全问题。

问题引入

就拿领取优惠券的问题来说，

需求描述：A 优惠券一共发行 100张，每一个用户最多可以领取5张。

当一个用户领取优惠券成功的时候，把领取的记录写入另外一个表中（这张表我们暂且称为表 B）。

在领取优惠券的过程中，优惠券库存的扣减过程，一般操作如下：

1、select查询优惠券的库存。

2、计算优惠券库存是否足够，如果优惠券存库不足则抛出库存不足的异常，如果优惠券库存足够，则判断是否在领取时间、判断用户领取数量是否超过个人最高领取限制。

3、如果2成立，则减去扣除的库存得到最新的库存剩余值。

4、set设置最新的优惠券库存剩余值

伪代码如下：

 扣减优惠券sql如下：

update coupon set stock = stock - 1 where id = #{coupon_id}

并发量比较低的时候，几乎看不出来有问题，可是当我们开启多线程，去请求这个抢优惠券的接口时，问题出现了，id为19的这个优惠券库存为负数。多发了一个，什么原因呢？

深入解读并发安全问题

为啥并发量高的时候会出现优惠券库存多发的问题呢？原因如下截图：

上图中出现问题的环节其实是判断优惠券库存那个步骤，重点来了：

高并发情况下，如果同时来了两个线程线程 A和线程 B（可以理解成是两个请求），比如先来的那个线程A请求通过了检查，这时线程 A 还没有扣减库存，这时经过一番操作，线程B也通过了这个检查优惠券是否可领取的方法，然后线程 A 和线程 B 依次扣减库存或者是同时扣减库存。所以就出现了刚刚数据库出现的现象，优惠券库存为-1个，就像下图。

怎么解决并发安全问题？

Java 代码加锁

2. synchronized (this){

4. LoginUser loginUser = LoginInterceptor.threadLocal.get();

6. CouponDO couponDO = couponMapper.selectOne(new QueryWrapper()

8. .eq("id", couponId)

10. .eq("category", categoryEnum.name()));

12. if(couponDO == null){

14. throw new BizException(BizCodeEnum.COUPON_NO_EXITS);

16. }

18. this.checkCoupon(couponDO,loginUser.getId());

21. //构建领券记录

23. CouponRecordDO couponRecordDO = new CouponRecordDO();

25. BeanUtils.copyProperties(couponDO,couponRecordDO);

27. couponRecordDO.setCreateTime(new Date());

29. couponRecordDO.setUseState(CouponStateEnum.NEW.name());

31. couponRecordDO.setUserId(loginUser.getId());

33. couponRecordDO.setUserName(loginUser.getName());

35. couponRecordDO.setCouponId(couponDO.getId());

37. couponRecordDO.setId(null);

40. int row = couponMapper.reduceStock(couponId);

42. if(row == 1){

44. couponRecordMapper.insert(couponRecordDO);

46. }else{

48. log.info("发送优惠券失败:{},用户:{}",couponDO,loginUser);

50. }

52. }

加个synchronized关键字，这样每个请求都得排队执行这个扣减库存操作，可以一定程度解决并发安全问题，但由于synchronized关键字基于jvm级别加锁，当集群环境下，有多个jvm进程,所以这种方法仅适用于单机节点。

Sql版本号

update product set stock=stock-1 where stock=#{上一次的库存}  and id = #{id} and stock>0

这种方法有个ABA的问题，我们可以加个version字段，每次修改数据的时候这个字段会加 1，这样就可以避免 ABA 问题。但是这种依靠数据库进行并发安全保障，会消耗数据库的资源，一定请求量内（需经过严格测试）可使用。

     update product set stock=stock-1,versioin = version+1 where   #{id} and stock>0 and version=#{上一次的版本号}

Redis分布式锁

引入 Redis 后，当领取优惠券时会先去 Redis 里面去获取锁，当锁获取成功后才可以对数据库进行操作。

在分布式锁中我们应该考虑如下：

排他性，在分布式集群中，同一个方法，在同一个时间只能被某一台机器上的一个线程执行；
容错性，当一个线程上锁后，如果机器突然的宕机，如果不释放锁，此时这条数据将会被锁死；
还要注意锁的粒度，锁的开销；
满足高可用，高性能，可重入。
伪代码如下：

2. @RestController

4. public class IndexController {

7. public static final String REDIS_LOCK = "coupon_lock";

10. @Autowired

12. StringRedisTemplate template;

15. @RequestMapping("/getCoupon")

17. public String getCoupon(){

20. // 每个人进来先要进行加锁，key值为"good_lock"

22. String value = UUID.randomUUID().toString().replace("-","");

24. try{

26. // 为key加一个过期时间

28. Boolean flag = template.opsForValue().setIfAbsent(REDIS_LOCK, value,10L,TimeUnit.SECONDS);

30. // 加锁失败

32. if(!flag){

34. return "抢锁失败！";

36. }

38. System.out.println( value+ " 抢锁成功");

40. String result = template.opsForValue().get("coupon:001");

42. int total = result == null ? 0 : Integer.parseInt(result);

44. if (total > 0) {

46. // 在此处需要处理抢购优惠券业务，处理时间较长。。。

48. int realTotal = total - 1;

50. template.opsForValue().set("coupon:001", String.valueOf(realTotal));

52. System.out.println("获取优惠券成功，库存还剩：" + realTotal + "件， 服务端口为8001");

54. return "获取优惠券成功，库存还剩：" + realTotal + "件， 服务端口为8001";

56. } else {

58. System.out.println("获取优惠券失败，服务端口为8001");

60. }

62. return "获取优惠券失败，服务端口为8001";

64. }finally {

66. // 谁加的锁，谁才能删除，使用Lua脚本，进行锁的删除

68. Jedis jedis = null;

70. try{

72. jedis = RedisUtils.getJedis();

74. String script = "if redis.call('get',KEYS[1]) == ARGV[1] " +

76. "then " +

78. "return redis.call('del',KEYS[1]) " +

80. "else " +

82. " return 0 " +

84. "end";

87. Object eval = jedis.eval(script, Collections.singletonList(REDIS_LOCK), Collections.singletonList(value));

89. if("1".equals(eval.toString())){

91. System.out.println("-----del redis lock ok....");

93. }else{

95. System.out.println("-----del redis lock error ....");

97. }

99. }catch (Exception e){

102. }finally {

104. if(null != jedis){

106. jedis.close();

108. }

110. }

112. }

114. }

116. }

Redission 红锁

Redission红锁其实是上述redis分布式锁的升级版，主要是框架已经封装好了我们需要的方法，实际过程中只要引入相应的jar包，使用对应的api即可。

Maven引入：

   org.redisson
   redisson
   3.17.4
伪代码如下：

2. public JsonData getCoupon(long couponId, CouponCategoryEnum categoryEnum) {

4. String key = "lock:coupon:" + couponId;

6. RLock rLock = redisson.getLock(key);

8. LoginUser loginUser = LoginInterceptor.threadLocal.get();

10. rLock.lock();

12. try{

14. //业务逻辑

16. }finally {

18. rLock.unlock();

20. }

22. return JsonData.buildSuccess();

24. }

使用这种方式也无需关心 key 过期时间续期的问题，因为在 Redisson 一旦加锁成功，就会启动一个 watch dog，你可以将它理解成一个守护线程，它默认会每隔 30 秒(可灵活配置)检查一下，如果当前客户端还占有这把锁，它会自动对这个锁的过期时间进行延长。

Zookeeper分布式锁

Zookeeper分布式锁应用了临时顺序节点。具体如何实现呢？让我们来看一看详细步骤：

获取锁：

首先，在Zookeeper当中创建一个持久节点ParentLock。当第一个客户端（Client1）想要获得锁时，需要在ParentLock这个节点下面创建一个临时顺序节点 Lock1。

之后，Client1查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是第一个节点，则成功获得锁。

这时候，如果再有一个客户端 Client2 前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock2。

Client2查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock2是不是顺序最靠前的一个，结果发现节点Lock2并不是最小的。

于是，Client2向排序仅比它靠前的节点Lock1注册Watcher，用于监听Lock1节点是否存在。这意味着Client2抢锁失败，进入了等待状态。

这时候，如果又有一个客户端Client3前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock3。

Client3查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock3是不是顺序最靠前的一个，结果同样发现节点Lock3并不是最靠前的。

于是，Client3向排序仅比它靠前的节点Lock2注册Watcher，用于监听Lock2节点是否存在。这意味着Client3同样抢锁失败，进入了等待状态。

这样一来，Client1得到了锁，Client2监听了Lock1，Client3监听了Lock2。这恰恰形成了一个等待队列，很像是Java当中ReentrantLock所依赖的AQS。

怎么测试并发安全问题？

首先我们要保证测试环境的项目是分布式、集群部署，其次可以根据线上获取优惠券接口的实际QPS，在测试环境使用工具jmeter并发请求优惠券接口，运行一段时间后，再去看下数据库相应的数据，譬如优惠券库存信息，抢购优惠券信息等等，反复多次运行看下效果。

总结

本篇文章主要分享了电商项目中一种常见的并发安全问题，以及相应的解决方案，如果从性能的角度去考虑应该是Redis > zookeeper > 数据库。从可靠性（安全）性角度：zookeeper > Redis > 数据库。