Redis 分布式锁|从青铜到钻石的五种演进方案

Redis 分布式锁|从青铜到钻石的五种演进方案

一、本地锁的问题

首先我们来回顾下本地锁的问题:

目前题目微服务被拆分成了四个微服务。前端请求进来时,会被转发到不同的微服务。假如前端接收了 10 W 个请求,每个微服务接收 2.5 W 个请求,假如缓存失效了,每个微服务在访问数据库时加锁,通过锁(synchronziedlock)来锁住自己的线程资源,从而防止缓存击穿

这是一种本地加锁的方式,在分布式情况下会带来数据不一致的问题:比如服务 A 获取数据后,更新缓存 key =100,服务 B 不受服务 A 的锁限制,并发去更新缓存 key = 99,最后的结果可能是 99 或 100,但这是一种未知的状态,与期望结果不一致。流程图如下所示:

Redis 分布式锁|从青铜到钻石的五种演进方案

二、什么是分布式锁

基于上面本地锁的问题,我们需要一种支持分布式集群环境下的锁:查询 DB 时,只有一个线程能访问,其他线程都需要等待第一个线程释放锁资源后,才能继续执行。

生活中的案例:可以把锁看成房门外的一把,所有并发线程比作,他们都想进入房间,房间内只能有一个人进入。当有人进入后,将门反锁,其他人必须等待,直到进去的人出来。

Redis 分布式锁|从青铜到钻石的五种演进方案

我们来看下分布式锁的基本原理,如下图所示:

Redis 分布式锁|从青铜到钻石的五种演进方案

我们来分析下上图的分布式锁:

  • 1.前端将 10W 的高并发请求转发给四个题目微服务。
  • 2.每个微服务处理 2.5 W 个请求。
  • 3.每个处理请求的线程在执行业务之前,需要先抢占锁。可以理解为“占坑”。
  • 4.获取到锁的线程在执行完业务后,释放锁。可以理解为“释放坑位”。
  • 5.未获取到的线程需要等待锁释放。
  • 6.释放锁后,其他线程抢占锁。
  • 7.重复执行步骤 4、5、6。

大白话解释:所有请求的线程都去同一个地方“占坑”,如果有坑位,就执行业务逻辑,没有坑位,就需要其他线程释放“坑位”。这个坑位是所有线程可见的,可以把这个坑位放到 Redis 缓存或者数据库,这篇讲的就是如何用 Redis 做“分布式坑位”

三、Redis 的 SETNX

Redis 作为一个公共可访问的地方,正好可以作为“占坑”的地方。

用 Redis 实现分布式锁的几种方案,我们都是用 SETNX 命令(设置 key 等于某 value)。只是高阶方案传的参数个数不一样,以及考虑了异常情况。

我们来看下这个命令,SETNXset If not exist的简写。意思就是当 key 不存在时,设置 key 的值,存在时,什么都不做。

在 Redis 命令行中是这样执行的:

set NX登录后复制

先进入容器:

docker exec -it redis-cli登录后复制

set wukong 1111 NX登录后复制

Redis 分布式锁|从青铜到钻石的五种演进方案

四、青铜方案

我们先用 Redis 的 SETNX 命令来实现最简单的分布式锁。

3.1 青铜原理

我们来看下流程图:

Redis 分布式锁|从青铜到钻石的五种演进方案

  • 多个并发线程都去 Redis 中申请锁,也就是执行 setnx 命令,假设线程 A 执行成功,说明当前线程 A 获得了。
  • 其他线程执行 setnx 命令都会是失败的,所以需要等待线程 A 释放锁。
  • 线程 A 执行完自己的业务后,删除锁。
  • 其他线程继续抢占锁,也就是执行 setnx 命令。因为线程 A 已经删除了锁,所以又有其他线程可以抢占到锁了。
  • 10 秒以后,A 还在执行任务,此时锁被自动打开了。
  • 因房间内只允许一个用户执行任务,所以用户 A 和 用户 B 执行任务产生了冲突
  • 用户 A 在 15 s 后,完成了任务,此时 用户 B 还在执行任务。
  • 用户 A 主动打开了编号为 123的锁。
  • 用户 B 还在执行任务,发现锁已经被打开了。
  • 用户 B 非常生气:我还没执行完任务呢,锁怎么开了?
  • 用户 C 抢占到锁,C 开始执行任务。
  • 因房间内只允许一个用户执行任务,所以用户 B 和 用户 C 执行任务产生了冲突。
  • 主动删除锁的时候,需要判断锁的编号是否和设置的一致,如果一致,则认为是自己设置的锁,可以进行主动删除。
  • 2.抢占锁,并设置过期时间为 10 s,且锁具有随机唯一 id。
  • 3.抢占成功,执行业务。
  • 4.执行完业务后,获取当前锁的值。
  • 5.如果锁的值和设置的值相等,则清理自己的锁。
  • 时刻:9.5s。线程 A 向 Redis 查询当前 key 的值。

  • 时刻:10s。锁自动过期。

  • 时刻:11s。线程 B 抢占到锁。

  • 时刻:12s。线程 A 在查询途中耗时长,终于拿多锁的值。

  • 时刻:13s。线程 A 还是拿自己设置的锁的值和返回的值进行比较,值是相等的,清理锁,但是这个锁其实是线程 B 抢占的锁。

  • 改进:设置锁的自动过期时间,过一段时间后,自动删除锁,这样其他线程就能获取到锁了。
  • 改进:占锁和设置锁过期时间保证原子操作。
  • 改进:每次占用的锁,随机设为较大的值,主动删除锁时,比较锁的值和自己设置的值是否相等。
  • 改进:使用 Lua 脚本进行获取锁、比较锁、删除锁的原子操作。
  • 改进:Redission 分布式锁。