Zookeeper开源客户端框架Curator简介

最新推荐文章于 2024-09-08 20:38:08 发布
最新推荐文章于 2024-09-08 20:38:08 发布
阅读量568 收藏
点赞数
分类专栏： JAVA
Curator是Netflix开源的一套ZooKeeper客户端框架，旨在解决ZooKeeper客户端使用过程中的复杂性问题，如连接管理、重试机制及多种应用场景的封装。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

Curator是Netflix开源的一套ZooKeeper客户端框架. Netflix在使用ZooKeeper的过程中发现ZooKeeper自带的客户端太底层, 应用方在使用的时候需要自己处理很多事情, 于是在它的基础上包装了一下, 提供了一套更好用的客户端框架. Netflix在用ZooKeeper的过程中遇到的问题, 我们也遇到了, 所以开始研究一下, 首先从他在github上的源码, wiki文档以及Netflix的技术blog入手. 

看完官方的文档之后, 发现Curator主要解决了三类问题: 
  • 封装ZooKeeper client与ZooKeeper server之间的连接处理;
  • 提供了一套Fluent风格的操作API;
  • 提供ZooKeeper各种应用场景(recipe, 比如共享锁服务, 集群领导选举机制)的抽象封装.


Curator列举的ZooKeeper使用过程中的几个问题 
初始化连接的问题: 在client与server之间握手建立连接的过程中, 如果握手失败, 执行所有的同步方法(比如create, getData等)将抛出异常 
自动恢复(failover)的问题: 当client与一台server的连接丢失,并试图去连接另外一台server时, client将回到初始连接模式 
session过期的问题: 在极端情况下, 出现ZooKeeper session过期, 客户端需要自己去监听该状态并重新创建ZooKeeper实例 . 
对可恢复异常的处理:当在server端创建一个有序ZNode, 而在将节点名返回给客户端时崩溃, 此时client端抛出可恢复的异常, 用户需要自己捕获这些异常并进行重试 
使用场景的问题:Zookeeper提供了一些标准的使用场景支持, 但是ZooKeeper对这些功能的使用说明文档很少, 而且很容易用错. 在一些极端场景下如何处理, zk并没有给出详细的文档说明. 比如共享锁服务, 当服务器端创建临时顺序节点成功, 但是在客户端接收到节点名之前挂掉了, 如果不能很好的处理这种情况, 将导致死锁. 

Curator主要从以下几个方面降低了zk使用的复杂性: 
重试机制:提供可插拔的重试机制, 它将给捕获所有可恢复的异常配置一个重试策略, 并且内部也提供了几种标准的重试策略(比如指数补偿). 
连接状态监控: Curator初始化之后会一直的对zk连接进行监听, 一旦发现连接状态发生变化, 将作出相应的处理. 
zk客户端实例管理:Curator对zk客户端到server集群连接进行管理. 并在需要的情况, 重建zk实例, 保证与zk集群的可靠连接 
各种使用场景支持:Curator实现zk支持的大部分使用场景支持(甚至包括zk自身不支持的场景), 这些实现都遵循了zk的最佳实践, 并考虑了各种极端情况. 

Curator通过以上的处理, 让用户专注于自身的业务本身, 而无需花费更多的精力在zk本身. 

Curator声称的一些亮点: 

日志工具 
内部采用SLF4J 来输出日志 
采用驱动器(driver)机制, 允许扩展和定制日志和跟踪处理 
提供了一个TracerDriver接口, 通过实现addTrace()和addCount()接口来集成用户自己的跟踪框架 

和Curator相比, 另一个ZooKeeper客户端——zkClient( https://github.com/sgroschupf/zkclient )的不足之处: 
文档几乎没有 
异常处理弱爆了(简单的抛出RuntimeException) 
重试处理太难用了 
没有提供各种使用场景的实现 

对ZooKeeper自带客户端(ZooKeeper类)的"抱怨": 
只是一个底层实现 
要用需要自己写大量的代码 
很容易误用 
需要自己处理连接丢失, 重试等 

Curator几个组成部分 
  • Client: 是ZooKeeper客户端的一个替代品, 提供了一些底层处理和相关的工具方法.
  • Framework: 用来简化ZooKeeper高级功能的使用, 并增加了一些新的功能, 比如管理到ZooKeeper集群的连接, 重试处理
  • Recipes: 实现了通用ZooKeeper的recipe, 该组件建立在Framework的基础之上
  • Utilities:各种ZooKeeper的工具类
  • Errors: 异常处理, 连接, 恢复等.
  • Extensions: recipe扩展


Client 
这是一个底层的API, 应用方基本对这个可以无视, 最好直接从Curator Framework入手 
主要包括三部分: 
不间断连接管理 
连接重试处理 

Retry Loop(循环重试) 
一种典型的用法: 
Java代码   收藏代码
  1. RetryLoop retryLoop = client.newRetryLoop();  
  2. while ( retryLoop.shouldContinue() )  
  3. {  
  4.    try  
  5.    {  
  6.        // perform your work  
  7.        ...  
  8.        // it's important to re-get the ZK instance as there may have been an error and the instance was re-created  
  9.        ZooKeeper      zk = client.getZookeeper();  
  10.   
  11.        retryLoop.markComplete();  
  12.    }  
  13.    catch ( Exception e )  
  14.    {  
  15.        retryLoop.takeException(e);  
  16.    }  
  17. }  

如果在操作过程中失败, 且这种失败是可重试的, 而且在允许的次数内, Curator将保证操作的最终完成. 

另一种使用Callable接口的重试做法: 
Java代码   收藏代码
  1. RetryLoop.callWithRetry(client, new Callable()  
  2. {  
  3.       @Override  
  4.       public Void call() throws Exception  
  5.       {  
  6.           // do your work here - it will get retried if needed  
  7.           return null;  
  8.       }  
  9. });  


重试策略 
RetryPolicy接口只有一个方法(以前版本有两个方法): 
public boolean allowRetry(int retryCount, long elapsedTimeMs); 
在开始重试之前, allowRetry方法被调用, 其参数将指定当前重试次数, 和操作已消耗时间. 如果允许, 将继续重试, 否则抛出异常. 

Curator内部实现的几种重试策略: 
  • ExponentialBackoffRetry:重试指定的次数, 且每一次重试之间停顿的时间逐渐增加.
  • RetryNTimes:指定最大重试次数的重试策略
  • RetryOneTime:仅重试一次
  • RetryUntilElapsed:一直重试直到达到规定的时间


Framework 
是ZooKeeper Client更高的抽象API 
自动连接管理: 当ZooKeeper客户端内部出现异常, 将自动进行重连或重试, 该过程对外几乎完全透明 
更清晰的API: 简化了ZooKeeper原生的方法, 事件等, 提供流程的接口 

CuratorFrameworkFactory类提供了两个方法, 一个工厂方法newClient, 一个构建方法build. 使用工厂方法newClient可以创建一个默认的实例, 而build构建方法可以对实例进行定制. 当CuratorFramework实例构建完成, 紧接着调用start()方法, 在应用结束的时候, 需要调用close()方法.  CuratorFramework是线程安全的. 在一个应用中可以共享同一个zk集群的CuratorFramework. 

CuratorFramework API采用了连贯风格的接口(Fluent Interface). 所有的操作一律返回构建器, 当所有元素加在一起之后, 整个方法看起来就像一个完整的句子. 比如下面的操作: 
Java代码   收藏代码
  1. client.create().forPath("/head", new byte[0]);  
  2. client.delete().inBackground().forPath("/head");  
  3. client.create().withMode(CreateMode.EPHEMERAL_SEQUENTIAL).forPath("/head/child", new byte[0]);  
  4. client.getData().watched().inBackground().forPath("/test");  


方法说明: 
  • create(): 发起一个create操作. 可以组合其他方法 (比如mode 或background) 最后以forPath()方法结尾
  • delete(): 发起一个删除操作. 可以组合其他方法(version 或background) 最后以forPath()方法结尾
  • checkExists(): 发起一个检查ZNode 是否存在的操作. 可以组合其他方法(watch 或background) 最后以forPath()方法结尾
  • getData(): 发起一个获取ZNode数据的操作. 可以组合其他方法(watch, background 或get stat) 最后以forPath()方法结尾
  • setData(): 发起一个设置ZNode数据的操作. 可以组合其他方法(version 或background) 最后以forPath()方法结尾
  • getChildren(): 发起一个获取ZNode子节点的操作. 可以组合其他方法(watch, background 或get stat) 最后以forPath()方法结尾
  • inTransaction(): 发起一个ZooKeeper事务. 可以组合create, setData, check, 和/或delete 为一个操作, 然后commit() 提交
. 

通知(Notification) 
Curator的相关代码已经更新了, 里面的接口已经由ClientListener改成CuratorListener了, 而且接口中去掉了clientCloseDueToError方法. 只有一个方法: 
eventReceived()            当一个后台操作完成或者指定的watch被触发时该方法被调用 

UnhandledErrorListener接口用来对异常进行处理. 

CuratorEvent(在以前版本为ClientEvent)是对各种操作触发相关事件对象(POJO)的一个完整封装, 而事件对象的内容跟事件类型相关, 下面是对应关系: 
CREATEgetResultCode() and getPath()
DELETEgetResultCode() and getPath()
EXISTSgetResultCode(), getPath() and getStat()
GET_DATAgetResultCode(), getPath(), getStat() and getData()
SET_DATAgetResultCode(), getPath() and getStat()
CHILDRENgetResultCode(), getPath(), getStat(), getChildren()
WATCHEDgetWatchedEvent()


名称空间(Namespace) 
因为一个zk集群会被多个应用共享, 为了避免各个应用的zk patch冲突, Curator Framework内部会给每一个Curator Framework实例分配一个namespace(可选). 这样你在create ZNode的时候都会自动加上这个namespace作为这个node path的root. 使用代码如下: 

Java代码   收藏代码
  1. CuratorFramework    client = CuratorFrameworkFactory.builder().namespace("MyApp") ... build();  
  2.  …  
  3. client.create().forPath("/test", data);  
  4. // node was actually written to: "/MyApp/test"  



Recipe