Apache Curator Client

Curator client使用底层的API, 强烈推荐你是用Curator Framework代替使用CuratorZookeeperClient

背景

CuratorZookeeperClient 是ZOoKeeper client的包装类。但是提供了更简单方式, 而且可以减少错误的发生。它提供了下列的特性:

  • 持续的连接管理 - ZooKeeper有很多的关于连接管理的警告(你可以到ZooKeeper FAQ查看细节)。CuratorZookeeperClient 可以自动的管理这些事情。
  • retry - 提供一个方式处理retry。
  • Test ZooKeeper server - 提供一个进程内的ZooKeeper测试服务器用来测试和实验。

方法

MethodDescription
Constructor创建一个给定ZooKeeper集群的连接。 你可以传入一个可选的watcher. 必须提供Retry策略
getZooKeeper()返回管理的ZooKeeper实例. 重要提示: a) 它会花费些许时间等待连接来完成, 在使用其它方法之前你应该校验连接是否完成. b) 管理的ZooKeeper实例可以根据特定的事件而改变。 不要持有实例太长时间. 总是调用getZooKeeper()得到一个新的实例.
isConnected()返回ZooKeeper client当前连接状态
blockUntilConnectedOrTimedOut()block知道连接成功或者超时
close()关闭连接
setRetryPolicy()改变retry策略
newRetryLoop()分配一个新的Retry Loop - 详情看下边

Retry Loop

由于各种各样的原因, 在zookeeper集群上的操作难免遇到失败的情况。最佳实践表明应该提供重试机制。Retry Loop 为此而生。 每个操作都被包装在一个Retry Loop中。下面是一个典型的处理流程:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
RetryLoop retryLoop = client.newRetryLoop();
while ( retryLoop.shouldContinue() )
{
try
{
// perform your work
...
// it's important to re\-get the ZK instance as there may have been an error and the instance was re\-created
ZooKeeper zk = client.getZookeeper();
retryLoop.markComplete();
}
catch ( Exception e )
{
retryLoop.takeException(e);
}
}

Retry Loop维护一定数量的retry, 它还决定一个错误是否可以要执行retry。 假如一个错误需要retry,Retry策略被调用来决定retry是要要执行,执行多少次才放弃。
很方便地,RetryLoop 提供了一个静态方法使用Callable来执行一个完整retry loop。

1
2
3
4
5
6
7
8
9
RetryLoop.callWithRetry(client, new Callable<Void>()
{
@Override
public Void call() throws Exception
{
// do your work here - it will get retried if needed
return null;
}
});

Retry策略

retry策略可以改变retry的行为。 它抽象出RetryPolicy接口, 包含一个方法public boolean allowRetry(int retryCount, long elapsedTimeMs);。 在retry被尝试执行前, allowRetry()被调用,并且将当前的重试次数和操作已用时间作为参数. 如果返回true, retry被执行。否则异常被抛出。
Curator本身提供了几个策略(在 com.netflix.curator.retry 包下):

Policy NameDescription
ExponentialBackoffRetry重试一定次数,每次重试sleep更多的时间
RetryNTimes重试N次
RetryOneTime重试一次
RetryUntilElapsed重试一定的时间

原文