Redis面试题之Redis事务,Redis分布式锁

╰半橙微兮° 2022-10-30 02:28 248阅读 0赞

# 1. Redis事务简介 #

为了避免Redis执行指令过程中, 多条连续执行的指令被干扰, 打断, 插队这种情况, 就需要开启事务.

Redis事务就是一个命令执行的队列, 将一系列预定义命令包装成一个整体(一个队列), 当执行时, 一次性按照添加顺序依次执行, 中间不会被打断或者干扰.

或者简单的理解, 就是一个队列中, 一次性,顺序性, 排他性的执行一系列命令.

# 2. Redis事务操作 #

## 2.1 Redis事务的基本操作 ##

*  开启事务`multi`  
    作用: 设定事务的开启位置, 次指令后, 后续的所有指定均加入到事务中.
 *  执行事务`exec`  
    作用: 设定事务的结束位置, 同时执行事务, 与multi成对出现, 成对使用.

**注意: 加入事务的命令暂时进入到任务队列中, 并没有立即执行, 只有与执行exec命令才开始执行.**

*  取消事务`discard`  
    作用: 终止当前事务的定义, 发生在multi之后, exec之前.

## 2.2 事务的工作流程 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70_pic_center]

*  执行指令
 *  服务器判断指令是否是事务指令
    
     *  普通指令就普通执行
     *  如果是`multi`就创建队列, 并返回ok
        
         *  继续执行指令
         *  服务器继续判断指令是否是事务指令
            
             *  如果是`exec`, 则执行事务, 并返回队列中所有结果
             *  如果是普通指令, 则加入队列中, 返回queued
             *  如果是`discard`, 则销毁队列, 返回ok

## 2.3 使用事务的注意事项 ##

*  如果开启事务后, 命令中出现了语法错误, 则导致该事务队列失效(之前书写正确的也失效了), 这就是都会整体失败.
 *  如果开始事务后, 命令执行时出现了错误, 则提交事务后, 正确的被执行了, 错误的不被执行, 也就是说不会整体回滚, 那只能手动回滚数据.
 *  如何手动进行事务回滚呢?

1.  记录操作过程中被影响的数据之前的状态  
    单数据: String  
    多数据:hash, list, set, zset
2.  设置指令恢复所有的被修改的项  
    单数据: 直接set回去,注意该值是否有时效, 如有也有设置回去  
    多数据: 修改对应值或者整体克隆复制.

## 2.4 基于特定条件的事务执行-锁 ##

实际开发过程中, 为了高可用, 会有多个客户端有操作Redis的权限. 为了保证同一个key只能被一个的客户端增删改操作, 需要对同一数据加锁.

*  场景分析  
    天猫双11热卖过程中, 对已经售罄的货物追加补货, 4个业务员都有权限补货, 只能被一个业务员连续操作, 不能被多个业务员重复补货, 如何解决呢?
    
    1.  多个客户端有可能同时操作同一个key, 且该key只能被修改一次.
    2.  如果修改后, 后面再被修改则要终止当前的操作.
    3.  肯定也要添加事务, 涉及增删改问题肯定是要添加事务的.
 *  解决方案
    
    1.  对同一个要修改的key添加监听锁
    2.  开启事务
    3.  一旦该key发生改变, 当前客户端操作的事务则失败
        
            watch key1 [key2, key3......] # 监听指定的key
            multi # 开启事务
            ... # 进行一些列操作
            exec # 提交事务
    4.  如何取消监视呢? 可以取消对所有key的监视
        
            unwatch

**因此, 这也是Redis的一个应用场景, Redis应用基于状态控制的批量任务执行.**

# 3. 分布式锁 #

## 3.1 分布式锁是什么 ##

实际开发过程中, 也会遇到如下场景, 不但要保证同一个key只能被一个的客户端增删改操作, 还要监控该key对应的value值, 这时就需要设置分布式锁了.

*  场景分析  
    还是天猫双11热卖过程中, 怎么避免最后一件商品不被多人同时购买(超卖问题)
    
    1.  watch监听能监听特定的key是否被修改, 但是无法监听被修改的值, 此处要监控的是具体的数据.
    2.  虽然Redis是单线程的, 但是多个客户端对同一数据同时进行操作时, 如何避免不被同时修改呢?
 *  解决方案
    
    1.  使用setnx设置一个公共锁 `setnx lock-key value`, value可以为随机任意值.
    2.  setnx命令能返回value值.只有第一次执行的才会成功并返回1，其它情况返回0：  
        如果返回是1, 说明没有人持有锁, 当前客户端设置锁成功,可以进行下一步的具体业务操作.  
        如果返回是0, 说明有人持有了锁, 当前客户端设置锁失败, 那么需要排队或等待锁的释放.
    3.  操作完毕通过del操作释放锁.

**这就是Redis分布式锁的雏形, 当然实际开发中要考虑锁时效性避免死锁问题,还要避免锁误删问题, 因此有接下来几种版本的分布式锁**

## 3.2 分布式锁版本1 ##

### 3.2.1 业务场景 ###

*  场景分析  
    依赖分布式锁的机制, 某个用户操作Redis时对应的客户端宕机了, 且此时已经获取到锁, 导致锁一直被持有, 其他客户端拿不到锁, 这就是**死锁问题**, 如何解决呢?
    
    1.  由于锁操作由用户控制加锁解锁, 必定会存在加锁未解锁的风险
    2.  需要解锁操作不能仅依赖用户控制, 系统级别要给出对应的保底处理方案.
 *  解决方案
    
    1.  使用expire为锁key添加时间限定, 到时不释放锁, 则放弃锁.
        
            setnx lock-key 001 # 设置分布式锁
            expire lock-key second # 设置单位为秒
            pexpire lock-key milliseconds # 设置单位为毫秒
    2.  或者直接设置的时候添加时间限制
        
            set lock-key value NX PX 毫秒数 
            # 比如为key为name设置分布式锁
            set lock-name 001 NX PX 5000
        
        `value`可以是任意值  
        `NX`代码只有lock-key不存在时才设置值
 *  实际开发中如何知道设置多少时间合适.  
    由于操作通常都是微秒或毫秒级，因此该锁定时间不宜设置过大。具体时间需要业务测试后确认。  
    例如：持有锁的操作最长执行时间127ms，最短执行时间7ms。
    
    1.  测试百万次最长执行时间对应命令的最大耗时，测试百万次网络延迟平均耗时  
        锁
    2.  时间设定推荐：最大耗时\*120%+平均网络延迟\*110%
    3.  如果二者相差2个数量级，取其中单个耗时较长即可.

### 3.2.2 流程图 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70]

*  1、通过set命令设置锁
 *  2、判断返回结果是否是OK
    
     *  1）Nil，获取失败，结束或重试（自旋锁）
     *  2）OK，获取锁成功
        
         *  执行业务
         *  释放锁，DEL 删除key即可
 *  3、异常情况，服务宕机。超时时间EX结束，会自动释放锁

## 3.3 分布式锁版本2 ##

### 3.3.1 业务场景 ###

*  场景分析
    
    1.  三个进程：A和B和C，在执行任务，并争抢锁，此时A获取了锁，并设置自动过期时间为20ms
    2.  A开始执行业务，因为某种原因，业务阻塞，耗时超过了20ms，此时锁自动释放了.
    3.  B恰好此时开始尝试获取锁，因为锁已经自动释放，成功获取锁.
    4.  A此时业务执行完毕，执行释放锁逻辑（删除key），于是B的锁被释放了，而B其实还在执行业务.
    5.  此时进程C尝试获取锁，也成功了，因为A把B的锁删除了。
    
    问题(1)：使用版本1的分布式锁, 有可能B和C同时获取到锁，违反了锁只能被一个客户端持有的特性.  
    如何解决这个问题呢？我们应该在删除锁之前, 判断这个锁是否是自己设置的锁, 如果不是（例如自己的锁已经超时释放）, 那么就不要删除了.  
    问题(2)：**如何得知当前获取锁的是不是自己呢**？
 *  解决方案
    
    1.  我们可以在set 锁时，存入自己的信息！删除锁前, 判断下里面的值是不是与自己相等. 如果不等，就不要删除了.
    2.  这里自己的信息通常是一个随机值+当前线程的id, 通过`UUID.randomUUID().toString()+Thread.currentThread().getId()`获取到.

### 3.3.2 流程图 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 1]

*  1、通过set命令设置锁  
    id通常是一个随机值+当前线程的id.
 *  2、判断返回结果是否是OK
    
     *  1）Nil，获取失败，结束或重试（自旋锁）
     *  2）OK，获取锁成功
        
         *  执行业务
         *  `get lock`判断返回的id是否一致
            
             *  一致则释放锁，DEL 删除key即可
             *  不一致则不释放锁.
 *  3、异常情况，服务宕机。超时时间EX结束，会自动释放锁

## 3.4 分布式锁版本3 ##

### 3.4.1 业务场景 ###

*  场景分析  
    就是实际开发过程中, 一段代码内部会有嵌套方法, 外层方法获取到锁后, 内层再去获取时由于锁已经存在了就无法获取了, 但内层代码不执行完外层也释放不了锁啊, 这就是**方法嵌套导致的死锁问题**, 怎么解决呢?
 *  解决方案
    
    1.  让锁成为可重入锁, 也就是外层代码获取到这把锁, 内层代码可以获取到该锁.
    2.  获取时判断是不是自己的锁, 是则继续使用, 而且要记录重入的次数
    3.  这里的锁不能使用之前的String类型作为lock-key的值了, 锁的value要使用hash结构
        
            hset lock-key 线程信息, 重入次数(默认1) NX PX 毫秒数
        
        key: `lock-key`  
        value-key:`线程信息`  
        value-value:`重入次数`

### 3.4.2 流程图 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 2]  
下面我们假设锁的key为“lock”，hashKey是当前线程的id：“threadId”，锁自动释放时间假设为20

获取锁的步骤：

*  1、判断lock是否存在 `EXISTS lock`
    
     *  返回1则存在，说明有人获取锁了，下面判断是不是自己的锁
        
         *  判断当前线程id作为hashKey是否存在：`HEXISTS lock threadId`
            
             *  存在，说明是自己获取的锁，重入次数+1：`HINCRBY lock threadId 1`，去到步骤3
             *  不存在，说明锁已经有了，且不是自己获取的，锁获取失败，end
     *  2、返回0则不存在，说明可以获取锁，并存入value值`HSET key threadId 1`
     *  3、设置锁自动释放时间，`EXPIRE lock 20`

释放锁的步骤：

*  1、判断当前线程id作为hashKey是否存在：`HEXISTS lock threadId`
    
     *  存在，说明锁还在，重入次数减1：`HINCRBY lock threadId -1`，获取新的重入次数.
     *  不存在，说明锁已经失效，不用管了
 *  2、判断重入次数是否为0：
    
     *  为0，说明锁全部释放，删除key：`DEL lock`
     *  大于0，说明锁还在使用，重置有效时间：`EXPIRE lock 20`

## 3.5 集群模式的Redis分布式锁 ##

### 3.5.1 RedLock算法 ###

这个场景是假设有一个redis cluster，有5个redis master实例。然后执行如下步骤获取一把锁：

*  获取当前时间戳，单位是毫秒
 *  轮流尝试在每个master节点上创建锁，过期时间较短，一般就几十毫秒
 *  尝试在大多数节点上建立一个锁，比如5个节点就要求是3个节点（n / 2 +1）
 *  客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了
 *  要是锁建立失败了，那么就依次删除这个锁
 *  只要别人建立了一把分布式锁，你就得不断轮询去尝试获取锁

### 3.5.2 Redission ###

虽然我们已经实现了分布式锁，能够满足大多数情况下的需求，不过我们的代码并不是万无一失。  
某些场景下，可能需要实现分布式的不同类型锁，比如：公平锁、互斥锁、可重入锁、读写锁等等。实现起来比较麻烦。  
而开源框架Redission就帮我们实现了上述的这些 锁功能，而且还有很多其它的强大功能。  
**Redission流程图**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 3]

*  加锁机制: 如果某个客户端要加锁, 它面对的是Redis Cluster集群, 首先会根据hash节点选择一台机器.
 *  锁互斥机制: 这个时候如果客户端2来尝试家锁, 发现myLock这个锁Key已经存在了, 在Mylock这个锁key的剩余时间内, 客户端2会进入一个while循环, 不停的尝试加锁.
 *  watch dog自动延期机制: 客户端1一旦加锁成功, 就会启动一个watch dog看门够, 他是一个后台线程，会每隔10秒检查一下, 如果客户端1还持有锁key, 那么就会不断的延长锁key的生存时间.
 *  可重入加锁机制: 执行可重入锁,会对客户端1的加锁次数, 累加1.
 *  锁释放机制: 执行释放锁, 就会对和护短加锁次数减1. 如果发现锁此时是0, 就从Redis中删除这个key, 另外客户端2就可以尝试加锁了.

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70_pic_center]: /images/20221024/993eed44972b485eaa7ef64f5d163740.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70]: /images/20221024/a1f7cbb6cc1a4c3f82ff04d23165eece.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 1]: /images/20221024/cf18ea03e8db40e583420fd65154f279.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 2]: /images/20221024/c4d8658cfd4648128e846e52ad79bc74.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 3]: /images/20221024/1745bcbc822f4b5795404233380b233e.png