zk的某核心开发者曾说curator对于zk的影响,就如同guava对于java的作用一样.
curator在对zk原始的api进行了大量包装,提供了一套更易用的fluent的api框架.但是使用中也存在这一些坑。
1. 创建完pathChildrenCache,一定记得调用start方法!!!不然是不会生效的。
2. 创建PathChildrenCache如果比较多的话,一定要记得自定义其使用的线程池参数,不然每次new出来一个PathChildrenCache,就会自行创建一个单线程池,创建不了多少就会开始抛超最多线程的个数异常.
3. 失去zk连接后,如果重新创建了curatorFramework,同时也需要重新创建PathChildrenCache,之前创建的Listener是不会再有事件进来.
4. 如果子节点个数太多,或者data太多,记得设置jute.maxbuffe参数,我们的项目中,节点是没有data的,但是由于一些公共服务的其consumers节点下的url实在是太多了,最多的一个consumers超过了10000个节点,而每个url的长度超过了400多个字符,超过了zk设置的4mb的数据长度,接近8mb大小,导致异常抛出.
5. 如果每次去查询多个zk的结果，不一定要使用多线程，zk是支持异步调用的，使用curator时，调用inBackground时，传入BackgroundCallback就行。
