女朋友也能看懂的Zookeeper分布式锁原理

最新推荐文章于 2024-09-12 11:30:10 发布
最新推荐文章于 2024-09-12 11:30:10 发布
阅读量221 收藏
点赞数
分类专栏： Java zookeeper分布式锁
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/JavaMrZhang/article/details/112986422
版权

介绍

许多场景中，数据一致性是一个比较重要的话题，在单机环境中，我们可以通过Java提供的并发API来解决；而在分布式环境(会遇到网络故障、消息重复、消息丢失等各种问题)下要复杂得多，比如电商的库存扣减，秒杀活动，集群定时任务执行等需要进程互斥的场景。本文主要探讨如何利用Zookeeper来实现分布式锁，对比了一些其他方案分布式锁的优缺点。至于使用何种，要因自己的业务场景去决定，没有绝对的方案。

分布式锁是什么？

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。

实现分布式锁注意点：
  • 锁的可重入性(递归调用不应该被阻塞、避免死锁)
  • 锁的超时(避免死锁、死循环等意外情况)
  • 锁的阻塞(保证原子性等)
  • 锁的特性支持(阻塞锁、可重入锁、公平锁、联锁、信号量、读写锁)
使用分布式锁注意点：
  • 分布式锁的开销(分布式锁一般能不用就不用，有些场景可以用乐观锁代替)
  • 加锁的粒度(控制加锁的粒度，可以优化系统的性能)
  • 加锁的方式

常见的实现分布式锁方案

数据库

基于数据库表唯一索引

最简单的方式就是直接创建一张锁表，当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。给某字段添加唯一性约束，如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，可以执行方法体内容。

但会引入数据库单点、无失效时间、不阻塞、不可重入等问题。

基于数据库排他锁

如果使用的是MySql的InnoDB引擎，在查询语句后面增加for update，数据库会在查询过程中(须通过唯一索引查询)给数据库表增加排他锁，我们可以认为获得排它锁的线程即可获得分布式锁，通过 connection.commit() 操作来释放锁。

会引入数据库单点、不可重入、无法保证一定使用行锁、排他锁，所以有可能长时间不提交导致占用数据库连接等问题。

优缺点
  • 优点：

直接借助数据库，容易理解。

  • 缺点

会引入更多的问题，使整个方案变得越来越复杂

操作数据库需要一定的开销，有一定的性能问题

使用数据库的行级锁并不一定靠谱，尤其是当我们的锁表并不大的时候

缓存

相比较于基于数据库实现分布式锁的方案来说，基于缓存来实现在性能方面会表现的更好一点，目前有很多成熟的缓存产品，包括Redis、memcached、tair等。

基于 redis 的 setnx()、expire() 方法做分布式锁

setnx 的含义就是 SET if Not Exists，其主要有两个参数 setnx(key, value)。该方法是原子的，如果 key 不存在，则设置当前 key 成功，返回 1；如果当前 key 已经存在，则设置当前 key 失败，返回 0。

expire 设置过期时间，要注意的是 setnx 命令不能设置 key 的超时时间，只能通过 expire() 来对 key 设置。

redis有个命令可以实现setnx 和 expire 同样效果的原子性指令，博主这边解释并未提及到。命令：
set k1 v1 ex 10 nx 。当然为了实现以上博主说的两个命令原子性操作，也可以使用lua脚本完成。

基于 Redlock 做分布式锁

Redlock 是 Redis 的作者 antirez 给出集群模式的 Redis 分布式锁，它基于 N 个完全独立的 Redis 节点（通常情况下 N 可以设置成 5）

基于 redisson 做分布式锁

redisson 是 redis 官方的分布式锁组件

优缺点

  • 优点
    性能好

  • 缺点

实现中需要考虑的因素太多，
通过超时时间来控制锁的失效时间并不是十分的靠谱

Zookeeper

大致思想

每个客户端对某个方法加锁时，在 Zookeeper 上与该方法对应的指定节点目录下，生成一个唯一的临时有序节点（zk有自动生成有序节点的功能）。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。当释放锁的时候，只需将这个临时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题

Zookeeper 实现分布式锁的核心原理
1. 排他锁

排他锁，又称写锁或独占锁。如果事务T1对数据对象O1加上了排他锁，那么在整个加锁期间，只允许事务T1对O1进行读取或更新操作，其他事务都不能对这个数据对象进行任何操作，直到T1释放了排他锁。

排他锁核心是保证当前有且仅有一个事务获得锁，并且锁释放之后，所有正在等待获取锁的事务都能够被通知到。

Zookeeper 的强一致性特性，能够很好地保证在分布式高并发情况下，创建节点能够保证全局唯一性，可以利用Zookeeper这个特性，实现排他锁。

就是读写互斥、写写互斥、读读互斥

实现原理，有3个核心步骤：定义锁、获取锁、释放锁

  • 定义锁

通过Zookeeper上的数据节点来表示一个锁

  • 获取锁

客户端通过调用 create 方法创建表示锁的临时节点。创建成功，认为客户端获得锁。创建失败，认为锁被占用。同时让没有获得锁的节点在该节点上注册Watcher监听，以便实时监听到lock节点的变更情况，再次去获取锁。

  • 释放锁

当前获得锁的客户端发生宕机或异常，那么Zookeeper上这个临时节点就会被删除，锁也就释放了。

正常执行完业务逻辑，客户端主动删除自己创建的临时节点。

2. 共享锁

共享锁，又称读锁。如果事务T1对数据对象O1加上了共享锁，那么当前事务只能对O1进行读取操作，其他事务也只能对这个数据对象加共享锁，直到该数据对象上的所有共享锁都被释放。

共享锁与排他锁的区别在于，加了排他锁之后，数据对象只对当前事务可见，而加了共享锁之后，数据对象对所有事务都可见。

总结，读读共享，读写互斥。都是读请求不锁资源，资源共享。有读有写就锁资源。

实现原理也是3个核心步骤：

  • 定义锁

通过Zookeeper上的数据节点来表示一个锁，是一个类似于 /lockpath/[hostname]-请求类型-序号的临时顺序节点

  • 获取锁

客户端通过调用 create 方法创建表示锁的临时顺序节点。如果是读请求，则创建 /lockpath/[hostname]-R-序号节点，如果是写请求则创建 /lockpath/[hostname]-W-序号节点

判断获得共享锁的逻辑为：

  1. 创建完节点后，获取 /lockpath 节点下的所有子节点，并对该节点注册子节点变更的Watcher监听

  2. 确定自己的节点序号

  3. 对于读请求，如果比发现有比自己序号小的写请求就等待继续获取锁，没有则获取共享锁，操作资源。 对于写请求，如果发现有比自己序号小的读/写请求就等待获取锁，没有则获取锁。

  4. 接收到Watcher通知后，重复步骤1

  • 释放锁

与排他锁逻辑一致。

3. 羊群效应的产生

在实现共享锁的 “判断读写顺序” 的第1个步骤是：创建完节点后，获取 /lockpath 节点下的所有子节点，并对该节点注册子节点变更的Watcher监听。这样的话，任何一次客户端移除共享锁之后，Zookeeper将会发送子节点变更的Watcher通知给所有机器，系统中将有大量的 “Watcher通知” 和 “子节点列表获取” 这个操作重复执行，然后所有节点再判断自己是否是序号最小的节点(写请求)或者判断比自己序号小的子节点是否都是读请求(读请求)，从而继续等待下一次通知。

然而，这些重复操作很多都是 “无用的”，实际上每个锁竞争者只需要关注序号比自己小的那个节点是否存在即可。

当集群规模比较大时，这些 “无用的” 操作不仅会对Zookeeper造成巨大的性能影响和网络冲击，更为严重的是，如果同一时间有多个客户端释放了共享锁，Zookeeper服务器就会在短时间内向其余客户端发送大量的事件通知–这就是所谓的 “羊群效应“。

改进后的分布式锁实现：

  1. 客户端调用 create 方法创建一个类似于 /lockpath/[hostname]-请求类型-序号 的临时顺序节点

  2. 客户端调用 getChildren 方法获取所有已经创建的子节点列表(这里不注册任何Watcher)

  3. 读请求：向比自己序号小的最后一个写请求节点注册Watcher监听，写请求：向比自己序号小的最后一个节点注册Watcher监听 （有无获取锁的逻辑同上）

  4. 等待Watcher监听，继续进入步骤2

用Curator客户端实现分布式锁

Apache Curator是一个Zookeeper的开源客户端，它提供了Zookeeper各种应用场景（Recipe，如共享锁服务、master选举、分布式计数器等）的抽象封装，接下来将利用Curator提供的类来实现分布式锁，Curator提供的跟分布式锁相关的类有5个，分别是：

  1. Shared Reentrant Lock 可重入锁
  2. Shared Lock 共享不可重入锁
  3. Shared Reentrant Read Write Lock 可重入读写锁
  4. Shared Semaphore 信号量
  5. Multi Shared Lock 多锁

关于错误处理：还是强烈推荐使用ConnectionStateListener处理连接状态的改变。当连接LOST时你不再拥有锁。

1. 可重入锁

Shared Reentrant Lock，全局可重入锁，所有客户端都可以请求，同一个客户端在拥有锁的同时，可以多次获取，不会被阻塞。它是由类 InterProcessMutex 来实现，它的主要方法：

//构造方法
public InterProcessMutex(CuratorFramework client, String path)
public InterProcessMutex(CuratorFramework client, String path, LockInternalsDriver driver)
// 通过acquire获得锁,并提供超时机制：
public void acquire() throws Exception
public boolean acquire(long time, TimeUnit unit) throws Exception
// 撤销锁
public void makeRevocable(RevocationListener<InterProcessMutex> listener)
public void makeRevocable(final RevocationListener<InterProcessMutex> listener, Executor executor)

定义一个 FakeLimitedResource 类来模拟共享资源，该资源一次只能被一个线程使用，直到使用结束，下一个线程才能使用，否则会抛出异常。

public class FakeLimitedResource {
    private final AtomicBoolean inUse = new AtomicBoolean(false);

    // 模拟只能单线程操作的资源
    public void use() throws InterruptedException {
        if (!inUse.compareAndSet(false, true)) {
            // 在正确使用锁的情况下，此异常不可能抛出
            throw new IllegalStateException("Needs to be used by one client at a time");
        }
        try {
            Thread.sleep((long) (100 * Math.random()));
        } finally {
            inUse.set(false);
        }
    }
}

下面的代码将创建 N 个线程来模拟分布式系统中的节点，系统将通过 InterProcessMutex 来控制对资源的同步使用。

每个节点都将发起10次请求，完成 请求锁–访问资源–再次请求锁–释放锁–释放锁 的过程。

客户端通过 acquire 请求锁，通过 release 释放锁，获得几把锁就要释放几把锁。

这个共享资源一次只能被一个线程使用，如果控制同步失败，将抛异常。

public class SharedReentrantLockTest {
    private static final String lockPath = "/testZK/sharedreentrantlock";
    private static final Integer clientNums = 5;
    final static FakeLimitedResource resource = new FakeLimitedResource(); // 共享的资源
    private static CountDownLatch countDownLatch = new CountDownLatch(clientNums);

    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < clientNums; i++) {
            String clientName = "client#" + i;
            new Thread(new Runnable() {
                @Override
                public void run() {
                    CuratorFramework client = ZKUtils.getClient();
                    client.start();
                    Random random = new Random();
                    try {
                        final InterProcessMutex lock = new InterProcessMutex(client, lockPath);
                        // 每个客户端请求10次共享资源
                        for (int j = 0; j < 10; j++) {
                            if (!lock.acquire(10, TimeUnit.SECONDS)) {
                                throw new IllegalStateException(j + ". " + clientName + " 不能得到互斥锁");
                            }
                            try {
                                System.out.println(j + ". " + clientName + " 已获取到互斥锁");
                                resource.use(); // 使用资源
                                if (!lock.acquire(10, TimeUnit.SECONDS)) {
                                    throw new IllegalStateException(j + ". " + clientName + " 不能再次得到互斥锁");
                                }
                                System.out.println(j + ". " + clientName + " 已再次获取到互斥锁");
                                lock.release(); // 申请几次锁就要释放几次锁
                            } finally {
                                System.out.println(j + ". " + clientName + " 释放互斥锁");
                                lock.release(); // 总是在finally中释放
                            }
                            Thread.sleep(random.nextInt(100));
                        }
                    } catch (Throwable e) {
                        System.out.println(e.getMessage());
                    } finally {
                        CloseableUtils.closeQuietly(client);
                        System.out.println(clientName + " 客户端关闭！");
                        countDownLatch.countDown();
                    }
                }
            }).start();
        }
        countDownLatch.await();
        System.out.println("结束！");
    }
}

控制台打印日志，可以看到对资源的同步访问控制成功，并且锁是可重入的

0. client#3 已获取到互斥锁
0. client#3 已再次获取到互斥锁
0. client#3 释放互斥锁
0. client#1 已获取到互斥锁
0. client#1 已再次获取到互斥锁
0. client#1 释放互斥锁
0. client#2 已获取到互斥锁
0. client#2 已再次获取到互斥锁
0. client#2 释放互斥锁
0. client#0 已获取到互斥锁
0. client#0 已再次获取到互斥锁
0. client#0 释放互斥锁
0. client#4 已获取到互斥锁
0. client#4 已再次获取到互斥锁
0. client#4 释放互斥锁
1. client#1 已获取到互斥锁
1. client#1 已再次获取到互斥锁
1. client#1 释放互斥锁
2. client#1 已获取到互斥锁
2. client#1 已再次获取到互斥锁
2. client#1 释放互斥锁
1. client#4 已获取到互斥锁
1. client#4 已再次获取到互斥锁
1. client#4 释放互斥锁
1. client#3 已获取到互斥锁
1. client#3 已再次获取到互斥锁
1. client#3 释放互斥锁
1. client#2 已获取到互斥锁
1. client#2 已再次获取到互斥锁
1. client#2 释放互斥锁
2. client#4 已获取到互斥锁
2. client#4 已再次获取到互斥锁
2. client#4 释放互斥锁
....
....
client#2 客户端关闭！
9. client#0 已获取到互斥锁
9. client#0 已再次获取到互斥锁
9. client#0 释放互斥锁
9. client#3 已获取到互斥锁
9. client#3 已再次获取到互斥锁
9. client#3 释放互斥锁
client#0 客户端关闭！
8. client#4 已获取到互斥锁
8. client#4 已再次获取到互斥锁
8. client#4 释放互斥锁
9. client#4 已获取到互斥锁
9. client#4 已再次获取到互斥锁
9. client#4 释放互斥锁
client#3 客户端关闭！
client#4 客户端关闭！
结束！

同时在程序运行期间查看Zookeeper节点树，可以发现每一次请求的锁实际上对应一个临时顺序节点

[zk: localhost:2181(CONNECTED) 42] ls /testZK/sharedreentrantlock
[leases, _c_208d461b-716d-43ea-ac94-1d2be1206db3-lock-0000001659, locks, _c_64b19dba-3efa-46a6-9344-19a52e9e424f-lock-0000001658, _c_cee02916-d7d5-4186-8867-f921210b8815-lock-0000001657]
2. 不可重入锁

Shared Lock 与 Shared Reentrant Lock 相似，但是不可重入，这个不可重入锁由类 InterProcessSemaphoreMutex 来实现，使用方法和上面的类似。

将上面程序中的 InterProcessMutex 换成不可重入锁 InterProcessSemaphoreMutex，如果再运行上面的代码，结果就会发现线程被阻塞在第二个 acquire 上，直到超时，也就是此锁不是可重入的。控制台输出日志如下：

0. client#2 已获取到互斥锁
0. client#1 不能得到互斥锁
0. client#4 不能得到互斥锁
0. client#0 不能得到互斥锁
0. client#3 不能得到互斥锁
client#1 客户端关闭！
client#4 客户端关闭！
client#3 客户端关闭！
client#0 客户端关闭！
0. client#2 释放互斥锁
0. client#2 不能再次得到互斥锁
client#2 客户端关闭！
结束！

把第二个获取锁的代码注释，程序才能正常执行

0. client#1 已获取到互斥锁
0. client#1 释放互斥锁
0. client#2 已获取到互斥锁
0. client#2 释放互斥锁
0. client#0 已获取到互斥锁
0. client#0 释放互斥锁
0. client#4 已获取到互斥锁
0. client#4 释放互斥锁
0. client#3 已获取到互斥锁
0. client#3 释放互斥锁
1. client#1 已获取到互斥锁
1. client#1 释放互斥锁
1. client#2 已获取到互斥锁
1. client#2 释放互斥锁
....
....
9. client#4 已获取到互斥锁
9. client#4 释放互斥锁
9. client#0 已获取到互斥锁
client#2 客户端关闭！
9. client#0 释放互斥锁
9. client#1 已获取到互斥锁
client#0 客户端关闭！
client#4 客户端关闭！
9. client#1 释放互斥锁
9. client#3 已获取到互斥锁
client#1 客户端关闭！
9. client#3 释放互斥锁
client#3 客户端关闭！
结束！
3. 可重入读写锁

Shared Reentrant Read Write Lock，可重入读写锁，一个读写锁管理一对相关锁，一个负责读操作，另外一个负责写操作；读操作在写锁没被使用时可同时由多个进程使用，而写锁在使用时不允许读(阻塞)；此锁是可重入的；一个拥有写锁的线程可重入读锁，但是读锁却不能进入写锁，这也意味着写锁可以降级成读锁， 比如 请求写锁 —>读锁 ---->释放写锁；从读锁升级成写锁是不行的。

可重入读写锁主要由两个类实现：InterProcessReadWriteLock、InterProcessMutex，使用时首先创建一个 InterProcessReadWriteLock 实例，然后再根据你的需求得到读锁或者写锁，读写锁的类型是 InterProcessMutex。

可以理解为我们上面分析的共享锁

 public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < clientNums; i++) {
            final String clientName = "client#" + i;
            new Thread(new Runnable() {
                @Override
                public void run() {
                    CuratorFramework client = ZKUtils.getClient();
                    client.start();
                    final InterProcessReadWriteLock lock = new InterProcessReadWriteLock(client, lockPath);
                    final InterProcessMutex readLock = lock.readLock();
                    final InterProcessMutex writeLock = lock.writeLock();

                    try {
                        // 注意只能先得到写锁再得到读锁，不能反过来！！！
                        if (!writeLock.acquire(10, TimeUnit.SECONDS)) {
                            throw new IllegalStateException(clientName + " 不能得到写锁");
                        }
                        System.out.println(clientName + " 已得到写锁");
                        if (!readLock.acquire(10, TimeUnit.SECONDS)) {
                            throw new IllegalStateException(clientName + " 不能得到读锁");
                        }
                        System.out.println(clientName + " 已得到读锁");
                        try {
                            resource.use(); // 使用资源
                        } finally {
                            System.out.println(clientName + " 释放读写锁");
                            readLock.release();
                            writeLock.release();
                        }
                    } catch (Exception e) {
                        System.out.println(e.getMessage());
                    } finally {
                        CloseableUtils.closeQuietly(client);
                        countDownLatch.countDown();
                    }
                }
            }).start();
        }
        countDownLatch.await();
        System.out.println("结束！");
    }
}

控制台打印日志

client#1 已得到写锁
client#1 已得到读锁
client#1 释放读写锁
client#2 已得到写锁
client#2 已得到读锁
client#2 释放读写锁
client#0 已得到写锁
client#0 已得到读锁
client#0 释放读写锁
client#4 已得到写锁
client#4 已得到读锁
client#4 释放读写锁
client#3 已得到写锁
client#3 已得到读锁
client#3 释放读写锁
结束！
4. 信号量

Shared Semaphore，一个计数的信号量类似JDK的 Semaphore，JDK中 Semaphore 维护的一组许可(permits)，而Cubator中称之为租约(Lease)。

有两种方式可以决定 semaphore 的最大租约数，在构造方法初始化的时候完成。第一种方式是由用户给定maxLeases 决定，第二种方式使用 SharedCountReader 类。

  public InterProcessSemaphoreV2(CuratorFramework client, String path, int maxLeases)
  public InterProcessSemaphoreV2(CuratorFramework client, String path, SharedCountReader count)

信号量主要实现类有

InterProcessSemaphoreV2 - 信号量实现类
Lease - 租约(单个信号)
SharedCountReader - 计数器，用于计算最大租约数量

你可以请求多个租约，通过调用acquire方法完成。如果 Semaphore 当前的租约不够，则请求线程会被阻塞，同时还提供了超时的重载方法。

public Lease acquire() throws Exception
public Collection<Lease> acquire(int qty) throws Exception
public Lease acquire(long time, TimeUnit unit) throws Exception
public Collection<Lease> acquire(int qty, long time, TimeUnit unit) throws Exception

调用 acquire 会返回一个租约对象，客户端必须在 finally 中 close 这些租约对象，否则这些租约会丢失掉。但是，如果客户端session由于某种原因比如crash丢掉，那么这些客户端持有的租约会自动close，这样其它客户端可以继续使用这些租约。租约还可以通过下面的几个方法返还，可以返回一个，也可以返回多个。

public void returnLease(Lease lease)
public void returnAll(Collection<Lease> leases)

一个Demo程序如下

public class SharedSemaphoreTest {
    private static final int MAX_LEASE = 10;
    private static final String PATH = "/testZK/semaphore";
    private static final FakeLimitedResource resource = new FakeLimitedResource();

    public static void main(String[] args) throws Exception {
        CuratorFramework client = ZKUtils.getClient();
        client.start();
        InterProcessSemaphoreV2 semaphore = new InterProcessSemaphoreV2(client, PATH, MAX_LEASE);
        Collection<Lease> leases = semaphore.acquire(5);
        System.out.println("获取租约数量：" + leases.size());
        Lease lease = semaphore.acquire();
        System.out.println("获取单个租约");
        resource.use(); // 使用资源
        // 再次申请获取5个leases，此时leases数量只剩4个，不够，将超时
        Collection<Lease> leases2 = semaphore.acquire(5, 10, TimeUnit.SECONDS);
        System.out.println("获取租约，如果超时将为null：" + leases2);
        System.out.println("释放租约");
        semaphore.returnLease(lease);
        // 再次申请获取5个，这次刚好够
        leases2 = semaphore.acquire(5, 10, TimeUnit.SECONDS);
        System.out.println("获取租约，如果超时将为null：" + leases2);
        System.out.println("释放集合中的所有租约");
        semaphore.returnAll(leases);
        semaphore.returnAll(leases2);
        client.close();
        System.out.println("结束!");
    }
}

控制台打印日志

获取租约数量：5
获取单个租约
获取租约，如果超时将为null：null
释放租约
获取租约，如果超时将为null：[org.apache.curator.framework.recipes.locks.InterProcessSemaphoreV2$3@3108bc, org.apache.curator.framework.recipes.locks.InterProcessSemaphoreV2$3@370736d9, org.apache.curator.framework.recipes.locks.InterProcessSemaphoreV2$3@5f9d02cb, org.apache.curator.framework.recipes.locks.InterProcessSemaphoreV2$3@63753b6d, org.apache.curator.framework.recipes.locks.InterProcessSemaphoreV2$3@6b09bb57]
释放集合中的所有租约
结束!

上面所讲的4种锁都是公平锁(fair)。从ZooKeeper的角度看，每个客户端都按照请求的顺序获得锁，相当公平。

5. 多锁

Multi Shared Lock 是一个锁的容器。当调用 acquire，所有的锁都会被 acquire，如果请求失败，所有的锁都会被 release。同样调用 release 时所有的锁都被 release(失败被忽略)。基本上，它就是组锁的代表，在它上面的请求释放操作都会传递给它包含的所有的锁。

主要涉及两个类：

InterProcessMultiLock - 对所对象实现类
InterProcessLock - 分布式锁接口类

它的构造函数需要包含锁的集合，或者一组 ZooKeeper 的 path，用法和 Shared Lock 相

public InterProcessMultiLock(CuratorFramework client, List<String> paths)
public InterProcessMultiLock(List<InterProcessLock> locks)

一个Demo程序如下

public class MultiSharedLockTest {
    private static final String lockPath1 = "/testZK/MSLock1";
    private static final String lockPath2 = "/testZK/MSLock2";
    private static final FakeLimitedResource resource = new FakeLimitedResource();

    public static void main(String[] args) throws Exception {
        CuratorFramework client = ZKUtils.getClient();
        client.start();

        InterProcessLock lock1 = new InterProcessMutex(client, lockPath1); // 可重入锁
        InterProcessLock lock2 = new InterProcessSemaphoreMutex(client, lockPath2); // 不可重入锁
        // 组锁，多锁
        InterProcessMultiLock lock = new InterProcessMultiLock(Arrays.asList(lock1, lock2));
        if (!lock.acquire(10, TimeUnit.SECONDS)) {
            throw new IllegalStateException("不能获取多锁");
        }
        System.out.println("已获取多锁");
        System.out.println("是否有第一个锁: " + lock1.isAcquiredInThisProcess());
        System.out.println("是否有第二个锁: " + lock2.isAcquiredInThisProcess());
        try {
            resource.use(); // 资源操作
        } finally {
            System.out.println("释放多个锁");
            lock.release(); // 释放多锁
        }
        System.out.println("是否有第一个锁: " + lock1.isAcquiredInThisProcess());
        System.out.println("是否有第二个锁: " + lock2.isAcquiredInThisProcess());
        client.close();
        System.out.println("结束!");
    }
}

读完是否有疑问？不妨留个言一起探讨，探讨！！ 整理自互联网，未知出处，文章略有改动。

yi博说
关注
专栏目录
详解使用Redis SETNX 命令实现分布式锁
09-09
本篇文章主要介绍了详解使用Redis SETNX 命令实现分布式锁，小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
SETNX分布锁详解
热门推荐
qq_47288175的博客
10-21 2万+
SETNX作为分布式锁详解
掌握ZooKeeper的业务使用场景，ZooKeeper如何实现分布式锁
最新发布
程序员-杨胡广的博客
09-12 1193
如果事务T1对数据对象O1加上了排他锁，那么在整个加锁期间，只允许事务T1对O1进行读取和更新操作，其他任何事务都不能再对这个数据对象进行任何类型的操作——直到T1释放了排他锁。如果事务T1对数据对象O1加上了共享锁，那么当前事务只能对O1进行读取操作，其他事务也只能对这个数据对象加共享锁——直到该数据对象上的所有共享锁都被释放。大家有没发现，上面分布式锁的实现方式是排他锁，我们也可以使用共享锁的实现方式，来看看两者的区别。另外共享锁的释放锁和排他锁都是一样的，只需要删除所创建的子节点就可以。
利用Zookeeper实现 - 分布式锁
JAVA葵花宝典
11-03 318
许多场景中，数据一致性是一个比较重要的话题，在单机环境中，我们可以通过Java提供的并发API来解决；而在分布式环境(会遇到网络故障、消息重复、消息丢失等各种问题)下要复杂得多，常见的解...
Redis分布式锁原理解析
Andy86869的博客
08-14 1万+
Redis 分布式锁命令 setnx当且仅当 key 不存在。若给定的 key 已经存在，则 setnx不做任何动作。setnx 是『set if not exists』(如果不存在，则 set)的简写,setnx 具有原子性。 getset先 get 旧值，后set 新值，并返回 key 的旧值(old value），具有原子性。当 key 存在但不是字符串类型时，返回一个错误;当key ...
深入解析 Redis 分布式锁原理
这个人很懒，什么都没有留下。
11-07 1852
深入解析 Redis 分布式锁原理
一文彻底理解ZooKeeper分布式锁的实现原理
01-20
《彻底理解ZooKeeper分布式锁实现原理》 ZooKeeper，简称zk，作为一个高可用的分布式协调服务，常被用于构建分布式系统中的各种组件，如分布式锁。在本篇文章中，我们将深入探讨如何利用Curator这个流行的开源框架...
redis和zookeeper实现分布式锁的区别
01-20
Redis和Zookeeper是两种常用的分布式协调服务，它们都可以用来实现分布式锁，但具体实现方式和特性有所不同。 **Redis分布式锁** Redis作为内存数据库，具有高性能、低延迟的特点，常被用作实现分布式锁。Redis...
zookeeper分布式锁
02-18
Zookeeper分布式锁的工作原理： 1. **会话和临时节点**：Zookeeper支持两种类型的节点，持久节点和临时节点。临时节点在客户端会话失效（例如，客户端崩溃或网络断开）时会被自动删除，这为实现分布式锁提供了一个...
java使用zookeeper实现的分布式锁示例
09-04
在分布式系统中，确保数据的一致性和...这个设计保证了锁的公平性，因为ZooKeeper会按照节点创建的顺序释放锁，而且在节点故障时也能自动清理资源。因此，这个实现对于构建分布式系统中的并发控制具有很高的实用价值。
从Paxos到Zookeeper分布式一致性原理与实践PDF
01-07
《从Paxos到Zookeeper分布式一致性原理与实践》是一本深入探讨分布式系统一致性问题的著作，其中重点讲解了Paxos算法与Zookeeper在实际应用中的理论与实践。Paxos是分布式计算领域中著名的共识算法，为解决分布式...
看一眼就能懂的“分布式锁”原理
chiquanzhe9768的博客
06-10 575
作者：贾俊江 原文：https://mp.weixin.qq.com/s/gQfkOkR80MdtoTBP8hep6w 分布式锁和我们平常讲到的锁原理基本一样，目的就是确保在多个线程并发时，只有一个线程在同一刻操作这个业务或者说方法、变量。 在一个进程中，也就是一个 JV...
redis-setnx-实现原理
cnfly8
04-16 5516
setGenericCommand 方法实现 //setGenericCommand()函数是以下命令: SET, SETEX, PSETEX, SETNX.的最底层实现 //flags 可以是NX或XX，由上面的宏提供 //expire 定义key的过期时间，格式由unit指定 //ok_reply和abort_reply保存着回复client的内容，NX和XX也会改变回复 //如果ok_reply为空，则使用 "+OK" //如果abort_reply为空，则使用 "$-1" void setGen
redis分布式锁实现原理_面试必需要明白的 Redis 分布式锁实现原理！
weixin_39676979的博客
11-26 1263
点击蓝色“架构文摘”关注我哟加个“星标”，每天上午 09:25，干货推送！作者 | Vt来源 |juejin.im/post/5e61a454e51d4526f071e1df谈起redis锁，下面三个，算是出现最多的高频词汇：setnxredLockredissonsetnx其实目前通常所说的setnx命令，并非单指redis的setnx key value这条命令。一般代指redis...
还不知道 Redis 分布式锁的背后原理？还不赶快学习一下
好好学java
04-15 452
前言以前在学校做小项目的时候，用到Redis，基本也只是用来当作缓存。可阿粉在工作中发现，Redis在生产中并不只是当作缓存这么简单。在阿粉接触到的项目中，Redis起到了一个分布式锁的...
redis中setnx命令的底层原理是什么
wwwwwww31311的博客
03-13 1173
该命令的含义是set if not exists,Redis是单线程的，所有的命令都是串行执行的。而且Redis的SETNX操作是原子的，即使有大量的线程同时发送SETNX命令，Redis也会一个接一个地执行这些命令。锁的超时问题，setnx用作锁的时候，必须要设置一个过期时间，防止这个锁无法及时释放造成死锁，且要注意setnx和expired必须是原子性的，如果不能保证原子性，那可能由于线程调度问题expired没有生效，依然会有死锁风险，过期时间设置也要结合实际线上情况，太短会出现问题。
基于redis实现分布式锁(SETNX和Redisson)(以扣减库存来当作案例)
m0_37235955的博客
03-22 1572
一：实现原理： 利用redis中的set命令来实现分布式锁。 从Redis 2.6.12版本开始，set可以使用下列参数： SET KEY VALUE [EX seconds] [PX milliseconds] [NX|XX] EX second ：设置键的过期时间为second秒。 SET key value EX second效果等同于SETEX key second value 。 PX millisecond ：设置键的过期时间为millisecond毫秒。 SET key value PX mi
关于分布式锁原理的一些学习与思考-redis分布式锁，zookeeper分布式锁
diandian9517的博客
03-08 681
首先分布式锁和我们平常讲到的锁原理基本一样，目的就是确保，在多个线程并发时，只有一个线程在同一刻操作这个业务或者说方法、变量。 在一个进程中，也就是一个jvm 或者说应用中，我们很容易去处理控制，在jdk java.util 并发包中已经为我们提供了这些方法去加锁， 比如synchronized 关键字 或者Lock 锁，都可以处理。 但是我们现在的应用程序如果只部署一台服务器...
zookeeper分布式锁原理
09-11
Zookeeper分布式锁原理是利用Zookeeper的节点唯一性和监听机制实现的。当多个客户端同时请求锁时，Zookeeper会创建一个临时有序节点，节点的名称是按照一定规则生成的，同时客户端会监听自己前一个节点的变化情况。...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值