公么吃奶摸下面好舒服

发布日期:2022-06-18 17:03    点击次数:174

从Curator美满分手式锁的源码再到羊群效应

一、媒介

Curator是一款由Java编写的,操作Zookeeper的客户端器具,在其里面封装了分手式锁、选举等高等功能。

今上帝如若分析其美满分手式锁的主要旨趣,关连分手式锁的一些先甘心其他美满,有敬爱的同学不错翻阅以下著述:

我用了上万字,走了一遍Redis美满分手式锁的崎岖之路,从单机到主从再到多实例,原本会发生这样多的问题_阳阳的博客-CSDN博客

Redisson可重入与锁续期源码分析_阳阳的博客-CSDN博客

在使用Curator获取分手式锁时,Curator会在指定的path下创建一个有序的临时节点,如果该节点是最小的,则代表获取锁顺利。

接下来,在准备责任中,咱们不错洞悉是否会创建出一个临时节点出来。

二、准备责任

最初咱们需要搭建一个zookeeper集群,天然你使用单机也行。

在这篇著述口试官:能给我画个Zookeeper选举的图吗?,先容了一种使用docker-compose花式快速搭建zk集群的花式。

在pom中引入依赖:

<dependency>          <groupId>org.apache.curator</groupId>          <artifactId>curator-recipes</artifactId>          <version>2.12.0</version>      </dependency

 Curator客户端真实立项:

/**  * @author qcy  * @create 2022/01/01 22:59:34  */ @Configuration public class CuratorFrameworkConfig {      //zk各节点地址     private static final String CONNECT_STRING = "localhost:2181,localhost:2182,localhost:2183";     //联贯超往往间(单元:毫秒)     private static final int CONNECTION_TIME_OUT_MS = 10 * 1000;     //会话超往往间(单元:毫秒)     private static final int SESSION_TIME_OUT_MS = 30 * 1000;     //重试的动手恭候时候(单元:毫秒)     private static final int BASE_SLEEP_TIME_MS = 2 * 1000;     //最大重试次数     private static final int MAX_RETRIES = 3;      @Bean     public CuratorFramework getCuratorFramework() {         CuratorFramework curatorFramework = CuratorFrameworkFactory.builder()                 .connectString(CONNECT_STRING)                 .connectionTimeoutMs(CONNECTION_TIME_OUT_MS)                 .sessionTimeoutMs(SESSION_TIME_OUT_MS)                 .retryPolicy(new ExponentialBackoffRetry(BASE_SLEEP_TIME_MS, MAX_RETRIES))                 .build();         curatorFramework.start();         return curatorFramework;     }      } 

 SESSION_TIME_OUT_MS参数则会保证,在某个客户端获取到锁之后短暂宕机,zk能在该时候内删除现时客户端创建的临时有序节点。

测试代码如下:

//临时节点旅途,qcy是博主名字缩写哈    private static final String LOCK_PATH = "/lockqcy";     @Resource    CuratorFramework curatorFramework;     public void testCurator() throws Exception {        InterProcessMutex interProcessMutex = new InterProcessMutex(curatorFramework, LOCK_PATH);        interProcessMutex.acquire();         try {            //模拟业务耗时            Thread.sleep(30 * 1000);        } catch (Exception e) {            e.printStackTrace();        } finally {            interProcessMutex.release();        }    } 

 当使用接口调用该局面时,在Thread.sleep处打上断点,干预到zk容器中洞悉创建出来的节点。

使用 docker exec -it zk容器名 /bin/bash 以交互模式干预容器,接着使用 ./bin/zkCli.sh 联贯到zk的server端。

然后使用 ls path 检讨节点

这三个节点都是经久节点,不错使用 get path 检讨节点的数据结构信息

若一个节点的ephemeralOwner值为0,即该节点的临时领有者的会话id为0,则代表该节点为经久节点。

当走到断点Thread.sleep时,如实发面前lockqcy下创建出来一个临时节点

​到这里吗,准备责任还是做完了,接下来分析interProcessMutex.acquire与release的经过

三、源码分析

Curator营救多种类型的锁,举例

InterProcessMutex,可重入锁排它锁 InterProcessReadWriteLock,读写锁 InterProcessSemaphoreMutex,不成重入排它锁

今上帝如若分析InterProcessMutex的加解锁过程,先看加锁过程

加锁
public void acquire() throws Exception {       if (!internalLock(-1, null)) {           throw new IOException("Lost connection while trying to acquire lock: " + basePath);       }   } 

 这里是遏止式获取锁,获取不到锁,就一直进行遏止。是以对于internalLock局面,超往往间开荒为-1,时候单元开荒成null。

private boolean internalLock(long time, TimeUnit unit) throws Exception {        Thread currentThread = Thread.currentThread();        //通过能否在map中取到该线程的LockData信息,来判断该线程是否还是持有锁        LockData lockData = threadData.get(currentThread);        if (lockData != null) {            //进行可重入,平直复返加锁顺利            lockData.lockCount.incrementAndGet();            return true;        }        //进行加锁        String lockPath = internals.attemptLock(time, unit, getLockNodeBytes());        if (lockPath != null) {            //加锁顺利,保存到map中            LockData newLockData = new LockData(currentThread, lockPath);            threadData.put(currentThread, newLockData);            return true;        }         return false;    } 

其中threadData是一个map,key线程对象,value为该线程绑定的锁数据。

LockData中保存了加锁线程owningThread,重入计数lockCount与加锁旅途lockPath,举例

/lockqcy/_c_c46513c3-ace0-405f-aa1e-a531ce28fb47-lock-0000000005 
private final ConcurrentMap<Thread, LockData> threadData = Maps.newConcurrentMap();      private static class LockData {         final Thread owningThread;         final String lockPath;         final AtomicInteger lockCount = new AtomicInteger(1);          private LockData(Thread owningThread, String lockPath) {             this.owningThread = owningThread;             this.lockPath = lockPath;         }     } 

 干预到internals.attemptLock局面中

String attemptLock(long time, TimeUnit unit, byte[] lockNodeBytes) throws Exception {       //动手时候       final long startMillis = System.currentTimeMillis();       //将超往往间斡旋滑化为毫秒单元       final Long millisToWait = (unit != null) ? unit.toMillis(time) : null;       //节点数据,这里为null       final byte[] localLockNodeBytes = (revocable.get() != null) ? new byte[0] : lockNodeBytes;       //重试次数       int retryCount = 0;       //锁旅途       String ourPath = null;       //是否获取到锁       boolean hasTheLock = false;       //是否完成       boolean isDone = false;        while (!isDone) {           isDone = true;            try {               //创建一个临时有序节点,并复返节点旅途               //里面调用client.create().creatingParentContainersIfNeeded().withProtection().withMode(CreateMode.EPHEMERAL_SEQUENTIAL).forPath(path);               ourPath = driver.createsTheLock(client,
国模丰满少妇私拍 path, localLockNodeBytes);               //依据复返的节点旅途,判断是否抢到了锁               hasTheLock = internalLockLoop(startMillis, millisToWait, ourPath);           } catch (KeeperException.NoNodeException e) {               //在会话逾期时,可能导致driver找不到临时有序节点,从而抛出NoNodeException               //这里就进行重试               if (client.getZookeeperClient().getRetryPolicy().allowRetry(retryCount++, System.currentTimeMillis() - startMillis, RetryLoop.getDefaultRetrySleeper())) {                   isDone = false;               } else {                   throw e;               }           }       }       //获取到锁,则复返节点旅途,供调用方纪录到map中       if (hasTheLock) {           return ourPath;       }        return null;   } 

 接下来,将会在internalLockLoop中哄骗刚才创建出来的临时有序节点,判断是否获取到了锁。

private boolean internalLockLoop(long startMillis, Long millisToWait, String ourPath) throws Exception {        //是否获取到锁        boolean haveTheLock = false;        boolean doDelete = false;        try {            if (revocable.get() != null) {                //现时不会干预这里                client.getData().usingWatcher(revocableWatcher).forPath(ourPath);            }            //一直尝试获取锁            while ((client.getState() == CuratorFrameworkState.STARTED) && !haveTheLock) {                //复返basePath(这里是lockqcy)下整个的临时有序节点,况且按照后缀从小到大罗列                List<String> children = getSortedChildren();                //取出现时列程创建出来的临时有序节点的称号,这里便是/_c_c46513c3-ace0-405f-aa1e-a531ce28fb47-lock-0000000005                String sequenceNodeName = ourPath.substring(basePath.length() + 1);                //判断现时节点是否处于排序后的首位,如果处于首位,则代表获取到了锁                PredicateResults predicateResults = driver.getsTheLock(client, children, sequenceNodeName, maxLeases);                if (predicateResults.getsTheLock()) {                    //获取到锁之后,则圮绝轮回                    haveTheLock = true;                } else {                    //这里代表莫得获取到锁                    //获取比现时节点索引小的前一个节点                    String previousSequencePath = basePath + "/" + predicateResults.getPathToWatch();                     synchronized (this) {                        try {                            //如果前一个节点不存在,则平直抛出NoNodeException,catch中不进行处理,不才一轮中链接获取锁                            //如果前一个节点存在,则给它开荒一个监听器,监听它的开释事件                            client.getData().usingWatcher(watcher).forPath(previousSequencePath);                            if (millisToWait != null) {                                millisToWait -= (System.currentTimeMillis() - startMillis);                                startMillis = System.currentTimeMillis();                                //判断是否超时                                if (millisToWait <= 0) {                                    //获取锁超时,删除刚才创建的临时有序节点                                    doDelete = true;                                    break;                                }                                //没超时的话,公么吃奶摸下面好舒服在millisToWait内进行恭候                                wait(millisToWait);                            } else {                                //无穷期遏止恭候,监听到前一个节点被删除时,才会触发叫醒操作                                wait();                            }                        } catch (KeeperException.NoNodeException e) {                            //如果前一个节点不存在,则平直抛出NoNodeException,catch中不进行处理,不才一轮中链接获取锁                        }                    }                }            }        } catch (Exception e) {            ThreadUtils.checkInterrupted(e);            doDelete = true;            throw e;        } finally {            if (doDelete) {                //删除刚才创建出来的临时有序节点                deleteOurPath(ourPath);            }        }        return haveTheLock;    } 

 判断是否获取到锁的中枢逻辑位于getsTheLock中

public PredicateResults getsTheLock(CuratorFramework client, List<String> children, String sequenceNodeName, int maxLeases) throws Exception {      //获取现时节点在整个子节点排序后的索引位置      int ourIndex = children.indexOf(sequenceNodeName);      //判断现时节点是否处于子节点中      validateOurIndex(sequenceNodeName, ourIndex);      //InterProcessMutex的构造局面,会将maxLeases动手化为1      //ourIndex必须为0,才智使得getsTheLock为true,也便是说,现时节点必须是basePath下的最末节点,才智代表获取到了锁      boolean getsTheLock = ourIndex < maxLeases;      //如果获取不到锁,则复返上一个节点的称号,用作对其开荒监听      String pathToWatch = getsTheLock ? null : children.get(ourIndex - maxLeases);       return new PredicateResults(pathToWatch, getsTheLock);  }   static void validateOurIndex(String sequenceNodeName, int ourIndex) throws KeeperException {      if (ourIndex < 0) {          //可能会由于联贯丢失导致临时节点被删除,因此这里属于保障秩序          throw new KeeperException.NoNodeException("Sequential path not found: " + sequenceNodeName);      }  } 

 那什么时候,在internalLockLoop处于wait的线程能被叫醒呢?

在internalLockLoop局面中,还是使用

client.getData().usingWatcher(watcher).forPath(previousSequencePath); 

给前一个节点开荒了监听器,当该节点被删除时,将会触发watcher中的回调

private final Watcher watcher = new Watcher() {         //回调局面         @Override         public void process(WatchedEvent event) {             notifyFromWatcher();         }     };      private synchronized void notifyFromWatcher() {         //叫醒是以在LockInternals实例上恭候的线程         notifyAll();     } 

 到这里,基本上还是分析完加锁的过程了,在这里转头下:

最初创建一个临时有序节点

如果该节点是basePath下最末节点,则代表获取到了锁,存入map中,下次平直进行重入。

如果该节点不是最末节点,则对前一个节点开荒监听,接着进行wait恭候。现时一个节点被删除时,将会告知notify该线程。

解锁

解锁的逻辑,就比拟浅易了,平直干预release局面中

public void release() throws Exception {       Thread currentThread = Thread.currentThread();       LockData lockData = threadData.get(currentThread);       if (lockData == null) {           throw new IllegalMonitorStateException("You do not own the lock: " + basePath);       }        int newLockCount = lockData.lockCount.decrementAndGet();       //平直减少一次重入次数       if (newLockCount > 0) {           return;       }       if (newLockCount < 0) {           throw new IllegalMonitorStateException("Lock count has gone negative for lock: " + basePath);       }        //到这里代表重入次数为0       try {           //开释锁           internals.releaseLock(lockData.lockPath);       } finally {           //从map中移除           threadData.remove(currentThread);       }   }    void releaseLock(String lockPath) throws Exception {       revocable.set(null);       //里面使用guaranteed,会在后台箝制尝试删除节点       deleteOurPath(lockPath);   } 

 重入次数大于0,就减少重入次数。当减为0时,调用zk去删除节点,这极少和Redisson可重入锁开释时一致。

四、羊群效应

在这里谈谈使用Zookeeper美满分手式锁场景中的羊群效应

什么是羊群效应

最初,羊群是一种很错落的组织,漫无有筹划,贫乏管制,一般需要牧羊犬来匡助主人限定羊群。

某个时候,当其中一只羊发现前边有愈加厚味的草而动起来,就会导致其余的羊一哄而起,压根岂论周围的情况。

是以羊群效应,指的是一个人在进行感性的看成后,导致其余人平直投降,产生非感性的从众看成。

而Zookeeper中的羊群效应,则是指一个znode被变调后,触发了多半本不错被幸免的watch告知,形成集群资源的构陷。

获取不到锁时的恭候演化 sleep一段时候

如果某个线程在获取锁失败后,十足不错sleep一段时候,再尝试获取锁。

但这样的花式,完了极低。

sleep时候短的话,会粗俗地进行轮询,构陷资源。

sleep时候长的话,会出现锁被开释但仍然获取不到锁的莫名情况。

是以,这里的优化点,在于奈何变主动轮询为异步告知。

watch被锁住的节点

整个的客户端要获取锁时,只去创建一个同名的node。

当znode存在时,这些客户端对其开荒监听。当znode被删除后,告知整个恭候锁的客户端,接着这些客户端再次尝试获取锁。

固然这里使用watch机制来异步告知,但是当客户端的数目相等多时,会存在性能低点。

当znode被删除后,在这刹那间,需要给多半的客户端发送告知。在此时代,其余提交给zk的平时请求可能会被蔓延偶然遏止。

这就产生了羊群效应,一个点的变化(znode被删除),形成了全面的影响(告知多半的客户端)。

是以,这里的优化点,在于奈何减少对一个znode的监听数目,最佳的情况是只须一个。

watch前一个有序节点

如果先指定一个basePath,想要获取锁的客户端,平直在该旅途下创建临时有序节点。

当创建的节点是最末节点时,代表获取到了锁。如果不是最小的节点,则只对前一个节点开荒监听器,只监听前一个节点的删除看成。

这样前一个节点被删除时,只会给下一个节点代表的客户端发送告知,不会给整个客户端发送告知,从而幸免了羊群效应。

​在幸免羊群效应的同期,使恰现时锁成为平正锁。即按照肯求锁的先后章程获取锁,幸免存在饥饿过度的线程。

五、后语

本文从源码角度西宾了使用Curator获取分手式锁的经过,接着从恭候锁的演化过程角度启程,分析了Zookeeper在分手式锁场景下幸免羊群效应的科罚决策。

这是Zookeeper系列的第二篇,对于其watch旨趣分析、zab条约等著述也在安排的路上了。

 





Powered by 东北女人毛多水多牲交视频 @2013-2022 RSS地图 HTML地图