1 简介
Curator是Netflix公司开源的一套Zookeeper客户端框架。了解过Zookeeper原生API都会清楚其复杂度。Curator帮助我们在其基础上进行封装、实现一些开发细节，包括接连重连、反复注册Watcher和NodeExistsException等。目前已经作为Apache的顶级项目出现，是最流行的Zookeeper客户端之一。从编码风格上来讲，它提供了基于Fluent的编程风格支持。除此之外，Curator还提供了Zookeeper的各种应用场景：Recipe、共享锁服务、Master选举机制和分布式计数器等。
2 依赖
项目在GitHub上的开源地址随着从Netflix转移到Apache也发生了变化。地址为：https://github.com/apache/curator。我在实际操作中选取如下的版本：
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-recipes</artifactId>
<version>4.0.1</version>
</dependency>3 创建客户端
在curator中，CuratorFramework表示zk的客户端。curator提供了如下的两种方式去创建：
public static CuratorFramework newClient(String connectString, RetryPolicy retryPolicy) {
return newClient(connectString, DEFAULT_SESSION_TIMEOUT_MS,
DEFAULT_CONNECTION_TIMEOUT_MS, retryPolicy);
}
public static CuratorFramework newClient(String connectString, int sessionTimeoutMs, int
connectionTimeoutMs, RetryPolicy retryPolicy) {
return builder()
.connectString(connectString)
.sessionTimeoutMs(sessionTimeoutMs)
.connectionTimeoutMs(connectionTimeoutMs)
.retryPolicy(retryPolicy).build();
}该方法newClient()是CuratorFrameworkFactory的方法，通过工场的方式去创建。connectString表示连接zookeeper的地址，retryPolicy表示重连策略。ExponentialBackoffRetry实现了该接口。
RetryPolicy retryPolicy=new ExponentialBackoffRetry(1000,3);第一个参数表示休眠多长时间再次重连。第二个参数表示重连的次数。如下的代码就是新建了一个会话：
public CuratorFramework getZKClient(){
/**
* baseSleepTimeMs 休眠1s后重连
* maxRetries 重连的最大次数
*/
RetryPolicy retryPolicy=new ExponentialBackoffRetry(1000,3);
return CuratorFrameworkFactory.newClient("127.0.0.1:2182", retryPolicy);
}4 创建节点测试
使用create创建节点，默认创建的是永久节点，value为机器的ip
public void createNode(){
CuratorFramework client = getZKClient();
client.start();
try {
client.create().forPath("/curator");
} catch (Exception e) {
e.printStackTrace();
}
}
大家可以看到我的验证结果。
5 获取数据和更新数据
public void getData(){
CuratorFramework client = getZKClient();
client.start();
// 包含状态查询
Stat stat = new Stat();
try {
/**
* 查询数据
* 普通查询
* 状态查询
*/
byte[] bytes = client.getData().forPath("/curator");
byte[] bytes1 = client.getData().storingStatIn(stat).forPath("/curator");
/**
* 更新数据
* 普通更新
* 指定版本更新
*/
Stat stat1 = client.setData().forPath("/curator", "新内容".getBytes());
Stat stat2 = client.setData().withVersion(1).forPath("/curator");
System.out.println(new String(bytes));
System.out.println(new String(bytes1));
System.out.println(stat1);
System.out.println(stat2);
} catch (Exception e) {
e.printStackTrace();
}
}6 Curator分布式锁之生成流水号
在分布式系统中，为了保证数据的一致性，往往需要进行同步控制，比如减库存、唯一流水号生成等。Curator对Zookeeper进行了封装，实现了分布式锁的功能，提供了线程的同步控制。同时，Curator也提供了多种锁机制。下面对通过时间戳生成流水号的场景进行逐步分析。
代码通过一个循环连续打印出10个时间戳。这里没有使用多线程，但分析下面的打印结果就会发现，其实在同一时刻会生成多个相同的流水号，运行时间在毫秒级别。
public static void main(String[] args) {
for(int i=0; i< 10; i++){
SimpleDateFormat sdf = new SimpleDateFormat("yyyyDDmm HH:mm:ss|SSS");
String orderNo = sdf.format(new Date());
System.out.println(orderNo);
}
}结果如下：
201831413 16:13:10|794
201831413 16:13:10|796
201831413 16:13:10|796
201831413 16:13:10|797
201831413 16:13:10|797
201831413 16:13:10|797
201831413 16:13:10|797
201831413 16:13:10|797
201831413 16:13:10|798
201831413 16:13:10|798
观察上述生成的时间流水号，10个流水号，但是只有794,796,797,798。这四个，其余的都是重复的。上面生成的流水号重复的可能性不大，一旦出现高并发，那么重复的订单号就会大量出现，当然也有其他方案进行解决，本篇文章就不再进行讨论。下说说如何通过分布式锁来解决此问题。
分布式锁示例
下面的代码利用Curator的分布式锁来实现在同一时刻只会生成一个唯一的流水号。
public class ZKLock {
/** 节点名称*/
private static final String path = "/lock_path";
public static void main(String[] args) {
/** 获取客户端*/
CuratorFramework client = getClient();
/** 获取分布式锁*/
InterProcessMutex lock = new InterProcessMutex(client,path);
/** 单个线程开始执行程序*/
final CountDownLatch countDownLatch = new CountDownLatch(1);
final long startTime = new Date().getTime();
for(int i=0;i<10;i++){
new Thread(new Runnable() {
@Override
public void run() {
try {
countDownLatch.await();
/** 获取锁*/
lock.acquire();
} catch (InterruptedException e) {
e.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
}
SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMdd HH:mm:ss|SSS");
System.out.println(sdf.format(new Date()));
/** 释放锁*/
try {
lock.release();
} catch (Exception e) {
e.printStackTrace();
}
System.out.println("显示此线程大概花费时间（等待+执行）:" + (new Date().getTime() - startTime) + "ms");
}
}).start();
}
System.out.println("创建线程花费时间:" + (new Date().getTime() - startTime) + "ms");
countDownLatch.countDown();
}
private static CuratorFramework getClient() {
RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
CuratorFramework client = CuratorFrameworkFactory.builder()
.connectString("127.0.0.1:2182")
.retryPolicy(retryPolicy)
.sessionTimeoutMs(6000)
.connectionTimeoutMs(3000)
.namespace("demo")
.build();
client.start();
return client;
}
}
打印结果为：
创建线程花费时间:2ms
20181110 16:33:31|776
显示此线程大概花费时间（等待+执行）:374ms
20181110 16:33:31|796
显示此线程大概花费时间（等待+执行）:394ms
20181110 16:33:31|814
显示此线程大概花费时间（等待+执行）:404ms
20181110 16:33:31|829
显示此线程大概花费时间（等待+执行）:419ms
20181110 16:33:31|841
显示此线程大概花费时间（等待+执行）:434ms
20181110 16:33:31|858
显示此线程大概花费时间（等待+执行）:449ms
20181110 16:33:31|874
显示此线程大概花费时间（等待+执行）:472ms
20181110 16:33:31|895
显示此线程大概花费时间（等待+执行）:485ms
20181110 16:33:31|905
显示此线程大概花费时间（等待+执行）:493ms
20181110 16:33:31|912
显示此线程大概花费时间（等待+执行）:502ms仔细观察可发现，通过多线程的访问，打印的时间戳却是唯一的。这里使用InterProcessMutex类来进行处理分布式锁，实现了一个生产唯一流水号的功能。
注意事项
在上面的代码中，打印了每步操作的时间，其中访问的zookeeper服务器是远程服务器。从打印的时间我们可以看出，通过这种方式生成唯一流水号并不能支撑很大的并发量。每次操作都需要通过网络访问，zookeeper的节点操作等，会花费大量的时间。另外，由于精确到毫秒，因此一秒钟最多也只能处理999个请求。
同时，在分布式环境中上面的示例还是会出现重复的可能性的，比如两个服务器的时间不一致，即两个服务器相差10ms，恰好第一个执行完，第二个执行的间隙也是10ms，那么第二个生成的订单号还是有可能跟第一个重复的，虽然这种概率及其小。
以上通过示例演示了Curator的分布式锁功能，根据具体的业务需求可选择不同的业务场景来使用。
参考：https://blog.csdn.net/wo541075754/article/details/71173552