关于zookeeper的议论
关于zookeeper的讨论
zookeeper作为分布式集群广泛使用的应用程序协调服务集群。它的特点就不说了，很多人分析过。前段时间微博上说到zk有一些问题，其实只是某些场合下zk使用需要小心，这里列举一下：
以后想到再继续写吧，因为最近越来越多的项目开始依赖zookeeper了，所以逐渐开始研究zk。不过进度还是远远赶不上前辈，大家可以在http://rdc.taobao.com/team/jm/archives/category/rpc-soa 看到更有质量的文章。
是的。数据和log都在里面。所以要用zk自带的工具定期删。也可以参见我之前的blog
zookeeper作为分布式集群广泛使用的应用程序协调服务集群。它的特点就不说了，很多人分析过。前段时间微博上说到zk有一些问题，其实只是某些场合下zk使用需要小心，这里列举一下：
- zk不适合做大数据量的存储，简单来说就是不适合做公用存储。原因很简单，每个数据要同步到所有server才返回，既慢，而且消耗带宽，client还容易阻塞。所以这种应用对zk来说太“重”了。
- watch机制是paxos所没有的，是zk为了应用而自己加上的。这个功能有许多陷阱，最根本的原因就是zk的watch事件是单向传递的，并不保证通知一定能到达客户端，因此网络不稳定或者client挂掉都会导致丢失watch事件。举个例子，hbase使用zk来获知rs是否挂掉。如果某台rs挂掉，master也跟着挂掉的话，是没有办法知道这个事件的。必须在代码层做处理。
- 另一种陷阱是client对于watch是一次性接收的，所以一次watch通知后，下一次watch接收必须等到client发出下一次watch请求。所以在处理期间如果有新的watch事件发生，会丢失这些事件。
- client提交请求时，有可能收到connection_loss的异常，很不幸收到这种异常的时候，client无从得知请求是否成功。因为这个异常的引起是因为连接断开，而连接是在提交请求时断开还是请求正在处理时断开，无从获知。所以应用层如果特别care一致性问题，就必须带上sessionId重连或者重试。
以后想到再继续写吧，因为最近越来越多的项目开始依赖zookeeper了，所以逐渐开始研究zk。不过进度还是远远赶不上前辈，大家可以在http://rdc.taobao.com/team/jm/archives/category/rpc-soa 看到更有质量的文章。
1 楼
x-rip
2011-12-19
我们搭了一个zookeeper集群，运行3天后，存放dataLogDir的目录将硬盘撑爆了，查看全是乱码，请教一下这个目录下存放的是什么？是不是应用的输出Log也会存放在这个里面？
2 楼
lc_koven
2011-12-19
x-rip 写道
我们搭了一个zookeeper集群，运行3天后，存放dataLogDir的目录将硬盘撑爆了，查看全是乱码，请教一下这个目录下存放的是什么？是不是应用的输出Log也会存放在这个里面？
是的。数据和log都在里面。所以要用zk自带的工具定期删。也可以参见我之前的blog
3 楼
alexanderdai
2012-04-03
嗯 zk watch不可靠，本身就不能强依赖zookeeper，hbase中的强依赖zk的用法是结构上的问题。必须具备定期向zk fetch最新新数据merge到hbase使用zk的 mem中才能保证数据与持久化的一致性。
例如一个很典型的用例场景就是hmaster分配region multi assgin多次都是因为这个引起的。理应当获取不到watch事件的时候达到标准去zk中主动fetch一下最新数据并与内存中cache的数据做比较然后当做本地event处理。
例如一个很典型的用例场景就是hmaster分配region multi assgin多次都是因为这个引起的。理应当获取不到watch事件的时候达到标准去zk中主动fetch一下最新数据并与内存中cache的数据做比较然后当做本地event处理。