zookeeper的原理和应用场景
本文先介绍zookeeper的znode、zookeeper的读写流程和zookeeper的节点类型，然后再根据zookeeper的节点类型和watch机制，图解zookeeper的典型应用场景。
zookeeper简介
zookeeper是分布式系统设计的基石，在分布式系统中扮演着“协调器”的作用(a distributed co-ordination service)。zookeeper中的数据是基于树形结构组织的。如下图所示，
zookeeper's Hierarchical Namespace
zookeeper中的每个节点称为一个znode，每个znode维持一个数据结构，其内容如下：
- Version number − 版本号，当和该znode节点关联的数据发生变化时，版本号会自增1。
- Action Control List (ACL) − 访问控制列表，znode的访问控制机制，它控制znode的所有读写操作。
- Timestamp − znode创建时的时间戳，精确到毫秒。
- Data length − znode节点存储数据的长度，最大1MB。
zookeeper的读写流程
当Client向zookeeper发出读请求时，无论是Leader还是Follower，都直接返回查询结果。
zookeeper读操作
zookeeper写入操作分为两种情况，① 写入请求直接发送到leader节点，② 写入请求发送到Follower节点，这两种情况有略微的区别。
写入请求直接发送到Leader节点时的操作步骤如下：
- ① Client向Leader发出写请求。
- ② Leader将数据写入到本节点，并将数据发送到所有的Follower节点；
- ③ 等待Follower节点返回；
- ④ 当Leader接收到一半以上节点(包含自己)返回写成功的信息之后，返回写入成功消息给client;
写入请求直接发送到leader节点
写入请求发送到Follower节点的操作步骤如下：
- ① Client向Follower发出写请求。
- ② Follower节点将请求转发给Leader；
- ③ Leader将数据写入到本节点，并将数据发送到所有的Follower节点；
- ④ 等待Follower节点返回；
- ⑤ 当Leader接收到一半以上节点(包含自己)返回写成功的信息之后，返回写入成功消息给原来的Follower；
- ⑥ 原来的Follower返回写入成功消息给Client；
写入请求发送到Follower节点
zookeeper的节点类型
学习zookeeper的节点类型、watch机制是理解zookeeper的应用场景的前提。znode有三种基本类型和两种组合类型：
- Persistence znode 持久znode，当创建之后会被持久化到存储中。若不特别指定，创建的znode默认为持久型。
- Ephemeral znode − 临时znode，由客户端在连接时创建，当客户端断开之后，该znode将会被自动删除。同时，临时znode不允许有子节点。
- Sequential znode − 序列znode，当节点被创建时，zookeeper会自动在节点后面添加数字后缀，如创建一个以/app/session的序列znode，创建完成之后的名称为/app/session0000000001。
- Persistence+Sequential znode，组合出的节点类型。
- Ephemeral+Sequential znode，组合出的节点类型。
zookeeper的watch机制
ZooKeeper 允许客户端向服务端注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。
ZooKeeper 的 Watcher 机制主要包括客户端线程、客户端 WatchManager 和 ZooKeeper 服务器三部分。在具体工作流程上，简单地讲，客户端在向 ZooKeeper 服务器注册 Watcher 的同时，会将 Watcher 对象存储在客户端的 WatchManager 中。当 ZooKeeper 服务器端触发 Watcher 事件后，会向客户端发送通知，客户端线程从 WatchManager 中取出对应的 Watcher 对象来执行回调逻辑。
zookeeper的应用场景
zookeeper实现配置中心
配置中心
应用程序启动时向zookeeper中和自己相关的znode上注册一个watcher，当被监控znode中数据的变化时，应用程序会接收到zookeeper通知消息，这样应用程序就可以根据获得的通知消息对应用程序的配置进行修改。
注意：应用程序注册的watcher每次只能触发一次，当获取完消息之后需要再注册一次watcher
服务注册中心
服务注册中心
操作流程：
- ① 服务提供者向Zookeeper注册服务；
- ② 服务消费者从zookeeper中查询服务和监听服务的变化；
- ③ 缓存服务信息到本地；
- ④ 调用远端的服务；
zookeeper集群系统管理
集群系统管理
客户端通过zookeeper向集群发送控制命令，集群中的Node上运行一个Agent或者应用程序中运行一个watch线程用于watch配置节点，当znode中的数据发生变化时，执行相依的动作。流程如下：
- ① client 写入命令到zookeeper中的某个znode；
- ② Node上的Agent或者应用程序中的watch线程获取到znode的变化，读取命令，并执行相应动作；
- ③ 各个Node将执行的结果写入到zookeeper；
- ④ 客户端的watch线程watch到有结果写入到znode，从znode中读取数据，并显示。
zookeeper实现分布式锁
zookeeper分布式锁
分布式锁实现步骤如下：
- 当需要获取锁时，客户端先连接到zookeeper，创建一个ephemeral+sequence类型的znode，创建的znode名称形如：lock_0000000001,lock_0000000002,lock_0000000003等。
- 然后，客户端获取/app/lock下的znode列表，判断自己创建的znode是否序列最小，若是，则获的锁；若不是，在距离自己最近的前一个znode上设置一个watch，当获取到znode变更通知后，重复此步骤直至获得锁；
- 执行业务代码；
- 完成业务流程后，删除对应的znode释放锁。
zookeeper集群选主
使用zookeeper的ephemeral+sequence类型的znode可以实现集群的选主功能。假设集群中有三个节点，大致的选主过程如下：
- 各个Node启动之后，以“/app/leader_election/guid_”为路径在zookeeper中创建ephemeral+sequence类型的znode，创建完成之后路径“/app/leader_election/”下将有guid_0000000001，guid_0000000002，guid_0000000003三个节点。
- 每个Follower节点各自watch一个距离自己最近且比自己sequence小的znode；
- 各个Node之间将选择序列最小的节点作为主节点，此时创建guid_0000000001序列的节点将被选举为leader，其他Node变为Follower，如下图所示。
zookeeper选主
当Leader宕机时，guid_0000000001将被删除，Follower（Node2）watch到leader已被移除，且没有比自己序列更小的Node了，于是将自己选为leader，其他Follower节点寻找Sequence最小的节点作为自己的主节点，选主完成后，如下图所示。
zookeeper选主
当Node1恢复之后，会创建一个名称为guid_0000000004的znode，并watch邻近的znode，即guid_0000000003，如下图所示：
zookeeper选主
个人理解：对应简单的系统，使用zookeeper来实现分布式系统的选主还是比较便捷的，但是对于复杂一些的系统，或者实时性要求较高的分布式系统，一般会选择基于Paxos或者Raft协议来实现选主功能。zookeeper本身也就是Paxos的一个实现。
