场景分析
为了避免对数据库造成压力，我们在新增优惠卷的时候，可以将优惠卷的信息储存在Redis中，这样用户抢购的时候访问优惠卷信息，通过Redis读取信息。
抢购流程：
业务分析
既然在新增优惠卷的时候，我们只需要id和库存信息，那么这个时候我们需要说选择Redis中Stringt数据类型，以id作为键，此时我们在进行抢劵的时候，通过id可以直接查询到对应的库存信息，进行判断。
此时我们会面临一下场景:
- 出现超卖问题
- 不能保证一人一单
超卖问题
锁结构选型:
读多写少的场景：
选择乐观锁。因为读操作不会加锁，可以提高系统的并发性能。写操作通过版本号或条件更新来避免冲突。
写操作频繁且并发量高的场景：
选择悲观锁。悲观锁通过加锁机制可以有效避免并发冲突，保证数据的一致性和正确性。
性能和一致性权衡：
在性能和一致性之间需要权衡。如果一致性要求非常高，且系统能够接受较低的并发性能，选择悲观锁。如果系统需要高性能，并且能够接受偶尔的冲突重试，选择乐观锁。
由于这个优惠卷抢票属于，读多写少这种场景，那么我们选型的话选择乐观锁会比较合适。
数据库乐观锁解决超卖问题
超卖问题分析
假设我们现在库存store = 1 ，那么此时线程一 判断之后 store > 0 那么这个时候线程一开始进行库存缩减，但是此时库存还没开始在数据库中扣减，此时线程二开始查询，发现 store > 0，那么线程二也认定自己抢票成功，开始扣减库存，那么此时就会出现store 减少了两次，那么库存就变成了-1，假设在线程二查询之后，线程一库存扣减之前，线程三又进行了判断，那么此时库存就又变成了-2。这是超卖问题的一个场景。
乐观锁，版本号法：
版本号法：也就是说引入一个新的字段用来检测当前我查询到的version，和我修改时的version是否是同一个，这样的话保证不会出现超卖问题，但是同样，会出现大量失败情况导致错误率极高。不推荐使用
CAS方案：
比较我查询到的库存值跟我更新后的库存值判断。但是这种情况也会出现上述的那种限制，所以我们只要判断扣减前的库存是否大于0即可，那么这种情况效率高，且不会出现大幅度失败。这个主要还是依靠mysql自身的行级锁机制进行的。属于悲观锁的一种范畴。
MySQL 中的行级锁可以确保同一行的数据在同一时间只能被一个事务修改，从而避免了并发更新导致的数据不一致问题。在代码中，当多个线程同时尝试更新同一行数据时，MySQL 会自动对该行数据加锁，以确保只有一个线程能够成功执行更新操作，其他线程会被阻塞直到锁释放。
这种方案解决较上一种方案会好一点，但依旧不是好的解决方案，因为对于这种场景下，阻塞依旧是不可避免的。
boolean voucherId1 = iSeckillVoucherService.update()
.setSql("stock = stock - 1")
.eq("voucher_id", voucherId)
.gt("stock", 0)
.update();
一人一单问题
我们只需要用户下单之后，把用户订单信息，存入Redis中，只需要到时候读取这个信息判断有多少次下单即可。
// 这个位置采用优惠卷id 和 用户 id作为键，储存对应的信息，避免抢其他票时出现误判
String keyUserOrder = "user:order:" + voucherId + user.getId();
Integer count = 0;
try{
count = Integer.valueOf(stringRedisTemplate.opsForValue().get(keyUserOrder));
if (count >= 1) {
return Result.fail("用户已购买");
}
}catch (Exception e){
log.error("第一次抢票");
}
// 这个是抢票成功时，将订单信息保存。值自增用来判断是否是第一次购买
Long orderCount = stringRedisTemplate.opsForValue().increment(keyUserOrder, 1);
新的实现思路
既然是抢劵，那我确实无法避免这个内容。我可以说实现一个优惠卷池，将这个内容存入Redis中，抢到的话就生成订单，这样的话也没有超卖问题。只不过还得解决一人一单。效率较上面这种会更好一点。
实现步骤
- 初始化优惠券池：将每张优惠券的信息预先存入Redis。
- 抢券逻辑：用户请求时，从Redis中获取一张优惠券。
- 生成订单：抢到优惠券后，生成订单并将订单信息和优惠券信息关联起来。
- 一人一单检查：确保同一用户不能重复抢券。
代码示例
以下是一个简单的代码实现示例：
初始化优惠券池：
// 初始化优惠券池，将100张优惠券信息存入Redis
String voucherPoolKey = "voucher:pool";
for (int i = 1; i <= 100; i++) {
// 假设优惠券信息是一个简单的字符串，这里可以是更复杂的对象
stringRedisTemplate.opsForList().leftPush(voucherPoolKey, "voucher_" + i);
}
抢券逻辑
public Result grabVoucher(Long voucherId, Long userId) {
// Redis中的键
String voucherPoolKey = "voucher:pool";
String userOrderKey = "user:order:" + voucherId + ":" + userId;
// 检查用户是否已经抢过
if (Boolean.TRUE.equals(stringRedisTemplate.hasKey(userOrderKey))) {
return Result.fail("用户已购买");
}
// 从Redis中弹出一张优惠券
String voucher = stringRedisTemplate.opsForList().rightPop(voucherPoolKey);
if (voucher == null) {
return Result.fail("优惠券已抢完");
}
// 抢券成功，生成订单
// 这里假设订单生成成功，实际应用中需要加入订单生成逻辑
String orderInfo = "order_for_" + voucher + "_by_user_" + userId;
// 记录用户抢券信息
stringRedisTemplate.opsForValue().set(userOrderKey, orderInfo);
return Result.ok("抢券成功", orderInfo);
}
订单生成
实际的订单生成过程可能涉及复杂的业务逻辑和数据库操作，这里简化为成功后记录用户抢券信息。
一人一单的实现
在用户抢券前，检查用户是否已经抢过，通过Redis键的存在性判断。
// 检查用户是否已经抢过
if (Boolean.TRUE.equals(stringRedisTemplate.hasKey(userOrderKey))) {
return Result.fail("用户已购买");
}
优点
- 高效处理并发：Redis的高吞吐量和低延迟使得这种方案在高并发场景下表现出色。
- 避免超卖：优惠券从Redis中弹出后即减少，确保不会超卖。
- 简单实现一人一单：通过Redis键值对存储和检查用户抢券信息，轻松实现一人一单的限制。
- 简化订单生成：在抢券成功后，立即生成订单并将信息存储在Redis中，减少了数据库操作的复杂性。
或者我感觉这个并发场景比较大的情况下，使用RabbitMQ削峰填谷，做限流也可以。
