一、Zookeeper分布式锁原理
核心思想:当客户端要获取锁,则创建节点,使用玩锁,就删除该节点!
1.客户端获取到锁,在lock节点下创建临时顺序节点。(避免了宕机问题)
2.然后获取到lock下面的所有子节点,客户端获取到所有子节点之后,如果发现自己创建的子节点序号最小,那么就认为该客户端获取到了锁。使用完锁后,就将该节点删除。
3.如果发现自己创建的节点,并非lock所有子节点中最小的,说明自己还没有获取到锁,此时客户端需要找到比自己小的那个节点,同时对其注册事件监听器,监听删除事件。
4.如果发现比自己小的那个节点被删除,则客户端的Watcher会收到相应通知,此时再次判断自己创建的节点是否是lock子节点中序号最小的,如果是则获取到了锁,如果不是则重复以上步骤继续获取到比自己小的一个节点并注册监听。
二、没加锁的卖票代码
class Ticket implements Runnable{
private int tickets = 10;//总票数
@Override
public void run() {
while (true) {
if (tickets > 0) {
System.out.println(Thread.currentThread()+":"+tickets--);
}
}
}
}
//测试类
public class LockTest {
public static void main(String[] args) {
Ticket ticket = new Ticket();
//创建客户端
new Thread(ticket, "携程").start();
new Thread(ticket, "飞猪").start();
new Thread(ticket,"12306").start();
}
}
从结果就能看出,存在一张票被重复购买的现象!虽然此时使用jvm级别的锁比如sychronized即可解决单机的线程不安全情况。但往往实际开发中用到的是服务器集群环境,这时候加jvm级别的锁是不能阻塞其他机器发送的请求。具体的解决方法请看下面!
三、Java API 操作
在Curator中有五种锁方案:
- InterProcessSemaphoreMutex:分布式排它锁(非可重入锁)
- InterProcessMutex:分布式可重入排它锁
- InterProcessReadWriteLock:分布式读写锁
- InterProcessMultiLock:将多个锁作为单个实体管理的容器
- InterProcessSemaPhoreV2:共享信号量
针对上面的提出的卖票程序,我们需要重新编写 Ticket 类,为其加上一个分布式锁即可解决:
public class Ticket implements Runnable{
private int tickets = 10;//总票数
private InterProcessMutex lock;
public Ticket(){
RetryPolicy retryPolicy = new ExponentialBackoffRetry(3000, 10);
CuratorFramework client = CuratorFrameworkFactory.builder().connectString("122.36.76.113:2181")
.sessionTimeoutMs(60 * 1000)
.connectionTimeoutMs(15 * 1000)
.retryPolicy(retryPolicy)
.build();
client.start();
lock = new InterProcessMutex(client,"/lock");
}
@Override
public void run() {
while (true) {
try {
//获取锁
lock.acquire(3, TimeUnit.SECONDS);
if (tickets > 0) {
System.out.println(Thread.currentThread() + ":" + tickets--);
}
} catch (Exception e) {
e.printStackTrace();
} finally {
//释放锁
try {
lock.release();
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
}
以下图片可以证明出,Zookeeper分布式锁的核心是创建临时顺序节点!