zookeeper的缺点和分布式锁问题

转载 http://www.chaozh.com/whats-bad-in-zookeeper-design/

转载 https://mp.weixin.qq.com/s?__biz=MzI4MTY5NTk4Ng==&mid=2247489041&idx=1&sn=b58745994c0c98662e2330c966b5036f&source=41#wechat_redirect

 

1. API事务能力不足，不支持客户端发起事务性的多步骤操作 

2. 服务器无仲裁能力，ZK服务器端不能做基本的判断逻辑，必须都在客户端进行

    提供的api偏底层，client端代码难度也比较高

 

3. 回调机制受限，Znode上面watch仅支持触发一次回调，不支持定时过期失效

    watch机制的回调，只会通知一次，不保证成功，无重试

4. 可扩展性不足，ZK集群不支持在线动态添加机器或替换机器

    因为只有一个Leader，水平扩展并不能明显提升性能，因为只有1个Leader, zk机器节点越多，反而会导致通信和同步时间更长，性能可能会变差，zk集群的实际qps tps能力 是 几万 这个级别

5. Zab协议，协议在选举和发送环节都有优化空间

    zab的设计就是对网络及其敏感，假如管理双机房（双机房间网络抖动是常态），会因为抖动导致单机房不可用（因为只有一个Leader），即便在一个机房内（机房内经常会做路由调整），抖动也会导致leader重新选举，实际leader选举通常几十秒到几分钟，这会严重放大本来只有秒级的网络抖动

 

zk实现分布式锁的问题

1. zk提交类似于一个2PC过程，设置锁的性能会低于redis

2. zk leader一旦挂掉，设置锁就不可用（相对而言redis多个master节点都可以写）

3. 状态处理不正确，容易出现多个客户端持有锁或者释放不掉