Curator client使用底层的API, 强烈推荐你是用Curator Framework代替使用CuratorZookeeperClient
背景
CuratorZookeeperClient 是ZOoKeeper client的包装类。但是提供了更简单方式, 而且可以减少错误的发生。它提供了下列的特性:
- 持续的连接管理 - ZooKeeper有很多的关于连接管理的警告(你可以到ZooKeeper FAQ查看细节)。CuratorZookeeperClient 可以自动的管理这些事情。
- retry - 提供一个方式处理retry。
- Test ZooKeeper server - 提供一个进程内的ZooKeeper测试服务器用来测试和实验。
方法
Method | Description |
---|---|
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中。下面是一个典型的处理流程:
|
|
Retry Loop维护一定数量的retry, 它还决定一个错误是否可以要执行retry。 假如一个错误需要retry,Retry策略被调用来决定retry是要要执行,执行多少次才放弃。
很方便地,RetryLoop 提供了一个静态方法使用Callable来执行一个完整retry loop。
|
|
Retry策略
retry策略可以改变retry的行为。 它抽象出RetryPolicy接口, 包含一个方法public boolean allowRetry(int retryCount, long elapsedTimeMs);
。 在retry被尝试执行前, allowRetry()被调用,并且将当前的重试次数和操作已用时间作为参数. 如果返回true, retry被执行。否则异常被抛出。
Curator本身提供了几个策略(在 com.netflix.curator.retry 包下):
Policy Name | Description |
---|---|
ExponentialBackoffRetry | 重试一定次数,每次重试sleep更多的时间 |
RetryNTimes | 重试N次 |
RetryOneTime | 重试一次 |
RetryUntilElapsed | 重试一定的时间 |