redis分布式（redis分布式锁可能出现的问题）

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

本文目录一览：

• 1、Redis 分布式锁详细分析
• 2、redis 分布式锁
• 3、redis是分布式的吗
• 4、如何使用redis实现分布式锁功能？
• 5、Redis分布式缓存搭建

Redis 分布式锁详细分析

锁的作用，我想大家都理解，就是让不同的线程或者进程可以安全地操作共享资源，而不会产生冲突。

比较熟悉的就是 Synchronized 和缓汪戚 ReentrantLock 等，这些可以保证同一个 jvm 程序中，不同线程安全操作共享资源。

但是在分布式系统中，这种方式就失效了；由于分布式系统多线程、多进程并且分布在不同机器上，这将使单机并发控制锁策略失效，为了解决这个问题就需要一种跨 JVM 的互斥机制来控制共享资源的访问。

比较常用的分布式锁有三种实现方式：

本篇文章主要讲解基于 Redis 分布式锁的实现。

分布式锁最主要的作用就是保证任意一个时刻，只有一个客户端能访问共享资源。

我们知道 redis 有 SET key value NX 命令，仅在不存在 key 的时候才能被执行成功，保证多个客户端只有一个能执行成功，相当于获取锁。

释放锁的时候，只需要删除 del key 这个 key 就行了。

上面的实现看似已经满足要求了，但是忘了考虑在分布式环境下，有以下问题：

最大的问题就是因为客户端或者网络问题，导致 redis 中的 key 没有删除，锁无法释放，因此其他客户端无法获取到锁。

针对上面的情况，使用了下面命令:

使用 PX 的命令，给 key 添加一个自动过期时间(30秒)，保证即使因为意外情况，没有调用释放锁的方法，锁也会自动释放，其他客户端仍然可以获取到锁。

注意给这个 key 设置的值 my_random_value 是一个随机值，而且必须保证这个值在客户端必须是唯一的。这个值的作用是为了更加安全地释放锁。

这是为了避免删除其他客户端成功获取的锁。考虑下面情况：

因此这里使用一个 my_random_value 随机值，保证客户端只会释放自己获取的锁，即只删除自己设置的 key 。

这种实现方式，存在下面问题：

上面章节介绍了，简单实现存在的问题，下面来介绍一下 Redisson 实现又是怎么解决的这些问题的。

主要关陵稿注 tryAcquireOnceAsync 方法，有三个参数:

方法主要流程:

这个方法的流程与 tryLock(long waitTime, long leaseTime, TimeUnit unit) 方法基本相同。

这个方法与 tryAcquireOnceAsync 方法的区别，就是一个获取锁过期时间，一个是能否获取锁。即 获取锁过期扰陵时间 为 null 表示获取到锁，其他表示没有获取到锁。

获取锁最终都会调用这个方法，通过 lua 脚本与 redis 进行交互，来实现分布式锁。

首先分析，传给 lua 脚本的参数：

lua 脚本的流程:

为了实现无限制持有锁，那么就需要定时刷新锁的过期时间。

这个类最重要的是两个成员属性：

使用一个静态并发集合 EXPIRATION_RENEWAL_MAP 来存储所有锁对应的 ExpirationEntry ，当有新的 ExpirationEntry 并存入到 EXPIRATION_RENEWAL_MAP 集合中时，需要调用 renewExpiration 方法，来刷新过期时间。

创建一个超时任务 Timeout task ，超时时间是 internalLockLeaseTime / 3 , 过了这个时间，即调用 renewExpirationAsync(threadId) 方法，来刷新锁的过期时间。

判断如果是当前线程持有的锁，那么就重新设置过期时间，并返回 1 即 true 。否则返回 0 即 false 。

通过调用 unlockInnerAsync(threadId) 来删除 redis 中的 key 来释放锁。特别注意一点，当不是持有锁的线程释放锁时引起的失败，不需要调用 cancelExpirationRenewal 方法，取消定时，因为锁还是被其他线程持有。

传给这个 lua 脚本的值：

这个 lua 脚本的流程：

调用了 LockPubSub 的 subscribe 进行订阅。

这个方法的作用就是向 redis 发起订阅，但是对于同一个锁的同一个客户端(即 一个 jvm 系统) 只会发起一次订阅，同一个客户端的其他等待同一个锁的线程会记录在 RedissonLockEntry 中。

方法流程：

只有当 counter = permits 的时候，回调 listener 才会运行，起到控制 listener 运行的效果。

释放一个控制量，让其中一个回调 listener 能够运行。

主要属性：

这个过程对应的 redis 中监控的命令日志:

因为看门狗的默认时间是 30 秒，而定时刷新程序的时间是看门狗时间的 1/3 即 10 秒钟，示例程序休眠了 15 秒，导致触发了刷新锁的过期时间操作。

注意 rLock.tryLock(10, TimeUnit.SECONDS); 时间要设置大一点，如果等待时间太短，小于获取锁 redis 命令的时间，那么就直接返回获取锁失败了。

分析源码我们了解 Redisson 模式的分布式，解决了锁过期时间和可重入的问题。但是针对 redis 本身可能存在的单点失败问题，其实是没有解决的。

基于这个问题， redis 作者提出了一种叫做 Redlock 算法, 但是这种算法本身也是有点问题的，想了解更多，请看 基于Redis的分布式锁到底安全吗?

[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是分布式的吗

是的

日常开发中，总会接触到一些好玩的东西，比如这篇的redis，一说到redis，可能就有人跟memcache做比较了，是呀，

memcache只能说是简单的kv内存数据结构,而redis支持的数据类型就丰富多了，当然最能让人看上眼的就是SortedSet。

有了它，我们就可以玩一些“贪心”的问题，比如适合“贪心”的优先队列，说到优先队列，我们以前实现了仅仅是内存形式的，

哎，内存毕竟是内存，当有海量数据的时候，最好能有一个序列化到硬盘的操作。。。恰恰这个场景redis就可以办到。。。

一：快速搭建

好了，我们知道redis比较适合做的事情了，现在我们可以进行快速搭建。

第一步：下载redis-2.0.2.zip (32 bit)。然后改名为redis放在D盘中。

最重要的也就丛闭升是下面两个：

redis-server.exe：        这个就是redis的服务端程序。

redis-cli.exe：             服务端开启后，我们的客户端就可以输入各种命令测试了。

从图中我们可以看到两点：

①：没有指定config file。

原来redis建议我们做一个配置文件，那我就搞段配置。

daemonize:  是否以“守护进程”的方式开启，当是守护进程的时候就不受控制台的影响了。

logfile:         log文件位置。

database:    开启数据库的个数。

dbfilename:  数据快照文件名。

save * *:     保存快照的频率，第一个为时间，第二个为写操作。

将这些配置好后，我们再看看：

②：我们看到redis默认的开放端口为6379。

二：安装驱动

好了，redis已经搭建完毕了，现在我们就要用C#去操作redis，这也是我最渴望的功能，优先队列~，先下载C#驱动，

就可以看到如下3个dll。

最后我们做下小测试：

1     class Program 2     { 3         static void Main(string[] args) 4         { 5             var client = new RedisClient("127.0.0.1", 6379); 6  7             //最后一个参数为我们排序的依据 8             var s = client.AddItemToSortedSet("12", "百度", 400); 9 10             client.AddItemToSortedSet("12", "谷歌", 300);11             client.AddItemToSortedSet("12", "阿里", 200);12             client.AddItemToSortedSet("12", "新浪", 100);13             client.AddItemToSortedSet("12", "人人", 500);14 15             //升序获取最一个值:"新浪"16             var list = client.GetRangeFromSortedSet("12", 0, 0);17 18             foreach (var item in list)19         渗老    {20                 Console.WriteLine(item);21             }22 23             //降序获取最一个值:"人人"24             list = client.GetRangeFromSortedSetDesc("12", 0, 0);25 26             foreach (var item in list)27             {28       态铅          Console.WriteLine(item);29             }30 31             Console.Read();32         }33     }

AddItemToSortedSet： 第三个参数也就是我们要排序的依据，这也非常适合我们做topK的问题，非常爽~

如何使用redis实现分布式锁功能？

由于redis是单线程的且性能很快，所以比较适合做全局分布式锁。

基本流程就是在操作可能某个全局冲突资源的时候，使用一个全局唯一key来判断是否有其腔谨他线程占用了资源，如果有其他线程占用，则报错退出或者循环等待。如果没有其他线程占用，则就可以通过添加分布式锁来占用这个资源，然后再执行后续的任务，在任务执行完成之后，再释放分布式锁，其他线程就可以继续使用这个资源了。

那么通过redis加锁的动作是什么呢？

简单加锁命令：

命令是：setnx

内部的实现机制就是判断这个key位置是不是有数据，没有数据就设置成value返回，有数据就返回一个特殊数值。

但是这里有一个问题是，如果占用资源的线程错误退出了，没有来得及释放分布式锁，这个锁就被永远的占用了

改进版的加锁：

命令是：1. setnx 2. expire

添加分布式锁的同时，添加一个锁锁过期的时间。这样，当加锁线程退出之后，至少等一段时间之后，锁是有机会释放掉的。

这里有一个小问题是，这两个命令是分开执行的，不是原子操作。那么就存在理论上来说，第一个命令执行完之后，就出现错误，来不及执行expire命令的可能，一种办法是自己写lua脚本，可以实现多条命令的原子化执行。一种办法是引用一些开源库。在2.8版本之后，redis为了解决这个问题，提供了官方版的解法，就是命令：set key value nx expireTimeNum ex，将上述两个命令合并成了一个命令。

有了过期时间之后解决了一部分问题，但是也有可能出现锁都过期了，但是中间执行的任务还没有结束，第一个线程还在执行了，第二个线程已经拿到锁开始执行了，那么这时候第一个线程如果执行完成之后，那么就会将第二个线程的锁释放掉了。第二个线程释放锁的时候，要不然出错，要不然是释放的其他线程的锁，这样也会和预期不符。

如果单纯地要解决这个问题的话，可以在设置value的时候使用一个随机数，释放锁的时候，先判断这个随机数是否一致，如果一致再删除锁，否则就退出。但是判断value和删除key也不是一个原子操作，这时候就需要使用lua脚本了。

上面的方案依然不能解决超时释放的问题，依然违背分布式锁的初衷。怎么办了？

解题思路是另外启动一个线程，它的任务就是每隔一段时间判断一下如果发现当前线程的任务快过期了还没有完成，则定雹圆芦期给当前线程的锁续个期。

有个开源库解决了这个问题，它大概率会比你实现得更好一些。这个库就是redisson，非常好记，就是redis的儿子son，连起来就是reidsson，虽然可能不是亲的，但是也足够了。

这个库里面有一个组件是watchdog，直译过来就是看门狗，它的作用就是每隔一段时间判断的。

再继续思考，还有一个更极端的问题是，redis如果是单节点的，它宕机了；或者是主备节点的，但是备份节点还没有来得及同步主节点的数据，主节点拿到锁之后，在同步数据之前就马上宕机了，则也有可能出现锁不住的问题。如果认为这是一个问题，想要解决这个问题，这个问题怎么解决了？

思路是在加锁的时候多加锁几台redis服务器，通常情况下redis部源带署的时候是2n+1台，那么在加锁的时候需要保证过半数服务器加锁成功了，也就是说n+1台服务器。这时候除非整个集群都不可用了，则这个安全性将大幅度提升。

这个问题也有开源库解决了，就是redis红锁。

下一个问题是分布式锁可以重入么？

如果想要实现可重入的分布式锁的话，需要在设置value的时候加上线程信息和加锁次数的信息。但是这是简单的思路，如果加上过期时间等问题之后，可重入锁就可能比较复杂了。

Redis分布式缓存搭建

花了两天时间整理了之前记录的Redis单体与哨兵模式的搭建与使用，又补齐了集群模式的使用和搭建经验，并对集群的一些个原理做了理解。

笔者安装中遇到的一些问题：

如果make报错，可能是没装gcc或者gcc++编辑器，安装之 yum -y install gcc gcc-c++ kernel-devel ，有可能还是提示一些个c文件编译不过，gcc -v查看下版本，如果不到5.3那么升级一下gcc：

在 /etc/profile 追加一行 source /opt/rh/devtoolset-9/enable

scl enable devtoolset-9 bash

重新make clean, make

这回编译通态纳哪过了，提示让你最好make test一下/

执行make test ，如果提示 You need tcl 8.5 or newer in order to run the Redis test

那就升级tcl， yum install tcl

重新make test，如果还有error就删了目录，重新tar包解压重新make , make test

\o/ All tests passed without errors! ，表示编译成功。

然后make install即可。

直接运行命令： ./redis-server /usr/redis-6.0.3/redis.conf

redis.conf 配置文件里帆码 bind 0.0.0.0 设置外部访问， requirepass xxxx 设置密码。

redis高可用方案有两种：

常用搭建方案为1主1从或1主2从+3哨兵监控主节点， 以及3主3从6节点集群。

（1）sentinel哨兵

/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf

sentinel2.conf配置：

坑1：master节点也会在故障转移后成为从节点，也需要配置masterauth

当kill master进程之后，经过sentinel选举，slave成为了新的master，再次启动原master，提示如下错误：

原因是此时的master再次启动已经是slave了，需要向现在的新master输入密码，所以需要在master.conf

中配置：

坑2：哨兵配置文件要暴露客户端可以访问到的master地址

在 sentinel.conf 配置文件的 sentinel monitor mymaster 122.xx.xxx.xxx 6379 2 中，配置该哨兵对应的master名字、master地址和端口，以及达到多少个哨兵选举通过认为master挂掉。其中master地址要站在redis访问者（也就是客户端）的角度、配置茄稿访问者能访问的地址，例如sentinel与master在一台服务器（122.xx.xxx.xxx）上，那么相对sentinel其master在本机也就是127.0.0.1上，这样 sentinel monitor mymaster 127.0.0.1 6379 2 逻辑上没有问题，但是如果另外服务器上的springboot通过lettuce访问这个redis哨兵，则得到的master地址为127.0.0.1，也就是springboot所在服务器本机，这显然就有问题了。

附springboot2.1 redis哨兵配置：

坑3：要注意配置文件.conf会被哨兵修改

redis-cli -h localhost -p 26379 ，可以登到sentinel上用info命令查看一下哨兵的信息。

曾经遇到过这样一个问题，大致的信息如下

slaves莫名其妙多了一个，master的地址也明明改了真实对外的地址，这里又变成127.0.0.1 !

最后，把5个redis进程都停掉，逐个检查配置文件，发现redis的配置文件在主从哨兵模式会被修改，master的配置文件最后边莫名其妙多了一行replicaof 127.0.0.1 7001， 怀疑应该是之前配置错误的时候（见坑2）被哨兵动态加上去的！ 总之，实践中一定要多注意配置文件的变化。

（2）集群

当数据量大到一定程度，比如几十上百G，哨兵模式不够用了需要做水平拆分，早些年是使用codis，twemproxy这些第三方中间件来做分片的，即 客户端 - 中间件 - Redis server 这样的模式，中间件使用一致性Hash算法来确定key在哪个分片上。后来Redis官方提供了方案，大家就都采用官方的Redis Cluster方案了。

Redis Cluster从逻辑上分16384个hash slot，分片算法是 CRC16(key) mod 16384 得到key应该对应哪个slot，据此判断这个slot属于哪个节点。

每个节点可以设置1或多个从节点，常用的是3主节点3从节点的方案。

reshard，重新分片，可以指定从哪几个节点移动一些hash槽到另一个节点去。重新分片的过程对客户端透明，不影响线上业务。

搭建Redis cluster

redis.conf文件关键的几个配置：

启动6个集群节点

[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis

root 5508 1 0 21:25 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7001 [cluster]

root 6903 1 0 21:32 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [cluster]

root 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [cluster]

root 6966 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [cluster]

root 6993 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [cluster]

root 7015 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7006 [cluster]

这时候这6个节点还是独立的，要把他们配置成集群：

说明： -a xxxx 是因为笔者在redis.conf中配置了requirepass xxxx密码，然后 --cluster-replicas 1 中的1表示每个master节点有1个从节点。

上述命令执行完以后会有一个询问： Can I set the above configuration? yes同意自动做好的分片即可。

最后 All 16384 slots covered. 表示集群中16384个slot中的每一个都有至少有1个master节点在处理，集群启动成功。

查看集群状态：

坑1：暴露给客户端的节点地址不对

使用lettuce连接发现连不上，查看日志 Connection refused: no further information: /127.0.0.1:7002 ，跟之前哨兵配置文件sentinel.conf里边配置master地址犯的错误一样，集群启动的时候带的地址应该是提供给客户端访问的地址。

我们要重建集群：先把6个redis进程停掉，然后删除 nodes-7001.conf 这些节点配置文件，删除持久化文件 dump.rdb 、 appendonly.aof ，重新启动6个进程，在重新建立集群：

然后，还是连不上，这次报错 connection timed out: /172.xx.0.xx:7004 ，发现连到企鹅云服务器的内网地址上了！

解决办法，修改每个节点的redis.conf配置文件，找到如下说明：

所以增加配置：

然后再重新构建集群，停进程、改配置、删除节点文件和持久化文件、启动进程、配置集群。。。再来一套（累死了）

重新使用Lettuce测试，这次终于连上了！

坑2：Lettuce客户端在master节点故障时没有自动切换到从节点

name这个key在7002上，kill这个进程模拟master下线，然后Lettuce一直重连。我们期望的是应该能自动切换到其slave 7006上去，如下图：

重新启动7002进程，

7006已成为新master，7002成为它的slave，然后Lettuce也能连接上了。

解决办法，修改Lettuce的配置：

笔者用的是springboot 2.1 spring-boot-starter-data-redis 默认的Lettuce客户端，当使用Redis cluster集群模式时，需要配置一下 RedisConnectionFactory 开启自适应刷新来做故障转移时的自动切换从节点进行连接。

重新测试：停掉master 7006，这次Lettuce可以正常切换连到7002slave上去了。（仍然会不断的在日志里报连接错误，因为需要一直尝试重连7006，但因为有7002从节点顶上了、所以应用是可以正常使用的）

Redis不保证数据的强一致性

Redis并不保证数据的强一致性，也就是取CAP定理中的AP

关于一致性Hash算法，可以参考 一致性Hash算法 - (jianshu.com)

Redis cluster使用的是hash slot算法，跟一致性Hash算法不太一样，固定16384个hash槽，然后计算key落在哪个slot里边（计算key的CRC16值再对16384取模），key找的是slot而不是节点，而slot与节点的对应关系可以通过reshard改变并通过gossip协议扩散到集群中的每一个节点、进而可以为客户端获知，这样key的节点寻址就跟具体的节点个数没关系了。也同样解决了普通hash取模算法当节点个数发生变化时，大量key对应的寻址都发生改动导致缓存失效的问题。

比如集群增加了1个节点，这时候如果不做任何操作，那么新增加的这个节点上是没有slot的，所有slot都在原来的节点上且对应关系不变、所以没有因为节点个数变动而缓存失效，当reshard一部分slot到新节点后，客户端获取到新迁移的这部分slot与新节点的对应关系、寻址到新节点，而没迁移的slot仍然寻址到原来的节点。

关于热迁移，猜想，内部应该是先做复制迁移，等迁移完了，再切换slot与节点的对应关系，复制没有完成之前仍按照原来的slot与节点对应关系去原节点访问。复制结束之后，再删除原节点上已经迁移的slot所对应的key。

与哨兵模式比较类似，当1个节点发现某个master节点故障了、会对这个故障节点进行pfail主观宕机，然后会通过gossip协议通知到集群中的其他节点、其他节点也执行判断pfail并gossip扩散广播这一过程，当超过半数节点pfail时那么故障节点就是fail客观宕机。接下来所有的master节点会在故障节点的从节点中选出一个新的主节点，此时所有的master节点中超过半数的都投票选举了故障节点的某个从节点，那么这个从节点当选新的master节点。

所有节点都持有元数据，节点之间通过gossip这种二进制协议进行通信、发送自己的元数据信息给其他节点、故障检测、集群配置更新、故障转移授权等等。

这种去中心化的分布式节点之间内部协调，包括故障识别、故障转移、选主等等，核心在于gossip扩散协议，能够支撑这样的广播协议在于所有的节点都持有一份完整的集群元数据，即所有的节点都知悉当前集群全局的情况。

Redis高可用方案 - (jianshu.com)

面试题:Redis 集群模式的工作原理能说一下么 - 云+社区 - 腾讯云 (tencent.com)

深度图解Redis Cluster原理 - detectiveHLH - 博客园 (cnblogs.com)

Redis学习笔记之集群重启和遇到的坑-阿里云开发者社区 (aliyun.com)

云服务器Redis集群部署及客户端通过公网IP连接问题

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