zookeeper典型使用场景

分布式锁

1、非公平锁
分布式锁的加锁原理：每个要执行任务的客户端创建指定路径的节点，若创建成功，代表获取到了锁，便可以执行业务逻辑，然后删除节点，释放锁，并向其他监听此节点的客户端发送释放锁的通知，其他客户端再反复执行以上流程。
此过程很容易看出是非公平锁，所有客户端监听同一个路径，节点释放锁后需要通知所有的客户端，压力较大。

2、公平锁
针对以上问题，我们可以采用公平锁来进行优化。公平锁的大致思路是，再zk集群上首先创建一个目录用于存放这些锁。这里就用/lock作为路径。然后客户端请求时会在此目录下创建临时顺序节点，然后判断自己的编号是否是此目录下最小的，若是，代表获取到了锁，若不是，则监听编号紧邻自己的前一个节点。等待前一个节点释放锁的通知，重复以上步骤。

3、共享锁
以上两种锁都是典型的互斥锁，也就是将所有的请求串行化起来一个一个执行，这样以来整个并发度和性能会受到影响，假如是读请求，有必要挨个加锁吗？有没有解决办法呢？可以考虑使用共享锁。
以上为共享锁的大致原理。核心思想就是将读写请求打上一个前缀标记进行区分。read请求监听前面最近的write请求，write请求监听前面最近的任意一个请求。其他步骤和公平锁类似。

注册中心
,什么是注册中心，就是让众多的服务，都在Zookeeper中进行注册，注册就是把自己的一些服务信息，比如IP，端口都写到 Zookeeper节点上， 这样有需要的服务就可以直接从zookeeper上面去拿， 我们可以定义统一的名称，比如， User-Service, 那所有的用户服务在启动的时候，都在User-Service 这个节点下面创建一个子节点（临时节点），这个子节点保持唯一就好，代表了每个服务实例的唯一标识，有依赖用户服务 的比如Order-Service 就可以通过User-Service 这个父节点，就能获取所有的User-Service 子 节点，并且获取所有的子节点信息（IP，端口等信息），拿到子节点的数据后Order-Service可 以对其进行缓存，然后实现一个客户端的负载均衡，同时还可以对这个User-Service 目录进行 监听， 这样有新的节点加入，或者退出，Order-Service都能收到通知，这样Order-Service重 新获取所有子节点，且进行数据更新。这个用户服务的子节点的类型为临时节点。 第一节课有 讲过，Zookeeper中临时节点生命周期是和SESSION绑定的，如果SESSION超时了，对应的节 点会被删除，被删除时，Zookeeper 会通知对该节点父节点进行监听的客户端, 这样对应的客户 端又可以刷新本地缓存了。当有新服务加入时，同样也会通知对应的客户端，刷新本地缓存，要 达到这个目标需要客户端重复的注册对父节点的监听。这样就实现了服务的自动注册和自动退出。