分布式锁—1.原理算法和使用建议二

原创于 2025-02-28 23:40:59 发布 · 1.1k 阅读

21 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

分布式锁原理与源码

大纲

1.Redis分布式锁的8大问题

2.Redis的RedLock算法分析

3.基于Redis和zk的分布式锁实现原理

4.Redis分布式锁的问题以及使用建议

3.Redis和zk的分布式锁实现原理对比

(1)Redis分布式锁的简单实现

(2)Redis官方的RedLock算法

(3)zk分布式锁之排他锁实现原理

(4)zk分布式锁之读写锁实现原理

(5)zk分布式锁的一个简单实现

(6)Redis分布式锁和zk分布式锁的对比

问题汇总：

一般实现分布式锁都有哪些方式？使用Redis如何设计分布式锁，使用zk来设计分布式锁可以吗？这两种分布式锁的实现方式哪种效率比较高？

(1)Redis分布式锁的简单实现

Redis分布式锁使用RedLock算法，是Redis官方支持的分布式锁算法，这个分布式锁有3个考量点：

考量点一：互斥，只能有一个客户端获取锁

考量点二：不能产生死锁

考量点三：容错，允许其中的节点出现故障而不影响分布式锁功能

一.获取锁

最普通的实现方式就是在Redis里创建一个key。如果创建成功，那么就认为获取锁成功。如果创建失败，即发现已经有该key了，则说明获取锁失败。

通常使用如下这样的命令进行创建：

/** 说明一："my:lock"就是锁的名称，对应于Redis的key */
/** 说明二：Redis中这个名为"my:lock"的key对应的值必须是一个随机值 */
/** 说明三：NX的意思是只有key不存在的时候才会设置成功 */
/** 说明四："PX 30000"的意思是30秒后锁自动释放 */
SET my:lock 随机值 NX PX 30000

二.释放锁

释放锁就是删除key，但是一般用lua脚本进行删除，并且是判断随机value一样才进行删除。

//删除key的lua脚本
String script =
"if redis.call('get', KEYS[1]) == ARGV[1] then" +
    "return redis.call('del', KEYS[1]);" +
"else" +
    "return 0;" +
"end;";

为什么必须要用随机值：

因为如果某个客户端获取到了锁，但阻塞了很长时间才执行完。此时可能由于过期时间已到而自动释放了锁，而别的客户端又刚好获取到锁，这个时候如果该客户端直接删除key那么就会有问题。所以才必须先对key设置随机值，然后再按key + 随机值来删除key释放锁。

三.这套Redis获取锁 + 释放锁的方案存在的问题

问题一：单点故障。如果Redis服务是普通的单实例，那么就会有单点故障的风险。

问题二：破坏互斥。如果Redis服务是普通主从架构，Redis进行的是主从异步复制。那么当Redis主节点挂了，key还没同步到从节点时，一旦从节点切换为主节点，其他系统的线程就会拿到锁。

(2)Redis官方的RedLock算法

RedLock算法主要是通过过半机制来避免单节点故障导致的锁没同步问题，RedLock算法在获取锁 + 释放锁的方案上基本和前面一致。但实际上这种RedLock算法也有很多问题，不是很完美。

RedLock算法获取一把锁的步骤：

步骤一：客户端先获取当前时间戳T1。

步骤二：客户端依次向这5个节点发起加锁请求，且每个请求都会设置超时时间，也是使用"SET my:lock 随机值 NX PX 50"创建锁。超时时间是毫秒级的，要远小于锁的有效时间，而且一般是几十毫秒。如果某一个节点加锁失败，包括网络超时、锁被其它线程持有等各种情况，那么就立即向下一个Redis节点申请加锁。

步骤三：如果客户端从3个以上(过半)节点加锁成功，则再次获取当前时间戳T2。如果T2 - T1 < 锁的过期时间，则认为客户端加锁成功，否则加锁失败。

步骤四：如果加锁失败，要向全部节点发起释放锁的请求。如果加锁成功，则去操作共享资源，也是使用lua按照key + 随机值进行删除。

(3)zk分布式锁之排他锁的实现原理

一.获取锁

使用临时顺序节点来表示获取锁的请求，让创建出后缀数字最小的节点的客户端成功拿到锁。

步骤一：客户端调用create()方法在"/exclusive_lock"节点下创建临时顺序节点。

步骤二：然后调用getChildren()方法返回"/exclusive_lock"下的所有子节点，接着对这些子节点进行排序。

步骤三：排序后，看看是否有后缀比自己小的节点。如果没有，则当前客户端便成功获取到排他锁。如果有，则调用exist()方法对排在自己前面的那个节点注册Watcher监听。

步骤四：当客户端收到Watcher通知前面的节点不存在，则重复步骤二。

二.释放锁

如果获取锁的客户端宕机，那么客户端在zk上对应的临时节点就会被移除。如果获取锁的客户端执行完，会主动将自己创建的临时节点删除。

(4)zk分布式锁之读写锁的实现原理

一.获取锁

步骤一：客户端调用create()方法在"/shared_lock"节点下创建临时顺序节点。如果是读请求，那么就创建"/shared_lock/read001"的临时顺序节点。如果是写请求，那么就创建"/shared_lock/write002"的临时顺序节点。

步骤二：然后调用getChildren()方法返回"/shared_lock"下的所有子节点，接着对这些子节点进行排序。

步骤三：对于读请求：如果排序后发现有比自己序号小的写请求子节点，则需要等待，且需要向比自己序号小的最后一个写请求子节点注册Watcher监听。

对于写请求：如果排序后发现自己不是序号最小的请求子节点，则需要等待，并且需要向比自己序号小的最后一个请求子节点注册Watcher监听。

注意：这里注册Watcher监听也是调用exist()方法。此外，不满足上述条件则表示成功获取共享锁。

步骤四：如果客户端在等待过程中接收到Watcher通知，则重复步骤二。

二.释放锁

如果获取锁的客户端宕机，那么zk上的对应的临时顺序节点就会被移除。如果获取锁的客户端执行完，会主动将自己创建的临时顺序节点删除。

(5)zk分布式锁的一个简单实现

一.分布式锁的实现步骤

步骤一：每个线程都通过"临时顺序节点 + zk.create()方法 + 添加回调"去创建节点。

步骤二：线程执行完创建临时顺序节点后，先通过CountDownLatch.await()方法进行阻塞。然后在创建成功的回调中，通过zk.getChildren()方法获取根目录并继续回调。

步骤三：某线程在获取根目录成功后的回调中，会对目录排序。排序后如果发现其创建的节点排第一，那么就执行countDown()方法表示获取锁成功。排序后如果发现其创建的节点不是第一，那么就通过zk.exists()方法监听前一节点。

步骤四：获取到锁的线程会通过zk.delete()方法来删除其对应的节点实现释放锁，在等候获取锁的线程掉线时其对应的节点也会被删除。而一旦节点被删除，那些监听根目录的线程就会重新执行zk.getChildren()方法，获取成功后其回调又会进行排序以及通过zk.exists()方法监听前一节点。

二.WatchCallBack对分布式锁的具体实现

public class WatchCallBack implements Watcher, AsyncCallback.StringCallback, AsyncCallback.Children2Callback, AsyncCallback.StatCallback {
    ZooKeeper zk ;
    String threadName;
    CountDownLatch countDownLatch = new CountDownLatch(1);
    String pathName;

    public String getPathName() {
        return pathName;
    }

    public void setPathName(String pathName) {
        this.pathName = pathName;
    }

    public String getThreadName() {
        return threadName;
    }

    public void setThreadName(String threadName) {
        this.threadName = threadName;
    }

    public ZooKeeper getZk() {
        return zk;
    }

    public void setZk(ZooKeeper zk) {
        this.zk = zk;
    }

    public void tryLock() {
        try {
            System.out.println(threadName + " create....");
            //创建一个临时的有序的节点
            zk.create("/lock", threadName.getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL, this, "abc");
            countDownLatch.await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    //当前线程释放锁, 删除节点
    public void unLock() {
        try {
            zk.delete(pathName, -1);
            System.out.println(threadName + " over work....");
        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (KeeperException e) {
            e.printStackTrace();
        }
    }

    //上面zk.create()方法的回调
    //创建临时顺序节点后的回调, 10个线程都能同时创建节点
    //创建完后获取根目录下的子节点, 也就是这10个线程创建的节点列表, 这个不用watch了, 但获取成功后要执行回调
    //这个回调就是每个线程用来执行节点排序, 看谁是第一就认为谁获得了锁
    @Override
    public void processResult(int rc, String path, Object ctx, String name) {
        if (name != null ) {
            System.out.println(threadName  + "  create node : " +  name );
            setPathName(name);
            //一定能看到自己前边的, 所以这里的watch要是false
            zk.getChildren("/", false, this ,"sdf");
        }
    }

    //核心方法: 各个线程获取根目录下的节点时, 上面zk.getChildren("/", false, this ,"sdf")的回调
    @Override
    public void processResult(int rc, String path, Object ctx, List<String> children, Stat stat) {
        //一定能看到自己前边的节点
        System.out.println(threadName + "look locks...");
        for (String child : children) {
            System.out.println(child);
        }
        //根目录下的节点排序
        Collections.sort(children);
        //获取当前线程创建的节点在根目录中排第几
        int i = children.indexOf(pathName.substring(1));
        //是不是第一个, 如果是则说明抢锁成功; 如果不是, 则watch当前线程创建节点的前一个节点是否被删除(删除);
        if (i == 0) {
            System.out.println(threadName + " i am first...");
            try {
                //这里的作用就是不让第一个线程获得锁释放锁跑得太快, 导致后面的线程还没建立完监听第一个节点就被删了
                zk.setData("/", threadName.getBytes(), -1);
                countDownLatch.countDown();
            } catch (KeeperException e) {
                e.printStackTrace();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        } else {
            //9个没有获取到锁的线程都去调用zk.exists, 去监控各自自己前面的节点, 而没有去监听父节点
            //如果各自前面的节点发生删除事件的时候才回调自己, 并关注被删除的事件(所以会执行process回调)
            zk.exists("/" + children.get(i-1), this, this, "sdf");
        }
    }

    //上面zk.exists()的监听
    //监听的节点发生变化的Watcher事件监听
    @Override
    public void process(WatchedEvent event) {
        //如果第一个获得锁的线程释放锁了, 那么其实只有第二个线程会收到回调事件
        //如果不是第一个哥们某一个挂了, 也能造成他后边的收到这个通知, 从而让他后边那个去watch挂掉这个哥们前边的, 保持顺序
        switch (event.getType()) {
            case None:
                break;
            case NodeCreated:
                break;
            case NodeDeleted:
                zk.getChildren("/", false, this ,"sdf");
                break;
            case NodeDataChanged:
                break;
            case NodeChildrenChanged:
                break;
        }
    }

    @Override
    public void processResult(int rc, String path, Object ctx, Stat stat) {
        //TODO
    }
}

三.分布式锁的测试类

package com.demo.zookeeper.lock;

import com.demo.zookeeper.config.ZKUtils;
import org.apache.zookeeper.ZooKeeper;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;

public class TestLock {
    ZooKeeper zk;

    @Before
    public void conn() {
        zk  = ZKUtils.getZK();
    }

    @After
    public void close() {
        try {
            zk.close();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    @Test
    public void lock() {
        //10个线程都去抢锁
        for (int i = 0; i < 10; i++) {
            new Thread() {
                @Override
                public void run() {
                    WatchCallBack watchCallBack = new WatchCallBack();
                    watchCallBack.setZk(zk);
                    String threadName = Thread.currentThread().getName();
                    watchCallBack.setThreadName(threadName);
                    //每一个线程去抢锁
                    watchCallBack.tryLock();
                    //抢到锁之后才能干活
                    System.out.println(threadName + " working...");
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    //干完活释放锁
                    watchCallBack.unLock();
                }
            }.start();
        }
        while(true) {

        }
    }
}

(6)Redis分布式锁和zk分布式锁的对比

一.性能开销方面

对于Redis分布式锁，客户端需要不断去尝试获取锁，比较消耗性能。对于zk分布式锁，当客户端获取不到锁时，只需要注册一个监听器即可。所以zk分布式锁不需要不断主动地尝试获取锁，性能开销小。

二.异常释放锁方面

对于Redis分布式锁，如果获取到锁的客户端挂了，那么只能等过期时间后才能释放锁。对于zk分布式锁，获取锁时创建的是临时节点，即便客户端挂了，由于临时节点会被zk删除，所以会自动释放锁。

三.实现方面

Redis分布式锁的RedLock算法比较麻烦，需要遍历上锁、计算时间等。而zk的分布式锁语义清晰实现简单，zk的分布式锁比Redis的分布式锁牢靠、而且模型简单易用。

四.性能方面

Redis和zk都是基于内存去通过写数据来创建锁的，但是因为zk有过半写机制，所以Redis能够承受更高的QPS。

五.支持方面

Redisson可以对分布式锁提供非常好的支持，zk的Curator则没有这么好的支持。

4.Redis分布式锁的问题以及使用建议

(1)Redis分布式锁的问题

(2)Redis分布式锁的优点

(3)zk分布式锁

(4)使用建议

(5)一点思考

(1)Redis分布式锁的问题

第一种方案：基于Redis单实例 + setnx随机值 + lua删除key

如果出现Redis单点故障，会导致系统全盘崩溃，做不到高可用。除非是那种不太核心的小系统，随便用一下分布式锁，那么可以使用Redis单实例。

第二种方案：基于Redis主从架构 + 哨兵 + setnx随机值 + lua删除key

Redis主从+哨兵保证了高可用，Master宕机，Slave会接替。但是存在隐患，即在Master宕机的瞬间：如果刚创建的锁还没异步复制到Slave，那么就会导致重复加锁的问题。虽然主从 + 哨兵保证了高可用，但锁的实现有漏洞，可能会导致系统异常。

第三种方案：使用RedLock算法

通过twemproxy、Codis、Redis Cluster可以实现Redis集群分片。面对Redis的多Master集群，此时使用的是RedLock算法，但不推荐，因为实现过程太复杂繁琐、很脆弱。因网络原因，难以实现多节点同时设置分布式锁，锁失效时间都会不一样。不同Linux机器的时间不同步 + 各种无法考虑到的问题，可能导致重复加锁。

举个例子：客户端A给5个Redis Master都设置了一个key上了一把锁，失效时间是10s。因为网络等各种情况不同，各个Master对key的过期处理可能不同步。可能会出现：客户端A由于某些原因处理耗时特别长所以还没释放锁，然后过了大概10秒，其中3台机器的key都到期失效了。此时客户端A还没释放锁，而客户端B却发起设置请求，刚好成功加到锁。于是出现两个客户端同时持有锁。

RedLock算法存在两个问题：

问题一：实现过程和步骤太复杂，上锁的过程和机制很重很复杂，导致很脆弱，各种意想不到的情况都可能发生。

问题二：网络原因和各服务器的时钟问题导致对key的过期处理并不同步，不够健壮，不一定能完全实现健壮的分布式锁的语义。

RedLock算法的问题总结：

第一是太复杂

第二是不健壮可能重复加锁

Redis分布式锁总结：

Redis分布式锁实际上没有100%完美的方案，或多或少有点问题。实际生产系统中，有时候用zk分布式锁，有时候也会用Redis分布式锁。

(2)Redis分布式锁的优点

Redis分布式锁有一个优点，就是拥有优秀的Redis客户端类库Redisson。Redisson封装了大量基于Redis的复杂操作，比如数据集合(Map、Set、List)的分布式的存储、各种复杂的分布式锁等。甚至基于Redis+Redisson，就可以将Redis作为一个轻量级的NoSQL使用。

Redisson对Redis分布式锁的支持非常友好，比如支持可重入锁、读写锁、公平锁、信号量、CountDownLatch等。Redisson支持很多种复杂的锁的语义，提供了各种分布式锁的高级支持，Redisson这个客户端框架本身就有完整的一套Redis分布式锁实现。

(3)zk分布式锁

zk分布式锁的优点是锁模型健壮、稳定、简单、可用性高，zk分布式锁的缺点是性能不如Redis，而且部署和运维成本高。

Curator客户端主要还是针对zk的一些基础语义进行封装。Curator之于zk，就类似于Jedis之于Redis。Curator也封装了多种不同的锁类型，比如可重入锁、读写锁、公平锁、信号量、CountDownLatch等锁类型。

Redis的Jedis可以和Redisson结合起来一起使用，因为Jedis封装了Redis的一些基础语义和操作。

(4)使用建议

目前行业里，基本都会有使用Redis或zk做分布式锁。Redis分布式锁没有100%完美和健壮的锁模型，或多或少会导致一些问题。如果业务场景能容忍这些问题，同时需要Redission的复杂的锁类型支持，那么可以使用Redis分布式锁。

zk分布式锁有完美健壮的锁模型，但没有太好的开源类库支持复杂锁类型。如果业务场景要求锁的语义健壮稳定，不能出现多客户端同时加到一把锁，且对锁的功能没有特别需求，那么可以使用zk分布式锁。

(5)一点思考

设计架构为什么偏好用zk分布式锁，原因两个：

原因一是Redis分布式锁的算法模型有隐患，zk分布式锁的机制更加健壮稳定。

原因二是Redis的本质是分布式缓存，zk的本质是分布式协调服务。

此外，如下是一些关于Redis框架的发展看法：

Redis现在越来越往队列、分布式锁、发布订阅等功能发展，有点本末倒置。Redis框架应该回归它的本质去发展，它的本质是一个kv缓存。Redis框架如果要发展，应该是纵向发展。比如支持磁盘存储、可以支持磁盘 + 内存的大规模海量数据的kv存储，而且Redis作为开源项目，最好提供一些便于集群管理和运维操作的功能。

比如提供便捷的可视化界面实现如下等功能来支持使用方高效管理：一键部署集群、集群上下线节点、集群数据迁移、集群数据备份、不同集群模式的一键转换(单实例模式->主从模式->哨兵模式->集群模式)、一键集群版本滚动升级、子集群模式与业务隔离、热key大value的自动发现与报警、集群资源的监控与报警、多机房集群部署容灾、集群访问量监控与扩容预警等。这些功能虽然Cache Clound有提供，但各大公司都要自己重复造轮子。

让人失望的是：Redis Cluster刚出来时还不支持读写分离，其Slave只做高可用自动切换。而且运维极其繁琐，还有RedLock分布式锁算法本身也不健壮。此外还支持队列、支持发布订阅等。Redis天然就不是为了分布式锁这种分布式系统的基础组件来设计的。zk才是最适合做各种分布式系统的基础设施依赖的，而且业界基本各大开源项目，都依赖zk做各种分布式系统的基础设施。

标签

#分布式锁