redis 允许别的服务器请求自己怎么配置 redis支持服务器锁定

转载

时光机3号 2024-06-24 09:02:01

文章标签 redis 分布式 Redisson jedis 分布式锁 文章分类 Redis 数据库

1.redis锁前世即基于单Redis节点的分布式锁，诸如setkey value px milliseconds nx

前世者，必将经历种种磨砺，才能稍微符合一些主流。推荐自测非常好用的redis工具（http://try.redis.io/）

第一劫：
dos命令版本
1)setnx job "hello"
如果当前job存在，则返回0表明赋值不成功。
如果当前job不存在，则返回1，表明赋值成功。
2)del job
单独删除操作命令
Java代码版本
1）redisCacheTemplate.opsForValue().set("key","123");（springboot+Redis）
如果当前key存在则覆盖，不存在则继续添加
2）redisCacheTemplate.delete("key");
删除存在的key操作
劫语：无论是dos命令操作，还是通过Java代码实现都不难发现，一个线程占用当前资源时候，如果请求执行因为某些原因意外推出了，导致独占的锁一直没有释放，那么这个锁将一直存在。以至于以后缓存得不到任何的更新。

第二劫：
劫语应对：既然占有的锁一直释放不了，我们可以通过锁添加失效时间
Java命令版本
1）redisCacheTemplate.opsForValue().setIfAbsent("key",UUID.randomUUID());
（redis封装的函数setIfAbsent(),追踪至底层代码，实际就是connection.setNX(rawKey, rawValue)一个原子性操作）
如果当前key存在，则赋值不成功，如果不存在的话，则赋值成功
2）redisCacheTemplate.expire("key",60,TimeUnit.SECONDS);
并且给当前锁设置失效时间.设置超时时间需要合理评估，过长或者过短都是问题。
劫语：有效的锁定了key，并且设置了失效时间，但是setnx方法只能由一个线程占有，如果其中执行逻辑比较缓慢，缓慢到超过设置的失效时间，另外一个线程获取key，执行到中间执行逻辑代码，出现冲突。

第三劫：
劫语应对：既然出现了由于中间逻辑执行缓慢情况，可以通过LUA脚本来加长当前key失效时间。
LUA脚本
1）伪代码
if redis.call("get",KEYS[1]) == ARGV[1] then
redis.call("set",KEYS[1],ex=3000)
else
getDLock();
如果获取当前锁还没失效，则增加当前锁失效时间，如果已经失效，则重新获取锁
劫语：就目前情况依旧不能解决两个线程同时操作独占资源情况。

第四劫：（普遍单机操作应用方法setkey value px milliseconds）
劫语应对：既然占有锁和锁添加超时时间，会存在一个执行，一个没有执行情况。我们就把他们封装城一个事务操作处理。
dos命令版本
1)setex mykey 60 redis
如果当前mykey没有值，则赋值redis,并且声明超时时间为60s（单位为second）
2）setex mykey 60 java(报错)
如果当前mykey存在值，并且没有超过超时时间，则赋值失败。
3）setex mykey 60 cainiao(返回1)
如果当前mykey存在值，并且超时时间已过，则赋值成功。
java命令版本
目前redis操作jar包中，已经对获取key值，还有设置失效方法封装成一个操作。
1）redisCacheTemplate.opsForValue().set("key", UUID.randomUUID(),60,TimeUnit.SECONDS);
追踪其底层代码，你就会发现，其实就是原子性操作
connection.setEx(rawKey, TimeoutUtils.toSeconds(timeout, unit), rawValue);
劫语：当单机REDIS服务停用，当前分布式锁方案仍旧存在问题。

第五劫：（普遍单机操作应用方法setNX+LUA（释放锁））
java命令版本
1)setnx方式获取锁，并且设置超时时间
public static boolean lock(String key,String uuid,int expire){
if(null == key){
return false;
}
try {
Jedis jedis = getJedisPool().getResource();
String res = jedis.set(key,uuid,"NX","EX",expire);
jedis.close();
return res!=null && res.equals("OK");
} catch (Exception e) {
return false;
}
}
需要注意事项：uuid值，需要唯一标识。否则会导致 “信号错误”，释放了不该释放的锁
A----->获取锁，占用资源 B-------->尝试获取失败，继续尝试
A----->执行公共资源(未执行完)，锁失效 B-------->尝试获取锁成功，执行公共资源
A----->执行完成，释放锁（A B锁一起释放）B-------->B还没操作成功

2）LUA释放锁结构，需要判断当前锁，是否为需要释放的锁，这就是为何声明锁唯一的原因

static String luaScript = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
 public static boolean releaseLock(String key ,String lockValue){
 if(key == null || lockValue == null) {
 return false;
 }
 try {
 Jedis jedis = getJedisPool().getResource();
 Object res =jedis.eval（luaScript,Collections.singletonList(key),Collections.singletonList(lockValue));
 jedis.close();
 return res!=null && res.equals(lockReleaseOK);
 } catch (Exception e) {
 return false;
 }
 }

劫语：当单机REDIS服务停用，当前分布式锁方案仍旧存在问题。

2.redis锁今生，基于redlock封装而成的redission框架

对于前世redis分布式锁各种解决方案，无论是成熟单机方案 1.SETNX+LUA 2.SET unique_value nx px milliseconds ，都局限性很大
所以Martin发布了一种算法redlock来进行集群（完全互相独立，不存在主从复制或者其他集群协调机制）操作分布式锁
算法如下：
1.获取当前Unix时间，以毫秒为单位。
2.依次尝试从5个实例，使用相同的key和具有唯一性的value（例如UUID）获取锁。并且设置一个超时时间（一般是5-50毫秒，远小于失效时间）
3.客户端当前时间减去开始获取锁时间（第一个redis实例开始）作为获取锁消耗总时间。当且仅当redis集群中有一多半锁获取到（n/2+1）,并且获取锁总时间小于锁设置的失效时间，才任务该线程获取到分布式锁。
4.获取到锁以后，锁的有效时间更改为，最起初设置的锁失效时间-获取锁总消耗时间
5.如果获取锁失败，应该在redis集群中进行解锁

Reddisson框架有效的实现了对redlock的封装。

1)项目中引入

<!--分布式锁-->
 <dependency>
 <groupId>org.redisson</groupId>
 <artifactId>redisson</artifactId>
 <version>3.11.1</version>
 </dependency> 
 2)项目中使用
 /**
 * redisson配置
 */
 @Configuration
 public class RedissonConfig {@Value("${spring.redis.host}")
 private String host;@Value("${spring.redis.port}")
 private String port;@Bean
 public RedissonClient getRedisson(){Config config = new Config();
 config.useSingleServer().setAddress("redis://" + host + ":" + port);
 return Redisson.create(config);
 }}

3)代码中引用

public VersionT getOneVersion() {
VersionT versionT = (VersionT) redisCacheTemplate.opsForValue().get("bzversion");
 RLock rLock = redissonClient.getLock("redissonLock:" + Thread.currentThread().getName()); //分布式锁，避免大量请求一瞬间请求到数据库，造成缓存击穿
 try {
 rLock.tryLock(500,10000, TimeUnit.SECONDS); // 锁失效时间设置10秒，锁响应时间设置50毫秒
 if (versionT == null) {
 VersionT version = versionDao.getOneVersion();
 redisCacheTemplate.opsForValue().set("bzversion", version);
 return version;
 }
 } catch (Exception e) {
 System.out.println("缓存版本号失败" + e.getMessage());
 } finally {
 rLock.unlock();
 }
 return versionT;
 }

4)源码中分析（redission获取锁源码解析）

public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
 long time = unit.toMillis(waitTime); // 单实例获取锁响应时间
 long current = System.currentTimeMillis(); 
 long threadId = Thread.currentThread().getId();
 Long ttl = this.tryAcquire(leaseTime, unit, threadId); // 获取分布式锁
 if (ttl == null) {
 return true;
 } else {
 time -= System.currentTimeMillis() - current; // 超过定义响应时间，返回获取锁失败
 if (time <= 0L) {
 this.acquireFailed(threadId);
 return false;
 } else {
 current = System.currentTimeMillis();
 RFuture<RedissonLockEntry> subscribeFuture = this.subscribe(threadId);
 if (!this.await(subscribeFuture, time, TimeUnit.MILLISECONDS)) {
 if (!subscribeFuture.cancel(false)) {
 subscribeFuture.onComplete((res, e) -> {
 if (e == null) {
 this.unsubscribe(subscribeFuture, threadId);
 }});
 }this.acquireFailed(threadId);
 return false;
 } else {
 try {
 time -= System.currentTimeMillis() - current;
 if (time <= 0L) {
 this.acquireFailed(threadId);
 boolean var20 = false;
 return var20;
 } else {
 boolean var16;
 do {
 long currentTime = System.currentTimeMillis();
 ttl = this.tryAcquire(leaseTime, unit, threadId);
 if (ttl == null) {
 var16 = true;
 return var16;
 }time -= System.currentTimeMillis() - currentTime;
 if (time <= 0L) {
 this.acquireFailed(threadId);
 var16 = false;
 return var16;
 }currentTime = System.currentTimeMillis();
 if (ttl.longValue() >= 0L && ttl.longValue() < time) {
 this.getEntry(threadId).getLatch().tryAcquire(ttl.longValue(), TimeUnit.MILLISECONDS);
 } else {
 this.getEntry(threadId).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
 }time -= System.currentTimeMillis() - currentTime;
 } while(time > 0L);this.acquireFailed(threadId);
 var16 = false;
 return var16;
 }
 } finally {
 this.unsubscribe(subscribeFuture, threadId);
 }
 }
 }
 }
 }
 5) <T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
 this.internalLockLeaseTime = unit.toMillis(leaseTime);
 return this.commandExecutor.evalWriteAsync(this.getName(), LongCodec.INSTANCE, command, "if (redis.call('exists', KEYS[1]) == 0) then redis.call('hset', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end; if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then redis.call('hincrby', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end; return redis.call('pttl', KEYS[1]);", Collections.singletonList(this.getName()), new Object[]{this.internalLockLeaseTime, this.getLockName(threadId)});
 }

跟踪到这里，就会发现，通过LUA脚本实现了锁判断，锁重入等操作。

if (redis.call('exists', KEYS[1]) == 0) 
 then redis.call('hset', KEYS[1], ARGV[2], 1); // 获取锁
 redis.call('pexpire', KEYS[1], ARGV[1]); // 设置key失效时间
 return nil; 
 end; 
 if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then redis.call('hincrby', KEYS[1], ARGV[2], 1); // redis重入锁
 redis.call('pexpire', KEYS[1], ARGV[1]); // 设置key失效时间
 return nil; 
 end; 
 return redis.call('pttl', KEYS[1]); // 以毫秒为单位返回 key 的剩余过期时间

redlock已经属于现在较为稳定的reids分布式锁，但是redlock的作者Martin以及antirez就这个算法不足进行了激烈的讨论，以及引发分布式阵营的对垒。
他们主要纠结的问题点在于：
1.时钟发生跳跃
2.长时间的GC pause或者长时间的网络延迟
其实对于时钟跳跃情况1.服务器更新时间插件 2.运维同学手动更改服务器时间这两种情况虽然很极端，但是确实会造成redlock的失效。
对于第二种情况，无论是长时间的GC pause还是长时间的网络延迟，其实在redlock算法第四步做了校验，那就是最起初设置的失效时间如果小于集群环境下获取redis锁消耗的总时间，则会进行获取锁失败操作。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。