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