聊一聊zookeeper分布式框架和主要功能

目录

前言

基本概念

集群角色

数据节点

Session会话

Watcher监听器

客户端工具

---

前言

  zookeeper是一个高可用、高性能的开源的分布式框架,具有保证客户端顺序一致性，原子性，顺序访问等特点。通过zookeeper可以实现发布/订阅，leader选举，分布式锁，分布式协调。元数据管理等功能。

基本概念

zookeeper 在架构设计上包括：集群角色，数据节点，watcher监听器，ACL权限控制等（zookeeper官方网站也有介绍https://zookeeper.apache.org/doc/r3.5.8/zookeeperProgrammers.html）。

接下来我们分别讲一下几个比较重要的概念。

集群角色

zookeeper 将集群节点分为三种角色：

Leader角色：负责处理读写请求，同步数据Follower节点;

Follower角色：参与Leader选举，参与Leader写时的数据同步（过半节点写入),。负责处理读请求，而写请求需要转发给Leader节点去处理；

Observer角色：不参与Leader选举，不参与Leader写时的数据同步（过半节点写入），只提供读服务和同步leader节点数据。

zookeeper集群只有Leader节点才可以处理写请求，其他节点只能提供读服务，因此,zookeeper集群的写性能并不高，适合读多写少的场景。

 这里可思考一下，zookeeper集群是如何通过ZAB协议进行leader选举的。

数据节点

 1.zookeeper数据结构是树状结构，每一个数据就是一个节点；

 2.节点分为持久节点和临时节点，持久节点会永久保存，除非主动删除，临时节点只在session会话时间内有效，session会话结束了临时节点会被删掉。

 3.节点又分为顺序节点和正常节点，对于顺序节点每次创建zookeeper服务都会在这个节点后面加上一个严格递增的数字。

 4.只有leader节点才可以创建数据节点，如果客户端请求follower节点创建数据节点，follower节点必须将创建请求转发给leader节点。

  这里可以思考下，zookeeper集群是如何通过ZAB协议同部数据的。

Session会话

     客户端和zookeeper服务建立连接之后，zookeeper服务会为客户端创建一个session会话保存到内存，并为客户端分配一个sessionId，在sessionTimeout时间内这个会话都是有效的，客户端通过发送读写请求和心跳请求都会更新sessionTimeout的超时时间，如果客户端和zookeeper服务端超过sessionTimeout时间都没有进行网络通信，zookeeper服务端和客户端都会关闭当前连接，session会话就会失效。

    这里不知道大家有没有疑问，客户端和follower节点连接之后也会创建session会话，而临时节点也只能有leader节点才能创建，那如果客户端和follower节点连接断开之后关闭session，leader节点又如何感知而删除临时节点的呢？

Watcher监听器

客户端通过监听器，注册一些感兴趣的事件，当zookeeper服务端有事件变更，便会通知到客户端。这里需要重要的是，zookeeper触发watch事件之后，便会将当前Watcher删除，如果需要重复监听某一个事件，我们在得到通知之后，再次注册相同的Watcher监听器。

客户端工具

zookeeper 提供了原生的zookeeper客户端api，功能相对简单，没有提供失败重试机制，自动注册Watcher监听器机制，使用起来很不方便。我们生产常用curator 框架作为zookeeper的客户端工具，该工具提供leader选举，分布式锁，可重复注册监听器，缓存，计时器等功能，功能强大，大小公司皆宜，深受我这种比较懒的程序员喜爱。

（curator 官方地址介绍了如何使用这些功能：http://curator.apache.org/curator-recipes/index.html）