秒杀场景下的业务梳理——Redis分布式锁的优化

发布时间:2024年01月23日

秒杀场景下的业务梳理——Redis分布式锁的优化

随着互联网的快速发展,商品秒杀的场景我们并不少见;秒杀是一种供不应求的,高并发的场景,它里面包含了很多技术点,掌握了其中的技术点,虽不一定能让你面试立马成功,但那也必是一个闪耀的点!

前言

假设我们现在有一个商城系统,里面上线了一个商品秒杀的模块,那么这个模块我们要怎么设计呢?

秒杀模块又会有哪些不同的需求呢?

全局唯一 ID

商品秒杀本质上其实还是商品购买,所以我们需要准备一张订单表来记录对应的秒杀订单。

这里就涉及到了一个订单 id 的问题了,我们是否可以像其他表一样使用数据库自身的自增 id 呢?

数据库自增 id 的缺点

订单表如果使用数据库自增 id ,则会存在一些问题:

  1. id 的规律太明显了 因为我们的订单 id 是需要回显给用户查看的,如果是 id 规律太明显的话,会暴露一些信息,比如第一天下单的 id = 10 , 第二天下单的 id = 11,这就说明这两单之间根本没有其他用户下单
  2. 受单表数据量的限制 在高并发场景下,产生上百万个订单都是有可能的,而我们都知道 MySQL 的单张表根本不可能容纳这么多数据(性能等原因的限制);如果是将单表拆成多表,还是用数据库自增 id 的话,就存在了订单 id 重复的情况了,很显然这是业务不允许的。

基于以上两个问题,我们可以知道订单表的 id 需要是一个全局唯一的 ID,而且还不能存在明显的规律。

全局 ID 生成器

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

image.png

这里我们思考一下是否可以用 Redis 中的自增计数来作为全局 id 生成器呢?

能不能主要是看它是否满足上述 5 个条件:

  1. 唯一性,每个订单都是来 Redis 这里生成订单 id 的,所以唯一性可以保证
  2. 高可用,Redis 可以由主从、集群等模式保证可用性
  3. 高性能,Redis 是基于内存的,本来就是以性能自称的
  4. 递增性,increment 本来就是递增的
  5. 安全性。。。这个就麻烦了点了,因为 Redis 的 increment 也是递增的,规律太明显了。。。

综上,Redis 的 increment 并不能满足安全性,所以我们不能单纯使用它来做全局 id 生成器。

但是——

我们可以使用它,再和其他东西拼接起来~

举个栗子:

image.png

ID的组成部分:

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

上面的时间戳就是用来增加复杂性的

下面给出代码样例:

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.自增长
 ? ? ? ?// 每天一个key
 ? ? ? ?long count = stringRedisTemplate.opsForValue()
 ? ? ? ? ?                              .increment("icr:" + keyPrefix + ":" + date);
?
 ? ? ? ?// 3.拼接并返回
 ? ? ? ?return timestamp << COUNT_BITS | count;
 ?  }
}

Redis自增ID策略:

  1. 每天一个key,方便统计订单量
  2. ID构造是 时间戳 + 计数器

扩展

全局唯一ID生成策略:

  1. UUID
  2. Redis自增(需要额外拼接)
  3. snowflake算法
  4. 数据库自增

超卖问题的产生

动画.gif

解决方案

超卖问题是典型的多线程安全问题,针对这一问题的常见解决方案就是加锁:

锁有两种:

一,悲观锁: 认为线程安全问题一定会发生,因此在操作数据之前先获取锁,确保线程串行执行。例如Synchronized、Lock都属于悲观锁;

二,乐观锁: 认为线程安全问题不一定会发生,因此不加锁,只是在更新数据时去判断有没有其它线程对数据做了修改。

如果没有修改则认为是安全的,自己才更新数据。 如果已经被其它线程修改说明发生了安全问题,此时可以重试或异常。

乐观锁的两种实现

下面介绍乐观锁的两种实现:

第一种,添加版本号:

每扣减一次就更改一下版本号,每次进行扣减之前需要查询一下版本号,只有在扣减时的版本号和之前的版本号相同时,才进行扣减。

动画2.gif

第二种,CAS法

因为每扣减一次,库存量都会发生改变的,所以我们完全可以用库存量来做标志,标志当前库存量是否被其他线程更改过(在这种情况下,库存量的功能和版本号类似)

动画3.gif

下面给出 CAS 法扣除库存时,针对超卖问题的解决方案:

 ? // 扣减库存
 ? boolean success = seckillVoucherService.update()
 ? ? ? ? ? ? ? ? ?  .setSql("stock = stock - 1") // set stock = stock - 1
 ? ? ? ? ? ? ? ? ?  .eq("voucher_id", voucherId).gt("stock", 0) // where id = ? and stock > 0
 ? ? ? ? ? ? ? ? ?  .update();

请注意上述的 CAS 判断有所优化了的,并不是判断刚查询的库存和扣除时的库存是否相等,而是判断当前库存是否大于 0。

因为 判断刚查询的库存和扣除时的库存是否相等会出现问题:假如多个线程都判断到不相等了,那它们都停止了扣减,这时候就会出现没办法买完了。

判断当前库存是否大于 0,则可以很好地解决上述问题!

一人一单的需求

一般来说秒杀的商品都是优惠力度很大的,所以可能存在一种需求——平台只允许一个用户购买一个商品。

对于秒杀场景下的这种需求,我们应该怎么去设计呢?

很明显,我们需要在执行扣除库存的操作之前,先去查查数据库是否已经有了该用户的订单了;如果有了,说明该用户已经下单过了,不能再购买;如果没有,则执行扣除操作并生成订单。

// 查询订单
int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
// 判断是否存在
if (count > 0) {
 ? ?// 用户已经购买过了
 ? ?return Result.fail("用户已经购买过一次!");
}
?
// 扣减库存
boolean success = seckillVoucherService.update()
 ? ? ?  .setSql("stock = stock - 1") // set stock = stock - 1
 ? ? ?  .eq("voucher_id", voucherId).gt("stock", 0) // where id = ? and stock > 0
 ? ? ?  .update();

并发安全问题

因为上述的实现是分成两步的:

  1. 判断当前用户在数据库中并没有订单
  2. 执行扣除操作,并生成订单

也正因为是分成了两步,所以才引发了线程安全问题: 可以是同一个用户的多个请求线程都同时判断没有订单,后续则大家都执行了扣除操作。

要解决这个问题,也很简单,只要让这两步串行执行即可,也就是加锁!

在方法头上加 synchronized

很显然这种会锁住整个方法,锁的范围太大了,而且会对所有请求线程作出限制;而我们的需求只是同一个用户的请求线程串行就可以了;显然有些大材小用了~

@Transactional
public synchronized Result createVoucherOrder(Long voucherId) {
 ? ?// 一人一单
 ? ?Long userId = UserHolder.getUser().getId
 ? ? // 查询订单
 ? ? int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
 ? ? // 判断是否存在
 ? ? if (count > 0) {
 ? ? ? ? // 用户已经购买过了
 ? ? ? ? return Result.fail("用户已经购买过一次!");
 ? 
 ? ? // 扣减库存
 ? ? boolean success = seckillVoucherService.update()
 ? ? ? ? ? ? .setSql("stock = stock - 1") // set stock = stock - 1
 ? ? ? ? ? ? .eq("voucher_id", voucherId).gt("stock", 0) // where id = ? and stock > 0
 ? ? ? ? ? ? .update();
 ? ? if (!success) {
 ? ? ? ? // 扣减失败
 ? ? ? ? return Result.fail("库存不足!");
 ? 
 ? ? // 创建订单
 ? ? VoucherOrder voucherOrder = new VoucherOrder();
 ? ? .....
 ? ? return Result.ok(orderId);
}
锁住同一用户 id 的 String 对象
@Transactional
public Result createVoucherOrder(Long voucherId) {
 ? ?// 一人一单
 ? ?Long userId = UserHolder.getUser().getId
 ? ?
 ? ?// 锁住同一用户 id 的 String 对象
 ? ?synchronized (userId.toString().intern()) {
 ? ?    // 查询订单
 ? ?    int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
 ? ?    // 判断是否存在
 ?      ......
 ? ? ? ? ? ?
 ? ?    // 扣减库存
 ? ? ?  ......
 ?  
 ? ?    // 创建订单
 ? ?    ......
 ? ? }
 ? ? return Result.ok(orderId);
}

上述方法开启了事务,但是synchronized (userId.toString().intern())锁住的却不是整个方法(先释放锁,再提交事务,写入订单),那就存在一个问题——假如一个线程的事务还没提交(也就是还没写入订单),这时候其他线程来了却可以获得锁,它判断数据库中订单为0 ,又可以再次创建订单。。。。

为了解决这个问题,我们需要先提交事务,再释放锁:

 // 锁住同一用户 id 的 String 对象
 synchronized (userId.toString().intern()) {
 ? ? ......
    createVoucherOrder(voucherId);
 ? ? ......
 }
?
@Transactional
public Result createVoucherOrder(Long voucherId) {
 ? ?// 一人一单
 ? ?Long userId = UserHolder.getUser().getId
 ? ?
 ? 
 ? ?    // 查询订单
 ? ?    int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
 ? ?    // 判断是否存在
 ?      ......
 ? ? ? ? ? ?
 ? ?    // 扣减库存
 ? ? ?  ......
 ?  
 ? ?    // 创建订单
 ? ?    ......
 ? ? 
 ? ? return Result.ok(orderId);
}

集群模式下的并发安全问题

刚刚讨论的那些都默认是单机结点的,可是现在如果放在了集群模式下的话就会出现一下问题。

刚刚的加锁已经解决了单机节点下的线程安全问题,但是却不能解决集群下多节点的线程安全问题:

因为 synchronized 锁的是对应 JVM 内的锁监视器,可是不同的结点有不同的 JVM,不同的 JVM 又有不同的锁监视器,所以刚刚的设计在集群模式下锁住的其实还是不同的对象,即无法解决线程安全问题。

image.png

知道问题产生的原因,我们应该很快就想到了解决办法了:

既然是因为集群导致了锁不同,那我们就重新设计一下,让他们都使用同一把锁即可!

image.png

分布式锁

分布式锁:满足分布式系统或集群模式下多进程可见并且互斥的锁。

image.png

分布式锁的实现

分布式锁的核心是实现多进程之间互斥,而满足这一点的方式有很多,常见的有三种:

MySQLRedisZookeeper
互斥利用mysql本身的互斥锁机制利用setnx这样的互斥命令利用节点的唯一性和有序性实现互斥
高可用
高性能一般一般
安全性断开连接,自动释放锁利用锁超时时间,到期释放临时节点,断开连接自动释放

基于 Redis 的分布式锁

用 Redis 实现分布式锁,主要应用到的是 SETNX key value命令(如果不存在,则设置)

主要要实现两个功能:

  1. 获取锁(设置一个 key)
  2. 释放锁 (删除 key)

基本思想是执行了 SETNX命令的线程获得锁,在完成操作后,需要删除 key,释放锁。

加锁:

@Override
public boolean tryLock(long timeoutSec) {
 ? ?// 获取线程标示
 ? ?String threadId = ID_PREFIX + Thread.currentThread().getId();
 ? ?// 获取锁
 ? ?Boolean success = stringRedisTemplate.opsForValue()
 ? ? ? ? ?  .setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);
 ? ?return Boolean.TRUE.equals(success);
}

释放锁:

@Override
public void unlock() {
 ? ?// 获取线程标示
 ? ?String threadId = ID_PREFIX + Thread.currentThread().getId();
 ? ?// 获取锁中的标示
 ? ?String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name);
 ? ?// 释放锁
 ? ?stringRedisTemplate.delete(KEY_PREFIX + name);
}

可是这里会存在一个隐患——假设该线程发生阻塞(或者其他问题),一直不释放锁(删除 key)这可怎么办?

为了解决这个问题,我们需要为 key 设计一个超时时间,让它超时失效;但是这个超时时间的长短却不好确定:

  1. 设置过短,会导致其他线程提前获得锁,引发线程安全问题
  2. 设置过长,线程需要额外等待
锁的误删

动画4.gif

超时时间是一个非常不好把握的东西,因为业务线程的阻塞时间是不可预估的,在极端情况下,它总能阻塞到 lock 超时失效,正如上图中的线程1,锁超时释放了,导致线程2也进来了,这时候 lock 是 线程2的锁了(key 相同,value不同,value一般是线程唯一标识);假设这时候,线程1突然不阻塞了,它要释放锁,如果按照刚刚的代码逻辑的话,它会释放掉线程2的锁;线程2的锁被释放掉之后,又会导致其他线程进来(线程3),如此往复。。。

为了解决这个问题,需要在释放锁时多加一个判断,每个线程只释放自己的锁,不能释放别人的锁!

释放锁

@Override
public void unlock() {
 ? ?// 获取线程标示
 ? ?String threadId = ID_PREFIX + Thread.currentThread().getId();
 ? ?// 获取锁中的标示
 ? ?String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name);
 ? ?
 ? ?// 判断标示是否一致
 ? ?if(threadId.equals(id)) {
 ? ? ? ?// 释放锁
 ? ? ? ?stringRedisTemplate.delete(KEY_PREFIX + name);
 ?  }
}

原子性问题

刚刚我们谈论的释放锁的逻辑:

  1. 判断当前锁是当前线程的锁
  2. 当前线程释放锁

可以看到释放锁是分两步完成的,如果你是对并发比较有感觉的话,应该一下子就知道这里会存在问题了。

分步执行,并发问题!

动画5.gif

假设 线程1 已经判断当前锁是它的锁了,正准备释放锁,可偏偏这时候它阻塞了(可能是 FULL GC 引起的),锁超时失效,线程2来加锁,这时候锁是线程2的了;可是如果线程1这时候醒过来,因为它已经执行了步骤1了的,所以这时候它会直接直接步骤2,释放锁(可是此时的锁不是线程1的了)

其实这就是一个原子性的问题,刚刚释放锁的两步应该是原子的,不可分的!

要使得其满足原子性,则需要在 Redis 中使用 Lua 脚本了。

引入 Lua 脚本保持原子性

lua 脚本:

-- 比较线程标示与锁中的标示是否一致
if(redis.call('get', KEYS[1]) == ?ARGV[1]) then
 ? ?-- 释放锁 del key
 ? ?return redis.call('del', KEYS[1])
end
return 0

Java 中调用执行:

public class SimpleRedisLock implements ILock {
?
 ? ?private String name;
 ? ?private StringRedisTemplate stringRedisTemplate;
?
 ? ?public SimpleRedisLock(String name, StringRedisTemplate stringRedisTemplate) {
 ? ? ? ?this.name = name;
 ? ? ? ?this.stringRedisTemplate = stringRedisTemplate;
 ?  }
?
 ? ?private static final String KEY_PREFIX = "lock:";
 ? ?private static final String ID_PREFIX = UUID.randomUUID().toString(true) + "-";
 ? ?private static final DefaultRedisScript<Long> UNLOCK_SCRIPT;
 ? ?static {
 ? ? ? ?UNLOCK_SCRIPT = new DefaultRedisScript<>();
 ? ? ? ?UNLOCK_SCRIPT.setLocation(new ClassPathResource("unlock.lua"));
 ? ? ? ?UNLOCK_SCRIPT.setResultType(Long.class);
 ?  }
?
 ? ?@Override
 ? ?public boolean tryLock(long timeoutSec) {
 ? ? ? ?// 获取线程标示
 ? ? ? ?String threadId = ID_PREFIX + Thread.currentThread().getId();
 ? ? ? ?// 获取锁
 ? ? ? ?Boolean success = stringRedisTemplate.opsForValue()
 ? ? ? ? ? ? ?  .setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);
 ? ? ? ?return Boolean.TRUE.equals(success);
 ?  }
?
 ? ?@Override
 ? ?public void unlock() {
 ? ? ? ?// 调用lua脚本
 ? ? ? ?stringRedisTemplate.execute(
 ? ? ? ? ? ? ? ?UNLOCK_SCRIPT,
 ? ? ? ? ? ? ? ?Collections.singletonList(KEY_PREFIX + name),
 ? ? ? ? ? ? ? ?ID_PREFIX + Thread.currentThread().getId());
 ?  }
}
?

到了目前为止,我们设计的 Redis 分布式锁已经是生产可用的,相对完善的分布式锁了。

总结

这一次我们从秒杀场景的业务需求出发,一步步地利用 Redis 设计出一种生产可用的分布式锁:

实现思路:

  1. 利用set nx ex获取锁,并设置过期时间,保存线程标示
  2. 释放锁时先判断线程标示是否与自己一致,一致则删除锁 (Lua 脚本保证原子性)

有哪些特性?

  1. 利用set nx满足互斥性
  2. 利用set ex保证故障时锁依然能释放,避免死锁,提高安全性
  3. 利用Redis集群保证高可用和高并发特性

目前还有待完善的点:

  1. 不可重入,同一个线程无法多次获取同一把锁
  2. 不可重试,获取锁只尝试一次就返回false,没有重试机制
  3. 超时释放,锁超时释放虽然可以避免死锁,但如果是业务执行耗时较长,也会导致锁释放,存在安全隐患(虽然已经解决了误删问题,但是仍然可能存在未知问题)
  4. 主从一致性,如果Redis提供了主从集群,主从同步存在延迟,当主宕机时,在主节点中的锁数据并没有及时同步到从节点中,则会导致其他线程也能获得锁,引发线程安全问题(延迟时间是在毫秒以下的,所以这种情况概率极低)
文章来源:https://blog.csdn.net/m0_54385790/article/details/135768651
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。