三、实战篇优惠券秒杀

源码仓库地址：git@gitee.com:chuangchuang-liu/hm-dingping.git

1、全局唯一ID

数据库默认自增的存在的问题：

id增长规律明显
受单表数据量的限制

场景一分析：id如果增长规律归于明显，容易被用户或者商业对手猜测出一些敏感信息，比如早上出的第一个单子的id是1，晚上再查看出的单子的id是1001，那别人就很容易猜测出你这一天的销售情况。
场景二分析：Mysql数据库的由于查询性能的考虑，单表数据量不建议超过500W。数据量更大时，需要进行分库分表，但从逻辑上来讲这两张表是同一个表，需要保证id的唯一性，增添了一定的维护成本。

全局ID生成器，是一种在分布式系统下用来生成全局唯一ID的工具，一般要满足下列特性：

特性	含义
唯一性	需要保证id全局唯一
高可用	生成器需要保证所有线程来调用时都能提供服务来生成id
高性能	很多业务要求执行时间不能过长如缓存重建，所以对生成器生成id的性能有一定要求
递增性	为了不重复、便于管理和查询以及提高系统的性能和效率
安全性	生成的id不易被猜测或篡改

为了增加ID的安全性，我们可以不直接使用Redis自增的数值，而是拼接一些其它信息：

符号位：永远为0
时间戳：31bit，以秒为单位，可以使用69年
序列号：32bit，秒内的计数器，支持每秒产生2^32个不同ID

编码实现

全局唯一id生成器

@Component
public class RedisIdWorker {/*** 开始时间戳*/private static final long BEGIN_TIMESTAMP = 1640995200L;/*** 序列号的位数*/private static final int COUNT_BITS = 32;private StringRedisTemplate stringRedisTemplate;public RedisIdWorker(StringRedisTemplate stringRedisTemplate) {this.stringRedisTemplate = stringRedisTemplate;}public long nextId(String keyPrefix) {// 1.生成时间戳LocalDateTime now = LocalDateTime.now();long nowSecond = now.toEpochSecond(ZoneOffset.UTC);long timestamp = nowSecond - BEGIN_TIMESTAMP;// 2.生成序列号// 2.1.获取当前日期，精确到天String date = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));// 2.2.自增长long count = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix + ":" + date);// 3.拼接并返回return timestamp << COUNT_BITS | count;}
}

单元测试

@SpringBootTest
class HmDianPingApplicationTests {@Autowiredprivate RedisIdWorker redisIdWorker;private ExecutorService es;/*** 初始化线程池*/@BeforeEachvoid setUp() {es = Executors.newFixedThreadPool(10);}@Testvoid testIdWorker() throws InterruptedException {CountDownLatch latch = new CountDownLatch(300);Runnable task = () -> {for (int i = 0; i < 100; i++) {long id = redisIdWorker.nextId("order");System.out.println("id = " + id);}latch.countDown();};long begin = System.currentTimeMillis();for (int i = 0; i < 300; i++) {es.submit(task);}latch.await();long end = System.currentTimeMillis();System.out.println("time = " + (end - begin));}
}

2、实现优惠券秒杀下单

秒杀需要思考的点：

秒杀活动是否开始或结束
库存是否足够

思路分析：

编码实现

/*** 下单购买秒杀券* @param voucherId 秒杀券id* @return 订单id*/
@Override
@Transactional
public Result order(Long voucherId) {// 查询优惠券信息SeckillVoucher voucher = seckillVoucherService.getById(voucherId);if (ObjectUtil.isEmpty(voucher)) {return Result.fail("id为" + voucherId + "的秒杀券不存在");}// 判断秒杀是否开始if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {return Result.fail("秒杀还未开始");}// 判断秒杀是否结束if (voucher.getEndTime().isBefore(LocalDateTime.now())) {return Result.fail("秒杀已结束");}// 判断秒杀券是否已售罄if (voucher.getStock() < 1) {return Result.fail("秒杀券已售罄");}// 扣减库存boolean success = seckillVoucherService.update().setSql("stock = stock - 1").eq("voucher_id", voucherId).update();if (!success) {return Result.fail("秒杀券已售罄");}// 生成订单VoucherOrder order = new VoucherOrder();long orderID = redisIdWorker.nextId("order");order.setId(orderID);order.setVoucherId(voucherId);order.setUserId(UserHolder.getUser().getId());save(order);return Result.ok(orderID);
}

3、超卖问题

超卖问题原因分析：假设线程1过来查询库存，判断出来库存大于1，正准备去扣减库存，但是还没有来得及去扣减，此时线程2过来，线程2也去查询库存，发现这个数量一定也大于1，那么这两个线程都会去扣减库存，最终多个线程相当于一起去扣减库存，此时就会出现库存的超卖问题。
超卖问题是典型的多线程安全问题，针对这一问题的常见解决方案就是加锁，而对于加锁通常有两种方案：

方案名称	含义	例子
悲观锁	认为线程安全问题一定会发生，因此在操作数据前，添加互斥锁，保证操作是串行的	Synchronized、Lock
乐观锁	认为线程安全问题不一定会发生，因此就不添加锁，只有在做更新操作时，判断其他线程是否做过更新。如果没有改过，才去做更新	CAS

什么是CAS？
CAS（Compare And Swap）是一种用于管理并发数据访问的无锁算法。CAS操作包含三个参数：内存位置（V）、预期原值（A）和新值（B）。执行CAS操作的基本步骤是：如果V的值和预期原值A相同，那么就用新值B替换V的值；如果V的值和预期原值A不相同，就不做任何操作。

乐观锁的两种常见方式：

版本号法（version）
利用业务数据本身来充当版本号

编码实现解决超卖问题

一般是CAS+自旋组合来解决超卖问题：如果CAS失败，但只要库存仍大于0，就允许其继续尝试购买秒杀券
但这里可以简化为只要当前库存量大于0，就允许其继续尝试购买秒杀券

// 扣减库存，添加乐观锁
boolean success = seckillVoucherService.update().setSql("stock = stock - 1").eq("voucher_id", voucherId)// 这种方式反而会增加下单的失败率
//                .eq("stock", voucher.getStock())// 只要库存还大于0，就认为下单成功.gt("stock", 0).update();

4、一人一单

需求： 要求一个用户只能购买一张秒杀券
目前存在的问题： 一个用户可以无限制次数的抢优惠券。应当加一层判断逻辑，当用户成功下完单后，不允许其再次抢优惠券。
判断逻辑： 查询该用户和优惠券在订单表里是否已经存在，如果存在，说明其之前已经抢过优惠券了

编码实现

// 保证一人一单
Integer count = query().eq("voucher_id", voucherId).eq("user_id", userId).count();
if (count > 0) {return Result.fail("id为：" + userId + "的用户已经购买过该秒杀券");
}

存在问题： 在并发情况下仍然会出现一人多单的问题
分析： 该问题和超卖的问题是一致的，因为在查询时，多个线程都进来查询，发现该用户没有下过单，因此都做创建订单操作。
解决方案： 和之前一样，通过添加锁来实现。乐观锁比较适合更新数据，而这里是插入数据操作，适合悲观锁。
注：添加悲观锁这里，存在诸多问题，一个个来分析：

锁的存放位置：在方法上添加同步锁。这种方式下，锁的粒度太粗了，导致每一个线程进来都会被锁住，性能太差

@Transactional
/*将锁放在方法体上，那么这个方法就是一个同步方法，只有一个线程能够进入，会导致性能问题*/
public synchronized Result oneUserAndOrder(Long voucherId) {Long userId = UserHolder.getUser().getId();// 保证一人一单Integer count = query().eq("voucher_id", voucherId).eq("user_id", userId).count();if (count > 0) {return Result.fail("id为：" + userId + "的用户已经购买过该秒杀券");}// 扣减库存，添加乐观锁boolean success = seckillVoucherService.update().setSql("stock = stock - 1").eq("voucher_id", voucherId)// 这种方式反而会增加下单的失败率
//                .eq("stock", voucher.getStock())// 只要我库存还大于0，就允许用户继续下单.gt("stock", 0).update();if (!success) {return Result.fail("秒杀券已售罄");}// 生成订单VoucherOrder order = new VoucherOrder();long orderID = redisIdWorker.nextId("order");order.setId(orderID);order.setVoucherId(voucherId);order.setUserId(UserHolder.getUser().getId());save(order);return Result.ok(orderID);
}

锁的存放位置：在方法体内添加同步锁，且以用户id进行加锁，这样锁的粒度更细，同一个用户线程进来后会去争锁资源，而不会导致所有线程都被锁住。

存在的问题： 在方法体内添加同步代码块，代码块执行完毕后立即释放锁，但事务又是由Spring管理的，此时事务还未提交。其他线程进来后，查询用户未下单，执行创建订单操作。因此这种方式仍会出现多线程并发问题。
解决方案： 事务提交后再释放锁

编码实现

<!--引入aspectJ-->
<dependency><groupId>org.aspectj</groupId><artifactId>aspectjweaver</artifactId>
</dependency>

@Override
public Result order(Long voucherId) {// 查询优惠券信息SeckillVoucher voucher = seckillVoucherService.getById(voucherId);if (ObjectUtil.isEmpty(voucher)) {return Result.fail("id为" + voucherId + "的秒杀券不存在");}// 判断秒杀是否开始if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {return Result.fail("秒杀还未开始");}// 判断秒杀是否结束if (voucher.getEndTime().isBefore(LocalDateTime.now())) {return Result.fail("秒杀已结束");}// 判断秒杀券是否已售罄if (voucher.getStock() < 1) {return Result.fail("秒杀券已售罄");}// 保证一人一单Long userId = UserHolder.getUser().getId();// 3、事务提交后，锁会被释放synchronized (userId.toString().intern()) {// 获取代理对象，代理对象才具备事务功能IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();return proxy.oneUserAndOrder(voucherId);}
}

@Transactional
public Result oneUserAndOrder(Long voucherId) {Long userId = UserHolder.getUser().getId();// 保证一人一单Integer count = query().eq("voucher_id", voucherId).eq("user_id", userId).count();if (count > 0) {return Result.fail("id为：" + userId + "的用户已经购买过该秒杀券");}// 扣减库存，添加乐观锁boolean success = seckillVoucherService.update().setSql("stock = stock - 1").eq("voucher_id", voucherId)// 这种方式反而会增加下单的失败率
//                .eq("stock", voucher.getStock())// 只要我库存还大于0，就允许用户继续下单.gt("stock", 0).update();if (!success) {return Result.fail("秒杀券已售罄");}// 生成订单VoucherOrder order = new VoucherOrder();long orderID = redisIdWorker.nextId("order");order.setId(orderID);order.setVoucherId(voucherId);order.setUserId(UserHolder.getUser().getId());save(order);Result.ok(orderID);
}

@MapperScan("com.hmdp.mapper")
// 启动aop，否则service获取不到aop代理类
@EnableAspectJAutoProxy(exposeProxy = true)
@SpringBootApplication
public class HmDianPingApplication {public static void main(String[] args) {SpringApplication.run(HmDianPingApplication.class, args);}
}

JMeter进行并发安全测试

可以发现，至此已成功添加了一人一单的限制！

5、集群环境下的并发问题

通过加锁可以解决在单机情况下的一人一单安全问题，但是在集群模式下就不行了。
1、我们将服务启动两份，端口分别为8081和8082：

2、修改nginx的配置文件

upstream backend {server 127.0.0.1:8081 max_fails=5 fail_timeout=10s weight=1;server 127.0.0.1:8082 max_fails=5 fail_timeout=10s weight=1;
}

具体操作：
1、通过IDEA克隆一份应用配置

2、添加 vm options

3、重启nginx

nginx -s reload

集群环境下锁失效的原因分析：
现在部署了多套tomcat服务器，每个tomcat内部都有一个jvm，jvm内部多个线程间可以实现锁互斥，但jvm间的线程的锁并不互斥，从而导致互斥锁失效，出现一人多单的问题，这就是集群环境下syn锁失效的原因，在这种情况下就需要使用分布式锁来解决该问题！