码迷,mamicode.com
首页 > 其他好文 > 详细

ZK分布式锁(未完 待续)

时间:2018-05-01 20:32:27      阅读:194      评论:0      收藏:0      [点我收藏+]

标签:second   无法   失效   tst   code   UI   空间   可重入   说明   

实现思路

公平锁:创建有序节点,判断本节点是不是序号最小的节点(第一个节点),若是,则获取锁;若不是,则监听比该节点小的那个节点的删除事件。

非公平锁:直接尝试在指定path下创建节点,创建成功,则说明该节点抢到锁了。如果创建失败,则监听锁节点的删除事件,或者sleep一段时间后再重试。

可重入:使用ThreadLocal记录加锁客户端的唯一标识。重复时先从ThreadLocal获取,获取到,这认为加锁成功,直接返回。

使用瞬时节点创建可重入公平锁

使用瞬时节点的好处是当Session失效时,该节点将被清理,从而避免使用持久节点加锁成功后,抛异常或宕机或服务器重启等原因造成的锁无法释放问题。

使用curator实现

// 假设需要加锁的订单Id
private static String orderId = "157146671409578219";
// 工程名
private static String appName = "trade_";
// 此次加锁业务处理逻辑描述
private static String operatorDesc = "updateTrade_";

// 部门,每个部门可以有自己的zk空间目录
private static String department = "zfpt" ;

// 锁前缀 应该根据业务 具有唯一性
private static String lockPrefixKey = "/" + appName + operatorDesc ;

/**
 * 每个线程 创建自己的Connection ,创建自己的Session
 */
@Test
public void curator() throws Exception {

    for (int i = 0 ; i < 100 ; i++) {

        Thread currentThread = new Thread(() -> {

            // 创建Connection
            CuratorFramework client = CuratorFrameworkFactory.builder()
                    .connectString("master:2181,slave1:2181,slave2:2181")
                    .retryPolicy(new RetryOneTime(1000)) //重试策略
                    .namespace(department) // 可以设置自己部门缩写
                    .build();
            client.start();

            // 模拟对同一个订单加锁
            InterProcessMutex lock = new InterProcessMutex(client, lockPrefixKey + orderId);

            try {
                // 一直尝试加锁 直到锁可用。 有点像synchronized
                // lock.acquire();
                if(lock.acquire(1, TimeUnit.SECONDS)) {
                    System.out.println(Thread.currentThread().getName() + " 抢到锁");
                } else {
                    System.out.println(Thread.currentThread().getName() + "超时没有抢到锁");
                }
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                try {
                    // 如果当前线程获得到锁,则释放锁
                    if(lock.isAcquiredInThisProcess()) {
                        System.out.println(Thread.currentThread().getName() + " 释放锁");
                        lock.release();
                    } else {
                        System.out.println(Thread.currentThread().getName() + " 没有抢到锁,故没有释放锁");
                    }
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        });
        currentThread.setName("Lock【" + i + "】");
        currentThread.start();
    }

    Thread.sleep(Integer.MAX_VALUE);
}

实现原理:
因为ZK不允许在临时节点下创建子节点,所以InterProcessMutex工具类会根据加锁传入path的(也就是案例中的lockPrefixKey + orderId)创建一个持久节点;然后在这个持久节点下创建瞬时节点,创建成功后,对该持久节点下的全部子节点进行降序排序,判断当前节点是否是第一个节点,如果是则获取锁,否则对前一个节点加上监听事件。然后Object.wait(),当监听事件被触发,则会调用notifyAll方法,对等待线程进行唤醒。再次尝试获取锁。

缺点:

  1. 传入的加锁节点会被创建为永久节点(就是lockPrefixKey + orderId),这样zk节点数量将会急速递增。
  2. 临时节点不稳定:一个客户端加锁成功后,可能会因为网络抖动等原因导致Session断开,该客户端创建的临时节点被清理,导致另外一节正在监听的客户端加锁成功,同时进行操作。

使用持久节点创建可重入公平锁

上文提到的临时节点不稳定,父节点为永久节点无法释放问题。我的拙见是:

  1. 使用持久节点代替临时节点:释放锁的时候删除自己创建的加锁节点。
  2. 父节点为永久节点无法释放:可以在每个客户端释放锁的时候进行判断,如果自己是最后一个节点,则删除父节点。
  3. 但是需要考虑的问题:客户端加锁成功后,宕机或重启或者其他极端异常情况,无法删除加锁节点。最后一个加锁节点同样异常,也无法删除父节点。这时,可以给每个锁加过期时间,过期失效。由于zk没有提供过期自动清理,所以可以在第二次访问该节点的时候 先进行判断,判断失效先删除再创建。如果没有第二次访问的节点 可以依靠定时任务进行节点清理。

ZK分布式锁(未完 待续)

标签:second   无法   失效   tst   code   UI   空间   可重入   说明   

原文地址:https://www.cnblogs.com/boothsun/p/8976829.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!