分布式锁（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的节点 先天性可控~