ZooKeeper使用场景

ZooKeeper是一个高可用的分布式数据管理与系统协调框架。基于对Paxos算法的实现，使该框架保证了分布式环境中数据的强一致性，也正是基于这样的特性，使得ZooKeeper能够应用于很多场景。网上对ZooKeeper的使用场景也有不少介绍，本文将结合作者身边的项目例子，系统的对zk的使用场景进行归类介绍。值得注意的是，ZooKeeper并不是生来就为这些场景设计，都是后来众多开发者根据框架的特性，摸索出来的典型使用方法。因此，也非常欢迎你分享你在ZooKeeper使用上的奇技淫巧。

zookeeper实现了主动通知节点变化，原子创建节点，临时节点，按序创建节点等功能。通过以上功能的组合，
zookeeper能够在分布式系统中组合出很多上层功能。下面就看几个常用到的场景，及使用方式和注意事项。

名字服务(NameService)

顾名思义，就是给分布式系统中的资源，使用人易于理解的名字，能够找到需要的资源。例如：一个统一接口系统，接收服务然后转给后端服务的具体server。当新增接口时，请求方只要传递新接口的名字，系统就能够根据名字找到对应的server，发现服务并转发请求。

在zookeeper中，按照命名的规则，建立对应的目录层级，例如 /company/team/service 就能找到一个公司，一个team下的提供的某个服务的路径。当上线新业务时，服务在zk中找到自己名字的节点，建立一个临时节点，写入配置信息。当调用方使用时，统一接口查询对应目录下的节点，选择合适的读取配置。当业务下掉时，直接删除服务，临时节点自动删除，服务自动下线掉。

配置管理(Configuration Management)

分布式系统位于不同主机的服务，有时要使用统一的配置。可以在zookeeper中的znode节点存储配置数据，每个客户端都监控（watch）znode的变化，当配置变更时，会通知推送，然后各个客户端再拉取新的配置。

注意：zk的watch是一次性的，客户端读取后要重新watch，并且检查是否是最新版本。

组员管理(Group Membership)

在Master、Slave模式下，Master要知道都有哪些Slave，进行同步等操作。也要及时知道哪些Slave死掉，然后去做相应处理。具体做法是Master先建立一个/Slave节点，每个Slave上线时都在/Slave建立一个临时节点，写入配置，server监控/Slave节点，对增加或消失的节点进行相应处理。

以上三种用法都属于配置类服务，按照一定的规则进行配置，需要读取配置的地方监控配置的变化。

简单互斥锁(Simple Lock)

每个进程都在/lock下创建锁znode，并watch /lock，只有一个创建成功，当成功的进程释放锁或者停止超时会通知其他进程，重新进入竞争锁的机制。

互斥锁(Simple Lock without Herd Effect)

为了不引发惊群效应，只要能给竞争进程排序就可以了，每个进程都在/lock的节点下创建带序号的znode，并且每个znode只监听比他次小的节点，当次小的节点释放锁后，比他次大的节点会收到通知，拿到锁权限。

注意：防止还没有执行到的进程死掉，要更新监听顺序。例如：2监听1，3监听2，如果2进程提前死掉，3要监控到这种状态，判断是否是2关闭，还是2释放锁，如果不是正常关闭，要去监听1更新监听。

读写锁(Read/Write Lock)

读写锁：多个读可以并发执行，但是写和读，写和写不能同时执行。
改动互斥锁方案，如果是写锁，监听他次小的节点，次小节点释放锁后，写锁检测是否还有更小的节点，如果有继续监听，如果没有获得写锁执行；如果是读锁，监听左侧最大的写锁，当写锁释放后就获得读锁。
也要注意中间节点死掉提前释放的问题，要重新监听节点。

屏障(Barrier)

在分布式系统中，屏障是这样一种语义: 客户端需要等待多个进程完成各自的任务，然后才能继续往前进行下一步。
例如凌晨备份，等待每个进程把数据都dump结束后，再打包压缩传走。

client先设置/mybarrier的znode，然后启动每个进程，每个进程执行结束成功后，在/mybarrier下创建结束的znode节点，client发现/mybarrier下的node数都达到了，再继续下面的任务。

双屏障(Double Barrier)

双屏障是这样一种语义: 它可以用来同步一个任务的开始和结束，当有足够多的进程进入屏障后，才开始执行任务；当所有的进程都执行完各自的任务后，屏障才撤销。

进入屏障：创建/ready和/process节点，每个进程都先到ready中注册，注册数量达到要求时，通知所有进程启动开始执行。
离开屏障：在/process下把注册ready的进程都建立节点，每个进程执行结束后删掉/process下的对应节点。当/process下为空时，任务全结束。

锁、屏障，本质都是排序，给要使用的节点排序，根据顺序来执行策略，保证执行不冲突。

总结

以上的应用场景，并不是只有zk能实现的，而且实现的方式也是通用的，换做其他组件，只要满足了通知和原子创建、自增id，都可以实现这些场景的使用。而且实现的方法也是通用的，不仅在zk中才这样用。
本质上就是统一配置通知机制，和原子简历自增id节点排序机制，实现了配置类和锁类协调的功能。