redis锁（redis锁并发问题）

本篇文章给大家谈谈redis锁，以及redis锁并发问题对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、大厂面试题详解：如何用Redis实现分布式锁？
• 2、不会还有人不知道吧？redis加锁的常见几种方式
• 3、redis 分布式锁
• 4、Redis红锁

大厂面试题详解：如何用Redis实现分布式锁？

说一道常见面试题：

一个很简单的答案就是去使用 Redission 客户端。Redission 中的锁方案就是 Redis 分布式锁得比较完美的详细方案。

那么，Redission 中的锁方案为什么会比较完美呢？

正好，我用 Redis 做分布式锁经验十分丰富，在实际工作中，也 探索 过许多种使用 Redis 做分布式锁的方案，经过了无数血泪教训。

所以，在谈及 Redission 锁为什么比较完美之前，先给大家看看我曾经使用 Redis 做分布式锁是遇到过的问题。

我曾经用 Redis 做分布式锁是想去解决一个用户抢优惠券的问题。这个业务需求是这样的：当用户领完一张优惠券后，优惠券的数量必须相应减一，如果优惠券抢光了，就不允许用户再抢了。

在实现时，先从数据库中先读出优惠券的数量进行判断，当优惠券大于 0，就进行允许领取优惠券，然后，再将优惠券数量减一后，写回数据库。

当时由于请求数量比较多，所以，我们使用了三台服务器去做分流。

这个时候会出现一个问题：

如果其中一台服务器上的 A 应用获取到了优惠券的数量之后，由于处理相关业务逻辑，未及时更新数据库的优惠券数量；在 A 应用处理业务逻辑的时候，另一台服务器上的 B 应用更新了优惠券数量。那么，等 A 应用去更新数据库中优惠券数量时，就会把 B 应用更新的优惠券数量覆盖掉。

看到这里，可能有人比较奇怪，为什么这里不直接使用 SQL：

原因是这样做，在没有分布式锁的协调下，优惠券数量可能直接会出现负数。因为当前优惠券数量为 1 的时候，如果两个用户通过两台服务器同时发起抢优惠券的请求，都满足优惠券大于 0 每个条件，然后都执行这条 SQL 说了句，结果优惠券数量直接变成 -1 了。

还有人说可以用乐观锁，比如使用如下 SQL:

这种方式就在一定几率下，很可能出现数据一直更新不上，导致长时间重试的情况。

所以，经过综合考虑，我们就采用了 Redis 分布式锁，通过互斥的方式，以防止多个客户端同时更新优惠券数量的方案。

当时，我们首先想到的就是使用 Redis 的 setnx 命令，setnx 命令其实就是 set if not exists 的简写。告则

当 key 设置值成功后，则返回 1，否则就返回 0。所以，这里 setnx 设置成功可以表示成获取到锁，如果失败，则说明已经有锁，可以被视作获取锁失败。

如果想要释放锁，执行任务 del 指令，把 key 删除即可。

利用这个特性，我们就可以让系统在返毁执行优惠券逻辑之前，先去 Redis 中执行 setnx 指令。再根漏友备据指令执行结果，去判断是否获取到锁。如果获取到了，就继续执行业务，执行完再使用 del 指令去释放锁。如果没有获取到，就等待一定时间，重新再去获取锁。

乍一看，这一切没什么问题，使用 setnx 指令确实起到了想要的互斥效果。

但是，这是建立在所有运行环境都是正常的情况下的。一旦运行环境出现了异常，问题就出现了。

想一下，持有锁的应用突然崩溃了，或者所在的服务器宕机了，会出现什么情况？

这会造成死锁——持有锁的应用无法释放锁，其他应用根本也没有机会再去获取锁了。这会造成巨大的线上事故，我们要改进方案，解决这个问题。

怎么解决呢？咱们可以看到，造成死锁的根源是，一旦持有锁的应用出现问题，就不会去释放锁。从这个方向思考，可以在 Redis 上给 key 一个过期时间。

这样的话，即使出现问题，key 也会在一段时间后释放，是不是就解决了这个问题呢？实际上，大家也确实是这么做的。

不过，由于 setnx 这个指令本身无法设置超时时间，所以一般会采用两种办法来做这件事：

1、采用 lua 脚本，在使用 setnx 指令之后，再使用 expire 命令去给 key 设置过期时间。

2、直接使用 set(key,value,NX,EX,timeout) 指令，同时设置锁和超时时间。

以上两种方法，使用哪种方式都可以。

释放锁的脚本两种方式都一样，直接调用 Redis 的 del 指令即可。

到目前为止，我们的锁既起到了互斥效果，又不会因为某些持有锁的系统出现问题，导致死锁了。这样就完美了吗？

假设有这样一种情况，如果一个持有锁的应用，其持有的时间超过了我们设定的超时时间会怎样呢？会出现两种情况：

出现第一种情况比较正常。因为你毕竟执行任务超时了，key 被正常清除也是符合逻辑的。

但是最可怕的是第二种情况，发现设置的 key 还存在。这说明什么？说明当前存在的 key，是另外的应用设置的。

这时候如果持有锁超时的应用调用 del 指令去删除锁时，就会把别人设置的锁误删除，这会直接导致系统业务出现问题。

所以，为了解决这个问题，我们需要继续对 Redis 脚本进行改动……毁灭吧，累了……

首先，我们要让应用在获取锁的时候，去设置一个只有应用自己知道的独一无二的值。

通过这个唯一值，系统在释放锁的时候，就能识别出这锁是不是自己设置的。如果是自己设置的，就释放锁，也就是删除 key；如果不是，则什么都不做。

脚本如下：

或者

这里，ARGV[1] 是一个可传入的参数变量，可以传入唯一值。比如一个只有自己知道的 UUID 的值，或者通过雪球算法，生成只有自己持有的唯一 ID。

释放锁的脚本改成这样：

可以看到，从业务角度，无论如何，我们的分布式锁已经可以满足真正的业务需求了。能互斥，不死锁，不会误删除别人的锁，只有自己上的锁，自己可以释放。

一切都是那么美好！！！

可惜，还有个隐患，我们并未排除。这个隐患就是 Redis 自身。

要知道，lua 脚本都是用在 Redis 的单例上的。一旦 Redis 本身出现了问题，我们的分布式锁就没法用了，分布式锁没法用，对业务的正常运行会造成重大影响，这是我们无法接受的。

所以，我们需要把 Redis 搞成高可用的。一般来讲，解决 Redis 高可用的问题，都是使用主从集群。

但是搞主从集群，又会引入新的问题。主要问题在于，Redis 的主从数据同步有延迟。这种延迟会产生一个边界条件：当主机上的 Redis 已经被人建好了锁，但是锁数据还未同步到从机时，主机宕了。随后，从机提升为主机，此时从机上是没有以前主机设置好的锁数据的——锁丢了……丢了……了……

到这里，终于可以介绍 Redission（开源 Redis 客户端）了，我们来看看它怎么是实现 Redis 分布式锁的。

Redission 实现分布式锁的思想很简单，无论是主从集群还是 Redis Cluster 集群，它会对集群中的每个 Redis，挨个去执行设置 Redis 锁的脚本，也就是集群中的每个 Redis 都会包含设置好的锁数据。

我们通过一个例子来介绍一下。

假设 Redis 集群有 5 台机器，同时根据评估，锁的超时时间设置成 10 秒比较合适。

第 1 步，咱们先算出集群总的等待时间，集群总的等待时间是 5 秒（锁的超时时间 10 秒 / 2）。

第 2 步，用 5 秒除以 5 台机器数量，结果是 1 秒。这个 1 秒是连接每台 Redis 可接受的等待时间。

第 3 步，依次连接 5 台 Redis，并执行 lua 脚本设置锁，然后再做判断：

再额外多说一句，在很多业务逻辑里，其实对锁的超时时间是没有需求的。

比如，凌晨批量执行处理的任务，可能需要分布式锁保证任务不会被重复执行。此时，任务要执行多长时间是不明确的。如果设置分布式锁的超时时间在这里，并没有太大意义。但是，不设置超时时间，又会引发死锁问题。

所以，解决这种问题的通用办法是，每个持有锁的客户端都启动一个后台线程，通过执行特定的 lua 脚本，去不断地刷新 Redis 中的 key 超时时间，使得在任务执行完成前，key 不会被清除掉。

脚本如下：

其中，ARGV[1] 是可传入的参数变量，表示持有锁的系统的唯一值，也就是只有持有锁的客户端才能刷新 key 的超时时间。

到此为止，一个完整的分布式锁才算实现完毕。总结实现方案如下：

这个分布式锁满足如下四个条件：

当然，在 Redission 中的脚本，为了保证锁的可重入，又对 lua 脚本做了一定的修改，现在把完整的 lua 脚本贴在下面。

获取锁的 lua 脚本：

对应的刷新锁超时时间的脚本：

对应的释放锁的脚本：

到现在为止，使用 Redis 作为分布式锁的详细方案就写完了。

我既写了一步一坑的坎坷经历，也写明了各个问题和解决问题的细节，希望大家看完能有所收获。

最后再给大家提个醒，使用 Redis 集群做分布式锁，有一定的争议性，还需要大家在实际用的时候，根据现实情况，做出更好的选择和取舍。

原文

不会还有人不知道吧？redis加锁的常见几种方式

redis加锁的常见几种方式，redis中加锁是比价誉野常见的操作，为了防止并发情况下产生的各种内存分配问题，而选择如何正确高效的加轮判锁，才是我们应该需要知道和了解的，常码字不易，出精品更难，没有特别幸运，那么请先特别努力，别因为懒惰而失败，还矫情地将原因归于自己倒霉。你必须庆桐喊特别努力，才能显得毫不费力

如果key不存在，则将key初始化为0，然后自增1

如何key不存在，则将key设置成value

同setnx加锁

[img]

redis 分布式锁

1、一个tomcat是一个进程，其中有很多线程（与有多少个app无关） 

2、一个tomcat启动一个JVM，其中可以有很多APP 

3、一个tomcat中部署的多个app，虽然同处一个JVM里，但是由于散源无法相互调用，所以也可以认为是分布式的 

synchronized 只是本地锁啊，锁的也只是当前jvm下的对象，在分布式场景下，要用分布式锁。

redis 分布式锁应用场景: 程序不是在一台tomcat(不同jvm)或者一台 tomcat部署的多个由于无法相互调用，synchronized失效，此时操作共享变备掘桐量，例如库存，就要用分布式锁仿坦

简陋版:

解决key 失效时间小于业务执行时间问题

//放到启动类

redisson底层主要是lua脚本

原理图：

解决key 失效时间小于业务执行时间问题

使用lua后的效果：

redis 集群，主redis挂了，此时还没同步到从redis,怎么办?

可以使用zookeeper,它会等 其他的zookeeper同步加速成功再返回成功

redis没办法100%解决这个问题，可以容忍，redis性能远高于zookeeper

解决

1.可以使用redlock(不推荐，不完善):2.使用redission

高并发分布式锁实现：

将数据在redis里分段减库存

Redis红锁

在算法的分布式版本中，我们假设我们有N个Redis主节点。这些节点是完全独立的，因此我们不使用复制或任何其他隐式协调系统。我们已经描述了如何在单个实例中安全地获取和释放锁。我们理所当然地认为，算法将使用此方法在单个实例中获取和释放锁。在我们的示例中，我们设置了 N=5，这是一个合理的值，因此我们需要在不同的计算机或虚拟机上运行 5 个 Redis 主节点，以确保它们以一种基本独立的方式失败。

为了获取锁，客户端执行以下操作：

该算法依赖于以下假设：虽然进程之间没有同步时钟，但每个进程中的本地时间以大致相同的速率更新，与锁的自动释放时间相比，误差幅度很小。这个假设与现实世界的计算机非常相似：每台计算机都有一个本地时钟，我们通常可以依靠不同的计算机来具有很小的时钟漂移。

在这一点上，我们需要更好地指定我们的互斥规则：只要持有锁的客户端在锁有效时间内（如步骤3中获得的那哗茄核样）终止其工作，减去一些时间（只需几毫秒，以补偿进程之间的时钟漂移），它才能得到保证。

本文包含有关需要绑定 时钟漂移 的类似系统的更多信息： Leases：分布式文件缓存一致性的高效容错机制 。

当客户端无法获取锁时，它应该在随机延迟后重试，以便尝试取消同步多个客户端，尝试同时获取同一资源的锁（这可能会导致没有人获胜的裂脑情况）。此外，客户端在大多数 Redis 实例中尝试获取锁的速度越快，裂脑情况的窗口就越小（并且需要重试），因此理想情况下，客户端应尝试使用多路复用同时将 SET 命令发送到 N 个实例。

值得强调的是，对于未能获取大多数锁的客户端来说，尽快释放（部分）获取的锁是多么重要，这样就不需要等待密钥到期才能再次获取锁（但是，如果发生网络分区并且客户端不再能够与 Redis 实例通信， 在等待密钥过期时需要支付可用性罚款）。

释放锁很简单，无论客户端是否认为它纳段能够成功锁定给定实例，都可以执行。

算法安全吗？让我们来看看在不同场景中会发生什么。

首先，我们假设客户端能够在大多数实例中获取锁。所有实例都将包含一个具有相同生存时间的密钥。但是，密钥是在不同的时间设置的，因此密钥也会在不同的时间过期。但是，如果在时间 T1（我们在联系第一台服务器之前采样之前采样的时间）将第一个键设置为最差，而在时间乱掘 T2（我们从最后一个服务器获得回复的时间）将最后一个键设置为最差，则我们确信集中第一个过期的密钥将至少存在 。所有其他密钥稍后将过期，因此我们确信至少这次将同时设置这些密钥。 MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT

在设置大多数密钥期间，另一个客户端将无法获取锁，因为如果 N/2+1 密钥已存在，则 N/2+1 SET NX 操作无法成功。因此，如果获得了锁，则不可能同时重新获得它（违反互斥属性）。

但是，我们还希望确保尝试同时获取锁的多个客户端无法同时成功。

如果客户端锁定大多数实例的时间接近或大于锁定最大有效时间（我们基本上用于 SET 的 TTL），它将认为锁定无效并将解锁实例，因此我们只需要考虑客户端能够在小于有效时间的时间内锁定大多数实例的情况。在这种情况下，对于上面已经表达的参数，因为任何客户端都不应该能够重新获取锁。因此，仅当锁定大多数实例的时间大于 TTL 时间时，多个客户端才能同时锁定 N/2+1 个实例（“时间”是步骤 2 的结束），从而使锁定无效。 MIN_VALIDITY

系统活动性基于三个主要功能：

但是，我们支付的可用性损失等于网络分区上的 TTL 时间，因此，如果有连续分区，我们可以无限期地支付此罚款。每次客户端获取锁并在能够删除锁之前进行分区时，都会发生这种情况。

基本上，如果存在无限连续的网络分区，则系统可能会在无限长的时间内变得不可用。

许多使用 Redis 作为锁服务器的用户在获取和释放锁的延迟以及每秒可以执行的获取/释放操作数方面都需要高性能。为了满足这一要求，与N Redis服务器对话以减少延迟的策略肯定是多路复用（将套接字置于非阻塞模式，发送所有命令，稍后读取所有命令，假设客户端和每个实例之间的RTT相似）。

但是，如果我们想以崩溃恢复系统模型为目标，则关于持久性还有另一个考虑因素。

基本上，为了看到这里的问题，让我们假设我们配置Redis时根本没有持久性。客户端在 5 个实例中的 3 个实例中获取锁。客户端能够获取锁的其中一个实例重新启动，此时我们可以为同一资源锁定3个实例，而另一个客户端可以再次锁定它，这违反了锁的独占性的安全属性。

如果我们启用AOF持久性，事情将会有所改善。例如，我们可以通过向服务器发送 SHUTDOWN 命令并重新启动它来升级服务器。由于 Redis 过期在语义上是实现的，因此当服务器关闭时，时间仍然会过去，因此我们所有的要求都很好。但是，只要它是干净关闭，一切都很好。停电怎么办？如果 Redis 配置为（默认情况下）每秒在磁盘上同步一次，则重新启动后，我们的密钥可能会丢失。从理论上讲，如果我们想在面对任何类型的实例重启时保证锁定安全，我们需要在持久性设置中启用。由于额外的同步开销，这将影响性能。 fsync=always

然而，事情比乍一看要好。基本上，只要实例在崩溃后重新启动，它就不再参与任何 当前活动的 锁定，算法安全性就会保留。这意味着实例重新启动时的当前活动锁定集都是通过锁定重新加入系统的实例以外的实例而获得的。

为了保证这一点，我们只需要在崩溃后使一个实例不可用，至少比我们使用的最大 TTL 多一点。这是实例崩溃时存在的有关锁的所有密钥变得无效并自动释放所需的时间。

使用 延迟重启 ，即使没有任何可用的Redis持久性，基本上也可以实现安全，但请注意，这可能会转化为可用性损失。例如，如果大多数实例崩溃，系统将全局不可用 TTL （此处全局意味着在此期间根本没有资源可锁定）。

如果客户端执行的工作由小步骤组成，则默认情况下可以使用较小的锁定有效期，并扩展实现锁定扩展机制的算法。基本上，如果客户端在计算过程中锁定有效性接近较低值，则可以通过将Lua脚本发送到所有实例来扩展锁定，该实例扩展密钥的TTL（如果密钥存在并且其值仍然是客户端在获取锁定时分配的随机值）。

只有当客户端能够将锁扩展到大多数实例中，并且在有效时间内（基本上要使用的算法与获取锁时使用的算法非常相似），才应考虑重新获取锁。

但是，这在技术上不会更改算法，因此应限制锁定重新获取尝试的最大次数，否则会违反其中一个活动属性。

关于redis锁和redis锁并发问题的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。