分布式锁(Redis实现)
1.分布式锁解决方案
1.采用数据库 不建议 性能不好 jdbc
2.基于Redis实现分布式锁(setnx)setnx也可以存入key,如果存入key成功返回1,如果存入的key已经存在了,返回0.
3.基于Zookeeper实现分布式锁 Zookeeper是一个分布式协调工具,在分布式解决方案中。
多个客户端(jvm),同时在zk上创建相同的一个临时节点,因为临时节点路径是保证唯一,只要谁能够创建节点成功,谁就能够获取到锁,没有创建成功节点,就会进行等待,当释放锁的时候,采用事件通知给客户端重新获取锁的资源。
Redis实现分布式锁与Zookeeper实现分布式锁区别
实现分布式锁最终是通过什么方式?(相同点)
在集群环境下,保证只允许有一个jvm进行执行。
从技术上分析(区别)
Redis 是nosql数据,主要特点缓存
Zookeeper是分布式协调工具,主要用于分布式解决方案
实现思路( 区别)
核心通过获取锁、释放锁、死锁问题
获取锁
Zookeeper
多个客户端(jvm),会在Zookeeper上创建同一个临时节点,因为Zookeeper节点命名路径保证唯一,不允许出现重复,只要谁能够先创建成功,谁能够获取到锁。
Redis
多个客户端(jvm),会在Redis使用setnx命令创建相同的一个key,因为Redis的key保证唯一,不允许出现重复,只要谁能够先创建成功,谁能够获取到锁。
释放锁
Zookeeper使用直接关闭临时节点session会话连接,因为临时节点生命周期与session会话绑定在一块,如果session会话连接关闭的话,该临时节点也会被删除。
这时候客户端使用事件监听,如果该临时节点被删除的话,重新进入盗获取锁的步骤。
Redis在释放锁的时候,为了确保是锁的一致性问题,在删除的redis 的key时候,需要判断同一个锁的id,才可以删除。
共同特征:如何解决死锁现象问题
Zookeeper使用会话有效期方式解决死锁现象。
Redis 是对key设置有效期解决死锁现象
性能角度考虑
因为Redis是NoSQL数据库,相对比来说Redis比Zookeeper性能要好。
可靠性
从可靠性角度分析,Zookeeper可靠性比Redis更好。
因为Redis有效期不是很好控制,可能会产生有效期延迟,Zookeeper就不一样,因为Zookeeper临时节点先天性可控的有效期,所以相对来说Zookeeper比Redis更好
Redis实现的分布式锁,setnx可以存入key,如果存入key成功返回1,如果存入的key已经存在了返回0
使用setnx命令方式,同时在redis上创建相同的一个key。redis不允许重复key。创建成功的jvm获取锁,创建失败的jvm就等待。
写入时候 有key 返回1 没有key返回0
在redis中,key 是唯一的!
set持续的输入 key 的value会一直被覆盖哦 返回值是 ok
setnx key不存在1 存在0
删除之后,又可以了哈!
如何释放锁?
执行完操作时候,删除key。 但是 如果此时 redis挂了,或者删除失败,咋办? 解决办法是 给key设置有效期!!!防止死锁问题 (如果代码一直执行不完了,也可以搞定他!)
综述:执行完,删除key,每个key,都有期
多台服务器集群中,只能保证一个jvm进行操作!
identifierValue的作用! 防止a线程删除了 b线程刚刚获取到的锁!!自己删除自己的
赶紧上代码,注解已经很详细了~
pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.toov5.redisLock</groupId>
<artifactId>redisLock</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.9.0</version>
</dependency>
</dependencies>
</project>
redis锁
package com.toov5;
import java.util.UUID;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
//基于redis实现分布式锁,核心方法 获取锁、释放锁
public class LockRedis {
//redis线程池
private JedisPool jedisPool;
//需要创建的那个key
private String redisLockKey = "redis_lock";
//value是个不能重复的数字 锁的id
public LockRedis(JedisPool jedisPool) {
this.jedisPool=jedisPool;
}
/*
* @param acquiretimeOut 在获取锁之前超时
* @param timeOut 在获取锁之后超时
*/
public String getRedisLock(Long acquiretimeOut, Long timeOut){
Jedis conn = null;
try {
//1建立连接
conn=jedisPool.getResource();
//2、定义redis对应key的value (uuid生成) 释放锁时候会用到
String identifierValue = UUID.randomUUID().toString();
//3、reids实现分布式锁 有两个超时问题
//3.1获取锁之前,如果规定时间内 没有获取到锁 放弃
//3.2获取锁之后,可以对应有效期。规定时间内 失效
//4使用循环机制 保证重复进行尝试获取锁(乐观锁)获取不到 则放弃
//5 使用setnx命令插入对应的redislockkey,判断返回值进行业务
int expireLock =(int)(timeOut/1000); //以秒为单位 转换
Long endTime = System.currentTimeMillis()+acquiretimeOut;
while (System.currentTimeMillis()<endTime) { //小于结束时间
//则 获取锁
//6、使用setnx命令插入redislockkey,判断返回值
if (conn.setnx(redisLockKey, identifierValue)==1) {
//设置对应key的有效期
conn.expire(redisLockKey, expireLock); //时间为int类型的
return identifierValue; //插入成功返回 对应的值 规定时间内去循环获取
}
}
} catch (Exception e) {
e.printStackTrace();
}finally{
if (conn != null) {
conn.close();
}
}
return null; //如果大于了 时间 就放弃了 返回 null 结束掉
}
//释放redis锁
public void unRedisLock(String identifierValue){
//两种 1、执行完毕删除
//如果直接删除,有可能a刚刚获取,却被b删除了 所以保证是自己创建的redislockkey,自己的
Jedis conn = null;
conn=jedisPool.getResource();
try {
//如果该锁的id等于identifierValue
if (conn.get(redisLockKey).equals(identifierValue)) {
System.out.println("释放锁"+Thread.currentThread().getName()+",identifierValue");
conn.del(redisLockKey);
}
} catch (Exception e) {
}finally{
if (conn !=null) {
conn.close();
}
}
}
}
业务逻辑:
package com.toov5;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;
public class LockService {
private static JedisPool pool = null;
//redis 连接代码
static {
JedisPoolConfig config = new JedisPoolConfig();
// 设置最大连接数
config.setMaxTotal(200);
// 设置最大空闲数
config.setMaxIdle(8);
// 设置最大等待时间
config.setMaxWaitMillis(1000 * 100);
// 在borrow一个jedis实例时,是否需要验证,若为true,则所有jedis实例均是可用的
config.setTestOnBorrow(true);
pool = new JedisPool(config, "192.168.91.5", 9001, 3000);
}
//创建一个redis锁
private LockRedis lockRedis = new LockRedis(pool);
//定义一个方法 演示rdis实现分布式锁
public void seckill(){
String identifierValue = lockRedis.getRedisLock(5000L, 5000L);//获取到一个随机的返回结果
if (identifierValue == null) {
System.out.println(Thread.currentThread().getName()+"获取时间超时,锁获取失败");
return;
}
System.out.println(Thread.currentThread().getName()+",获取锁成功,锁的id"+identifierValue);
//释放锁
lockRedis.unRedisLock(identifierValue); //表示锁的id
}
}
线程:
package com.toov5;
public class ThreadRedis extends Thread {
private LockService lockService;
public ThreadRedis(LockService lockService) {
this.lockService=lockService;
}
@Override
public void run() {
lockService.seckill();
}
}
测试:
package com.toov5;
public class RedisLockTest {
public static void main(String[] args) {
LockService lockService = new LockService();
for (int i = 0; i < 50; i++) {
new ThreadRedis(lockService).start();
}
}
}
运行结果:
zk也可以通过设置连接超时时间来防止死锁!
三种分布式对比
上面几种方式,哪种方式都无法做到完美。就像CAP一样,在复杂性、可靠性、性能等方面无法同时满足,所以,根据不同的应用场景选择最适合自己的才是王道。
从理解的难易程度角度(从低到高)
数据库 > 缓存 > Zookeeper
从实现的复杂性角度(从低到高)
Zookeeper >= 缓存 > 数据库
从性能角度(从高到低)
缓存 > Zookeeper >= 数据库
从可靠性角度(从高到低)
Zookeeper > 缓存 > 数据库
Redis实现分布式锁与Zookeeper实现分布式锁区别
使用redis实现分布式锁
redis中的set nx 命令,当key不存在时,才能在redis中将key添加成功,利用该属性可以实现分布式锁,并且redis对于key有失效时间,可以控制当某个客户端加锁成功之后挂掉,导致阻塞的问题。
使用Zookeeper实现分布式锁
多个客户端在Zookeeper上创建一个相同的临时节点,因为临时节点只能允许一个客户端创建成功,那么只要任意一个客户端创建节点成功,谁就成功的获取到锁,当释放锁后,其他客户端同样道理在Zookeeper节点。
总结:
相同: 都是保证集群环境下,只有几个jvm进行执行
不同: redis 是NoSQL数据库,主要特点是做缓存
Zookeeper 是分布式协调工具,主要用于分布式解决方案的
主要考虑到三个方面 获取锁 释放锁 死锁
1、获取锁 多个jvm,会在Zookeeper上面创建一个临时节点,谁先创建成功。 节点唯一性
在redis上使用setnx命令创建一个key,谁先创建成功。可以的唯一性
2、释放锁 使用直接关闭临时节点session会话连接。临时节点就会删除。其他客户端事件监听,进入获取锁的环节步骤。
为了保证一致性,一定要判断锁的id才可以删除key
3、 防止死锁: Zookeeper会话有效期设置
Redis的key过期时间
性能角度上: redis比zk要好一些。 毕竟redis是NoSQL数据库,内存中哦。
可靠性来说 zk好 以为redis 的有效期不好控制 可能延迟 看代码: 拿到锁了设置有效期 过程有延迟 zk的节点 先天性可控~