支撑Zookeeper核心功能的数据结构与常用应用场景

主要结构

• 树：Zookeeper的数据结构是一颗目录树，类型与UNIX文件系统。
• 节点：树中每一个节点称为ZNode。每个节点通过其在目录树中的路径唯一确定。
  • 每个节点可以存储少量数据，默认最大1M。数据量比较大时，在多副本复制时，会使性能降低，另外带宽压力了比较大。
  • 每个节点有一个ACL访问控制列表，提供基本的安全保障。

ZNode的类型

持久节点（persistent）：节点创建后就一直存在，通过API的完成CURD。

• 使用场景1：配置中心。结合Watch特性可以实现配置信息的实时生效。
• 使用场景2：动态DNS与负载均衡。用zookeeper管理域名信息与ip+port（可以加权重等信息）的映射信息。域名也换成服务名（service name），通过服务名来进行调用。

临时节点（ephemeral）：这种节点的生命周期与客户端会话绑定，当客户端下线时，此节点自动删除。

• 使用场景1：可以实现"集群感知"，配合Watch机制可以实现服务发现和服务路由。比如客户端监听某个微服务目录，这个目录下有多个完成同一功能的服务节点，zookeeper可以实时感知到此目录中的节点变化，实时通知到客户端，客户端修改本地的服务列表，进行服务的路由和负载均衡。
• 使用场景2：排它锁。多个客户端都创建同一个节点（/exclusive_lock/lock），zookeeper会保证只有一个客户端创建成功。其他客户端可以监听/exclusive_lock/目录下子节点的变更情况，以便知晓何时可获取锁。使用完锁后，通过删除lock节点来释放锁，客户端宕机也会自动释放锁。（并不能完全保证没有重复）

时序节点（sequential）：这种节点多了一个在当前目录中自增的序号。这个序号是按照创建时间递增的。

• 使用场景：全局唯一ID。(最大值：?）性能不高。

临时性时序节点（ephemeral sequential）：同时具备临时节点和时序节点的特性。

• 使用场景1：简单的Leader选举。把所有服务都注册为某个目录下的临时时序节点，当前Leader宕机后，相应的节点会消失，这时选用序号最小的节点作为新的leader。
• 使用场景2：共享锁。
  • 获取锁：所有客户端如果想获取共享锁，就在同一个目录（/shared_lock/）下创建一个临时顺序节点，名字上区分客户端、请求类型（读还是写）和自带的序号（host-R-序号，192.168.0.1-R-0001)。
  • 判断读写顺序：所有客户端在创建了子节点后，获取所有的字节，并且监听目录中节点变化。确定自己节点在所有节点中的顺序。对于读请求，如果没有比自己小的子节点，或者比自己小的都是读请求，则表明自己成功获取到了共享读锁，开始执行读取操作。如果比自己的子节点中有写请求，则当前请求需要进入等待。对于写请求，只有自己不是最小的子节点，都将进入等待。收到Watch通知后，重新进行上面的判断。
  • 释放锁：客户端调用删除节点操作或客户端宕机。
  • 上面过程有个问题，很多客户端会收到很多无用的通知，这被称为“羊群效应”。解决思路是每个客户端只需要关注比自己小的节点变化即可，不需要关注所有子节点。每个客户端不再监听所有子节点的变化。对于读请求，只需要监听比自己序号小的最后一个写请求节点即可。对于写请求，只需要监听比自己小的最后一个节点即可。
• 使用场景3：任务热备份（原理与Leader选举一样）