ZooKeeper的常用使用场景

ZK的常用使用场景

一、注册中心

实现方式

• 基于临时节点
• 基于监视通知机制
  注意：ZK集群可能会挂掉，所以为了防止zk挂掉后我们还能正常的进行服务的调用，需要在本地做一次缓存，只有当产生变化时这份缓存才会失效
  经典场景：dubbo中使用ZK做注册中心，并且引入了服务目录的概念，服务目录就是本地的一个缓存，但是当服务提供者列表发生变化时会更新这个缓存列表并且重新进行服务的导入

作为注册中心的缺点分析

• 数据一致性的需求：zk是一个cp的系统，但是注册中心更应该考虑a，当发生分区等问题时，只保证最终一致性即可，最终的结果只是有几台机器负载不均；
• 可用性：如上边叙述，当zk发生问题时，会影响服务的正常调用，但是实践中注册中心不能因为自己的原因影响服务的正常调用是注册中心设计的指导原则
• 服务规模：zk的写是不可扩展的，当我们的集群节点越来越多，并且频繁上下线的时候，会对写节点带来压力
• 持久化需求：注册中心需要关心之前的数据吗？答案是否定的，注册中心只需要关注当前的数据就行，所以不需要持久化本地和开启备份
• 健康检查：zk的健康检查只是简单的心跳，不能检查服务的实际状态
• 复杂性：zk运维成本高，需要专业的人员进行维护
  参考：阿里巴巴为什么不用ZK作为注册中心

二、分布式锁

zk作为分布式锁有两种实现方式 都是基于临时节点+通知机制

1.所有的节点都监听一个临时节点

这样带来的坏处是，会发生羊群效应，如果说在这个临时节点等待的节点超过1000个watch，那么当临时节点移除式就要发送1000个通知，这样会对zk的正常读写带来性能的影响。

2.改进后的分布式锁 引入临时顺序节点

在创建临时节点时，创建有顺序的临时节点，后一个节点总是监听他的前一个节点，这样当就是一个临时节点上只有一个监视点可以避免羊群效应，但是也会造成按创建顺序进行锁的获取，类似于公平锁；

图例

三、master选举

基于临时节点+同一个目录下节点名称不能相同
谁能创建节点成功谁是master，其他会话监听临时检点状态，当master下线后重新进行选举

四、id生成或命名服务

基于顺序节点
一个目录下的顺序节点是递增的