Redis与Zookeeper实现分布式锁的区别

时间 2019-11-06

标签 redis zookeeper 实现分布式区别栏目 Redis 繁體版

原文原文链接

Redis实现分布式锁

　　1.根据lockKey区进行setnx（set not exist，若是key值为空，则正常设置，返回1，不然不会进行设置并返回0）操做，若是设置成功，表示已经得到锁，不然并无获取锁。node

　　2.若是没有得到锁，去Redis上拿到该key对应的值，在该key上咱们存储一个时间戳（用毫秒表示，t1），为了不死锁以及其余客户端占用该锁超过必定时间（5秒），使用该客户端当前时间戳，与存储的时间戳做比较。redis

　　3.若是没有超过该key的使用时限，返回false，表示其余人正在占用该key，不能强制使用；若是已经超过期限，那咱们就能够进行解锁，使用咱们的时间戳来代替该字段的值。算法

　　4.可是若是在setnx失败后，get该值却没法拿到该字段时，说明操做以前该锁已经被释放，这个时候，最好的办法就是从新执行一遍setnx方法来获取其值以得到该锁。session

　　释放锁：删除redis中key异步

 1 public class RedisKeyLock {
 2     private static Logger logger = Logger.getLogger(RedisKeyLock.class);
 3     private final static long ACCQUIRE_LOCK_TIMEOUT_IN_MS = 10 * 1000;
 4     private final static int EXPIRE_IN_SECOND = 5;//锁失效时间
 5     private final static long WAIT_INTERVAL_IN_MS = 100;
 6     private static RedisKeyLock lock;
 7     private JedisPool jedisPool;
 8     private RedisKeyLock(JedisPool pool){
 9         this.jedisPool = pool;
10     }
11     public static RedisKeyLock getInstance(JedisPool pool){
12         if(lock == null){
13             lock = new RedisKeyLock(pool);
14         }
15         return lock;
16     }
17  
18     public void lock(final String redisKey) {
19         Jedis resource = null;
20         try {
21             long now = System.currentTimeMillis();
22             resource = jedisPool.getResource();
23             long timeoutAt = now + ACCQUIRE_LOCK_TIMEOUT_IN_MS;
24             boolean flag = false;
25             while (true) {
26                 String expireAt = String.valueOf(now + EXPIRE_IN_SECOND * 1000);
27                 long ret = resource.setnx(redisKey, expireAt);
28                 if (ret == 1) {//已获取锁
29                     flag = true;
30                     break;
31                 } else {//未获取锁，重试获取锁
32                     String oldExpireAt = resource.get(redisKey);
33                     if (oldExpireAt != null && Long.parseLong(oldExpireAt) < now) {
34                         oldExpireAt = resource.getSet(redisKey, expireAt);
35                         if (Long.parseLong(oldExpireAt) < now) {
36                             flag = true;
37                             break;
38                         }
39                     }
40                 }
41                 if (timeoutAt < now) {
42                     break;
43                 }
44               TimeUnit.NANOSECONDS.sleep(WAIT_INTERVAL_IN_MS);
45             }
46             if (!flag) {
47                 throw new RuntimeException("canot acquire lock now ...");
48             }
49         } catch (JedisException je) {
50             logger.error("lock", je);
51             je.printStackTrace();
52             if (resource != null) {
53                 jedisPool.returnBrokenResource(resource);
54             }
55         } catch (Exception e) {
56             e.printStackTrace();
57             logger.error("lock", e);
58         } finally {
59             if (resource != null) {
60                 jedisPool.returnResource(resource);
61             }
62         }
63     }
64     public boolean unlock(final String redisKey) {
65         Jedis resource = null;
66         try {
67             resource = jedisPool.getResource();
68             resource.del(redisKey);
69             return true;
70         } catch (JedisException je) {
71             je.printStackTrace();
72             if (resource != null) {
73                 jedisPool.returnBrokenResource(resource);
74             }
75             return false;
76         } catch (Exception e) {
77             logger.error("lock", e);
78             return false;
79         } finally {
80             if (resource != null) {
81                 jedisPool.returnResource(resource);
82             }
83         }
84     }
85 }

另外一个版本：分布式

　　SET my:lock 随机值 NX PX 30000性能

　　这个的NX的意思就是只有key不存在的时候才会设置成功，PX 30000的意思是30秒后锁自动释放。别人建立的时候若是发现已经有了就不能加锁了。ui

　　释放锁就是删除key，可是通常能够用lua脚本删除，判断value同样才删除this

　　为啥要用随机值呢？由于若是某个客户端获取到了锁，可是阻塞了很长时间才执行完，此时可能已经自动释放锁了，此时可能别的客户端已经获取到了这个锁，要是你这个时候直接删除key的话会有问题，因此得用随机值加上面的lua脚原本释放锁。（就是根据这个随机值来判断这个锁是否是本身加的）lua

　　若是是Redis是单机，会有问题。由于若是是普通的redis单实例，那就是单点故障。单节点挂了会致使锁失效。

　　若是是redis普通主从，那redis主从异步复制，若是主节点挂了，key还没同步到从节点，此时从节点切换为主节点，别人就会拿到锁。

RedLock算法

　　这个场景是假设有一个redis cluster，有5个redis master实例。而后执行以下步骤获取一把锁：

　　获取当前时间戳，单位是毫秒

　　跟上面相似，轮流尝试在每一个master节点上建立锁，过时时间较短，通常就几十毫秒

　　尝试在大多数节点上创建一个锁，好比5个节点就要求是3个节点（n / 2 +1）

　　客户端计算创建好锁的时间，若是创建锁的时间小于超时时间，就算创建成功了

　　要是锁创建失败了，那么就依次删除这个锁

　　只要别人创建了一把分布式锁，你就得不断轮询去尝试获取锁

Zookeeper实现分布式锁

基于临时顺序节点：

　　1.客户端调用create()方法建立名为“locknode/guid-lock-”的节点，须要注意的是，这里节点的建立类型须要设置为EPHEMERAL_SEQUENTIAL。

　　2.客户端调用getChildren(“locknode”)方法来获取全部已经建立的子节点。

　　3.客户端获取到全部子节点path以后，若是发现本身在步骤1中建立的节点是全部节点中序号最小的，那么就认为这个客户端得到了锁。

　　4.若是建立的节点不是全部节点中序号最小的，那么则监视比本身建立节点的序列号小的最大的节点，进入等待。直到下次监视的子节点变动的时候，再进行子节点的获取，判断是否获取锁。

　　释放锁的过程相对比较简单，就是删除本身建立的那个子节点便可。

不太严谨的代码：

  1 public class ZooKeeperDistributedLock implements Watcher{
  2     
  3     private ZooKeeper zk;
  4     private String locksRoot= "/locks";
  5     private String productId;
  6     private String waitNode;
  7     private String lockNode;
  8     private CountDownLatch latch;
  9     private CountDownLatch connectedLatch = new CountDownLatch(1);
 10 private int sessionTimeout = 30000; 
 11 
 12     public ZooKeeperDistributedLock(String productId){
 13         this.productId = productId;
 14          try {
 15        String address = "192.168.31.187:2181,192.168.31.19:2181,192.168.31.227:2181";
 16             zk = new ZooKeeper(address, sessionTimeout, this);
 17             connectedLatch.await();
 18         } catch (IOException e) {
 19             throw new LockException(e);
 20         } catch (KeeperException e) {
 21             throw new LockException(e);
 22         } catch (InterruptedException e) {
 23             throw new LockException(e);
 24         }
 25     }
 26 
 27     public void process(WatchedEvent event) {
 28         if(event.getState()==KeeperState.SyncConnected){
 29             connectedLatch.countDown();
 30             return;
 31         }
 32 
 33         if(this.latch != null) {  
 34             this.latch.countDown(); 
 35         }
 36     }
 37 
 38     public void acquireDistributedLock() {   
 39         try {
 40             if(this.tryLock()){
 41                 return;
 42             }
 43             else{
 44                 waitForLock(waitNode, sessionTimeout);
 45             }
 46         } catch (KeeperException e) {
 47             throw new LockException(e);
 48         } catch (InterruptedException e) {
 49             throw new LockException(e);
 50         } 
 51 }
 52 
 53     public boolean tryLock() {
 54         try {
 55          // 传入进去的locksRoot + “/” + productId
 56         // 假设productId表明了一个商品id，好比说1
 57         // locksRoot = locks
 58         // /locks/10000000000，/locks/10000000001，/locks/10000000002
 59             lockNode = zk.create(locksRoot + "/" + productId, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);
 60    
 61             // 看看刚建立的节点是否是最小的节点
 62          // locks：10000000000，10000000001，10000000002
 63             List<String> locks = zk.getChildren(locksRoot, false);
 64             Collections.sort(locks);
 65     
 66             if(lockNode.equals(locksRoot+"/"+ locks.get(0))){
 67                 //若是是最小的节点,则表示取得锁
 68                 return true;
 69             }
 70     
 71             //若是不是最小的节点，找到比本身小1的节点
 72       int previousLockIndex = -1;
 73             for(int i = 0; i < locks.size(); i++) {
 74         if(lockNode.equals(locksRoot + “/” + locks.get(i))) {
 75                      previousLockIndex = i - 1;
 76             break;
 77         }
 78        }
 79        
 80        this.waitNode = locks.get(previousLockIndex);
 81         } catch (KeeperException e) {
 82             throw new LockException(e);
 83         } catch (InterruptedException e) {
 84             throw new LockException(e);
 85         }
 86         return false;
 87     }
 88      
 89     private boolean waitForLock(String waitNode, long waitTime) throws InterruptedException, KeeperException {
 90         Stat stat = zk.exists(locksRoot + "/" + waitNode, true);
 91         if(stat != null){
 92             this.latch = new CountDownLatch(1);
 93             this.latch.await(waitTime, TimeUnit.MILLISECONDS);                   this.latch = null;
 94         }
 95         return true;
 96 }
 97 
 98     public void unlock() {
 99         try {
100         // 删除/locks/10000000000节点
101         // 删除/locks/10000000001节点
102             System.out.println("unlock " + lockNode);
103             zk.delete(lockNode,-1);
104             lockNode = null;
105             zk.close();
106         } catch (InterruptedException e) {
107             e.printStackTrace();
108         } catch (KeeperException e) {
109             e.printStackTrace();
110         }
111 }
112 
113     public class LockException extends RuntimeException {
114         private static final long serialVersionUID = 1L;
115         public LockException(String e){
116             super(e);
117         }
118         public LockException(Exception e){
119             super(e);
120         }
121 }
122 
123 // 若是有一把锁，被多我的给竞争，此时多我的会排队，第一个拿到锁的人会执行，而后释放锁，后面的每一个人都会去监听排在本身前面的那我的建立的node上，一旦某我的释放了锁，排在本身后面的人就会被zookeeper给通知，一旦被通知了以后，就ok了，本身就获取到了锁，就能够执行代码了
124 
125 }

另外一个版本：

　　zk分布式锁，就是某个节点尝试建立临时znode，此时建立成功了就获取了这个锁；这个时候别的客户端来建立锁会失败，只能注册个监听器监听这个锁。

　　释放锁就是删除这个znode，一旦释放掉就会通知客户端，而后有一个等待着的客户端就能够再次从新加锁。

　　redis分布式锁，其实须要本身不断去尝试获取锁，比较消耗性能

　　zk分布式锁，获取不到锁，注册个监听器便可，不须要不断主动尝试获取锁，性能开销较小

　　另一点就是，若是是redis获取锁的那个客户端bug了或者挂了，那么只能等待超时时间以后才能释放锁；而zk的话，由于建立的是临时znode，只要客户端挂了，znode就没了，此时就自动释放锁