关于zookeeper的讨论

    zookeeper作为分布式集群广泛使用的应用程序协调服务集群。它的特点就不说了，很多人分析过。前段时间微博上说到zk有一些问题，其实只是某些场合下zk使用需要小心，这里列举一下：

1. zk不适合做大数据量的存储，简单来说就是不适合做公用存储。原因很简单，每个数据要同步到所有server才返回，既慢，而且消耗带宽，client还容易阻塞。所以这种应用对zk来说太“重”了。
2. watch机制是paxos所没有的，是zk为了应用而自己加上的。这个功能有许多陷阱，最根本的原因就是zk的watch事件是单向传递的，并不保证通知一定能到达客户端，因此网络不稳定或者client挂掉都会导致丢失watch事件。举个例子，hbase使用zk来获知rs是否挂掉。如果某台rs挂掉，master也跟着挂掉的话，是没有办法知道这个事件的。必须在代码层做处理。
3. 另一种陷阱是client对于watch是一次性接收的，所以一次watch通知后，下一次watch接收必须等到client发出下一次watch请求。所以在处理期间如果有新的watch事件发生，会丢失这些事件。
4. client提交请求时，有可能收到connection_loss的异常，很不幸收到这种异常的时候，client无从得知请求是否成功。因为这个异常的引起是因为连接断开，而连接是在提交请求时断开还是请求正在处理时断开，无从获知。所以应用层如果特别care一致性问题，就必须带上sessionId重连或者重试。

    以后想到再继续写吧，因为最近越来越多的项目开始依赖zookeeper了，所以逐渐开始研究zk。不过进度还是远远赶不上前辈，大家可以在http://rdc.taobao.com/team/jm/archives/category/rpc-soa 看到更有质量的文章。


已有 2 人发表留言，猛击->> 这里<<-参与讨论


ITeye推荐

• —软件人才免语言低担保 赴美带薪读研！—