【Zookeeper】典型使用场景实战

公平锁 互斥锁

【Zookeeper】典型使用场景实战_第1张图片

InterProcessMutex

acquire

【Zookeeper】典型使用场景实战_第2张图片

  • attemptLock 加锁
    • createsTheLock() 创建节点

      • 创建父节点是容器节点,这样这个节点的所有子节点都被删除后,它就会被删除
      • 子节点是临时顺序结点

      【Zookeeper】典型使用场景实战_第3张图片

    • internalLockLoop() 判断刚刚创建的节点是不是序号最小的

      • 获取所有子节点并排序
      • getsTheLock 看当前节点是不是最小的
        【Zookeeper】典型使用场景实战_第4张图片
      • 不是最小的就去监听前一个结点

【Zookeeper】典型使用场景实战_第5张图片

Zookeeper和redis分布式锁比较

redis是主从模式,当主机宕机后重新从从机里选举新的主机后,有一段数据不一致性。
那如果线程A在原来的主机加锁setnx ccc成功,而新的主机没有ccc这个key,线程B在新的setnx ccc也会成功。这样就有两个线程都获取到了锁。

Zookeeper不是主从模式,他的Leader和Follower的数据是保持一致的,所以不存在redis的问题。

Zookeeper的写性能没有redis好。

幽灵节点的规避

幽灵结点是指当客户端创建节点成功后,没有收到服务端的回应,也就是客户端不知道自己已经成功创建了节点。
这样就又会尝试创建新的结点,那之前创建的结点就是幽灵结点了。

Zookeeper规避的方式就是创建的时候给前面加一个uuid,客户端去创建节点的时候会先按这个uuid找。有的话就不会再创建。
在这里插入图片描述

共享锁

【Zookeeper】典型使用场景实战_第6张图片

写锁前面一定不能有读和写的操作他才能执行,所以要对前一个节点进行监听。

读锁前面不能有写锁,所以要对前面的写锁进行监听。

InterProcessReadWriteLock

Leader选举

通过分布式锁选举,谁拿到锁谁就是Leader 然后执行,执行完后把锁释放又选取新的Leader一直这样循环。
【Zookeeper】典型使用场景实战_第7张图片

【Zookeeper】典型使用场景实战_第8张图片

注册中心

Zookeeper作为注册中心,有新的User-Service就在/UserService下创建一个临时节点。
其他服务只用得到/userService的所有子节点就知道怎么去访问User-Service,对/UserService进行监听,有变动就重新获取这些子节点
【Zookeeper】典型使用场景实战_第9张图片

你可能感兴趣的:(Zookeeper,Zookeeper分布式锁,注册中心,Leader选举)