Zookeeper基本知识介绍

1、什么是zookeeper
Zookeeper是一个分布式开源框架，提供了协调分布式应用的基本服务，它向外部应用暴露一组通用服务——分布式同步（Distributed Synchronization）、命名服务（Naming Service）、集群维护（Group Maintenance）等，简化分布式应用协调及其管理的难度，提供高性能的分布式服务。ZooKeeper本身可以以单机模式安装运行，不过它的长处在于通过分布式ZooKeeper集群（一个Leader，多个Follower），基于一定的策略来保证ZooKeeper集群的稳定性和可用性，从而实现分布式应用的可靠性。

• zookeeper是为别的分布式程序服务的
• Zookeeper本身就是一个分布式程序（只要有半数以上节点存活，zk就能正常服务）
• Zookeeper所提供的服务涵盖：主从协调、服务器节点动态上下线、统一配置管理、分布式共享锁、统一名称服务等
• 虽然说可以提供各种服务，但是zookeeper在底层其实只提供了两个功能： 管理(存储，读取)用户程序提交的数据（类似namenode中存放的metadata）； 并为用户程序提供数据节点监听服务；

1.1 Zookeeper特性

• Zookeeper：一个leader，多个follower组成的集群
• 全局数据一致：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的
• 分布式读写，更新请求转发，由leader实施
• 顺序一致性：从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到ZooKeeper中。
• 数据更新原子性：一次数据更新要么成功，要么失败
• 实时性，在一定时间范围内，client能读到最新数据

1.2 Zookeeper数据结构

• 层次化的目录结构，命名符合常规文件系统规范(类似文件系统）
• 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
• 节点Znode可以包含数据和子节点（但是EPHEMERAL类型的节点不能有子节点）

节点类型

• PERSISTENT-持久化目录节点
  客户端与zookeeper断开连接后，该节点依旧存在

• PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
  客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号

• EPHEMERAL-临时目录节点
  客户端与zookeeper断开连接后，该节点被删除

• EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
  客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

1.3 监听通知机制

• Watcher（事件监听器），是ZooKeeper中一个很重要的特性。ZooKeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去。该机制是ZooKeeper实现分布式协调服务的重要特性。

1.4 ACL
ZooKeeper采用ACL（Access Control Lists）策略来进行权限控制。ZooKeeper定义了如下5种权限。

• CREATE: 创建子节点的权限。
• READ: 获取节点数据和子节点列表的权限。
• WRITE：更新节点数据的权限。
• DELETE: 删除子节点的权限。
• ADMIN: 设置节点ACL的权限。

注意：CREATE 和 DELETE 都是针对子节点的权限控制。

1.5 分布式锁
分布式锁是控制分布式系统之间同步访问共享资源的一种方式。
分布式锁又分为排他锁和共享锁两种。

排他锁
排他锁（Exclusive Locks，简称X锁），又称为写锁或独占锁。

如果事务T1对数据对象O1加上了排他锁，那么在整个加锁期间，只允许事务T1对O1进行读取和更新操作，其他任何事务都不能在对这个数据对象进行任何类型的操作（不能再对该对象加锁），直到T1释放了排他锁。

共享锁

共享锁（Shared Locks，简称S锁），又称为读锁。如果事务T1对数据对象O1加上了共享锁，那么T1只能对O1进行读操作，其他事务也能同时对O1加共享锁（不能是排他锁），直到O1上的所有共享锁都释放后O1才能被加排他锁。

1.6 ZAB协议
ZooKeeper Atomic Broadcast（ZAB，ZooKeeper原子广播协议）作为其数据一致性的核心算法，是一种特别为ZooKeeper设计的崩溃可恢复的原子广播算法。基于ZAB协议，ZooKeeper实现了一种主备模式（Leader、Follower）的系统架构来保持集群中各副本之间数据的一致性。
事务请求的处理方式：

所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而剩下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal（提案）并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，Leader就会再次向所有的Follower服务器分发Commit消息，要求对刚才的Proposal进行提交。