Zookeeper

基本概念：

Zookeeper:它是一个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

本质上就是zookeeper=文件系统+监听通知机制。

集群角色

1、leader：负责进行投票的发起和决议，更新系统状态。

2、follower：用于接收客户端请求并向客户端返回结果以及在选举过程中参与投票

3、observer：也可以接收客户端连接，将写请求转发给leader节点，但是不参与投票过程，只同步leader的状态。通常对查询操作做负载

文件系统：

zk的数据模型是以znode的形式存储和组织。与标准文件系统类似，是一个树形结构，根节点是'/'。

图中每个节点都是一个znode，类似于文件系统中的一个文件，形成了一个树形结构，每个znode内部还可以存储不超过1M的数据。这些znode可以是持久的，还可以是短期的（ephemeral ）。
短期的（ephemeral ）znode当创建他的客户端session超时，会被zk主动删除。有点类似给文件加锁，进程异常退出后，锁立刻解除。

Session 指的是 ZooKeeper 服务器与客户端会话。在 ZooKeeper 中，一个客户端连接是指客户端和服务器之间的一个 TCP 长连接。客户端启动的时候，首先会与服务器建立一个 TCP 连接，从第一次连接建立开始，客户端会话的生命周期也开始了。通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的Watch事件通知。 Session的sessionTimeout值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。

在为客户端创建会话之前，服务端首先会为每个客户端都分配一个sessionID。由于 sessionID 是 Zookeeper 会话的一个重要标识，许多与会话相关的运行机制都是基于这个 sessionID 的，因此，无论是哪台服务器为客户端分配的 sessionID，都务必保证全局唯一。

zk的数据模型类似文件系统，这点也没什么特别的。本质还是kv形式，如果kv的value还要求是kv格式，那么就和zk的数据模型一样。表示成树形的格式，更容易表示层级关系。

0. zk内部的选主和写数据机制。有超过一半的zk集群节点选出来的主节点，成为集群的leader节点，负责主写和同步其他丛属follower节点。底层用的ZAB（ZooKeeper Atomic Broadcast）协议。

1. 短期的（ephemeral ）znode功能。方便实现锁类操作，在分布式中处理超时状态。
2. 客户端可以设置监控watch某个znode的功能，当znode发生变化（版本号变更）时，会主动通知watch的客户端有变化了。该功能让客户端不必轮询，能够有序地知道znode变更顺序。

权限控制：

ZooKeeper 采用 ACL（AccessControlLists）策略来进行权限控制，类似于  UNIX 文件系统的权限控制。

ACL使用：scheme:id:perm 来标识：
       权限模式（Scheme）：授权的策略，这个参数代表使用何种方式对节点进行授权，有权限全部放开或是只给创建者开权限等等
　　授权对象（ID）:授权的对象，这个是授权的对象，至于授权对象取什么取决于权限模式，有个取用户名密码、有的取决于客户端的ip地址即同一个ip即使不是同一个用户也赋予同一个权限
　　权限（Permission）:授予的权限，CREATE、READ、WRITE、DELETE、ADMIN 也就是 增、删、改、查、管理权限，

       CREATE   c 可以创建子节点
　　DELETE   d 可以删除子节点（仅下一级节点）
　　READ       r 可以读取节点数据及显示子节点列表
　　WRITE     w 可以设置节点数据
　　ADMIN     a 可以设置节点访问控制列表权限

delete是指对子节点的删除权限，其它4种权限指对自身节点的操作权限。

子节点不会继承父节点的权限，客户端无权访问某节点：

getAcl        getAcl <path>     读取ACL权限
setAcl        setAcl <path> <acl>     设置ACL权限
addauth      addauth <scheme> <auth>     添加认证用户

具体的权限文件操作及权限控制：https://www.cnblogs.com/qlqwjy/p/10517231.html

监听机制：

数据发布与订阅，即所谓的配置中心，顾名思义就是发布者将数据发布到 ZooKeeper 节点上, 供订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和动态更新。 对于：数据量通常比较小。数据内容在运行时动态变化。集群中各机器共享，配置一致。 这样的全局配置信息就可以发布到 ZooKeeper上，让客户端（集群的机器）去订阅该消息。 发布/订阅系统一般有两种设计模式，分别是推（Push）和拉（Pull）模式。 - 推模式 服务端主动将数据更新发送给所有订阅的客户端 - 拉模式 客户端主动发起请求来获取最新数据，通常客户端都采用定时轮询拉取的方式 ZooKeeper 采用的是推拉相结合的方式： 客户端想服务端注册自己需要关注的节点，一旦该节点的数据发生变更，那么服务端就会向相应 的客户端发送Watcher事件通知，客户端接收到这个消息通知后，需要主动到服务端获取最新的数据

Kafka向zookeeper订阅broker信息，即客户端会在zookeeper上注册相关的watcher。一旦zookeeper发生变化，客户端能及时感知并作出相应调整。

特点：

• 顺序一致性： 从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。
• 原子性： 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。
• 单一系统映像 ： 无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。
• 可靠性： 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。

顺序一致性其实是因为所有的写操作都是发送到leader节点进行操作的所有你会发现zookeeper的文件操作没有覆写竞争的问题

原子性是因为当客户端进行写操作时，所有的follower节点包括observer节点必须同步完成，否则回滚掉，而其中的稳定性是通过心跳保活机制来的，一般对zookeeper的写操作不是很频繁，但是要求必须所有节点同时生效

配置文件：

zookeeper的配置文件：

/home/zookeeper/bin/conf/zoo.cfg