前面一篇文章讲了很多理论的东西，今天搞一下zk的集群搭建，条件有限我是在本地使用虚拟机搭建的环境，4个节点，其中1个leader,2个Follower，1个Observer。
一、集群搭建
各主机下修改主机名和网络配置
修改主机名：/etc/hostname
修改网络配置：/etc/sysconfig/network-scripts/ifcfg-ens33
如图
安装过程：
1、下载压缩文件
2、解压文件(去除版本信息我重命名了解压后文件夹名称为zk,tar、mv命令都懂的)
3、安装目录conf文件夹下复制配置文件
4、修改配置文件
observer的配置略有不同
5、创建数据存储目录
6、数据存储目录下分别创建主机编号，分别为1、2、3、4如下
7、配置环境变量(etc/profile)并从新加载
8、逐个启动，启动超过半数时会选出leader并对外提供服务
操作命令：
zkServer.sh start
zkServer.sh restart
zkServer.sh status
zkServer.sh stop
启动后查看各节点状态如下：
启动后zkos1为leader
数据存储目录如下：
其中acceptedEpoch为接收的最新年号，currentEpoch为当前系节点年号
数据如下：
表示当前为第6任leader
重启zkos1模拟leader宕机，后重选leader并查看状态
此时zkos3当选为新leader,再查看年号此时已在原来的基础上加1
二、相关概念
1、数据存储结构
zk数据存储结构是在根节点下挂很多子节点，使用了称为znode的数据节点概念。znode是zk中数据的最小单元，每个znode上都可以保存数据，同时还可以挂载子节点，形成一个树形化命名空间。
1)、四种节点类型
a、持久节点
b、持久顺序节点
c、临时节点：其生命周期与客户端会话的相同。只能做叶子节点。
d、临时顺序节点
2)、节点状态(记不住也不用记，用到的时候再查一下)
a、cZxid：Created Zxid，表示当前znode被创建时的事务ID
b、ctime：Created Time，表示当前znode被创建的时间
c、mZxid：Modified Zxid，表示当前znode最后一次被修改时的事务ID
d、mtime：Modified Time，表示当前znode最后一次被修改时的时间
e、pZxid：表示当前znode的子节点列表最后一次被修改时的事务ID。注意，只能是其子节点列表变更了才会引起pZxid的变更，子节点内容的修改不会影响pZxid。
f、cversion：Children Version，表示子节点的版本号。该版本号用于充当乐观锁。
g、dataVersion：表示当前znode数据的版本号。该版本号用于充当乐观锁。
h、aclVersion：表示当前znode的权限ACL的版本号。该版本号用于充当乐观锁。
i、ephemeralOwner：若当前znode是持久节点，则其值为0；若为临时节点，则其值为创建该节点的会话的SessionID。当会话消失后，会根据SessionID来查找与该会话相关的临时节点进行删除。
j、dataLength：当前znode中存放的数据的长度。
k、numChildren：当前znode所包含的子节点的个数。
2、会话
客户端与服务端之间的任何交互操作都与会话相关。ZooKeeper客户端启动时，首先会与zk服务器建立一个TCP长连接。连接一旦建立，客户端会话的生命周期也就开始了。
1)、会话的三种状态
a、CONNECTING：连接中。Client要创建一个连接，其首先会在本地创建一个zk对象，用于表示其所连接上的Server。
b、CONNECTED：已连接。连接成功后，该连接的各种临时性数据会被初始化到zk对象中。
c、CLOSED：已关闭。连接关闭后，这个代表Server的zk对象会被删除。
2)、会话超时管理(客户端管理)
是从客户端当前会话第一次发起服务端连接的时间开始计时。
3)、三种会话连接事件
客户端与服务端的长连接失效后，客户端将进行重连，会产生3种会话事件。
a、CONNECTION_LOSS：连接丢失
b、SESSION_MOVED：会话转移
c、SESSION_EXPIRED：会话失效
4)、会话空闲超时(服务端维护)
一旦空闲时长超时，服务端就会将该会话的SessionId从服务端清除。客户端可定时发送心跳检测保持长连接。
3、ACL
ACL全称为Access Control List(访问控制列表)，是一种细粒度的权限管理策略，可以针对任意用户与组进行细粒度的权限控制。zk利用ACL控制znode节点的访问权限，如节点数据读写、节点创建、节点删除、读取子节点列表、设置节点权限等。
1)、zk的ACL
zk的ACL分为三个维度：授权策略scheme、授权对象id、用户权限permission，子znode不会继承父znode的权限。
a、授权策略scheme
IP：根据IP地址进行权限验证。
digest：根据用户名与密码进行验证。
world：对所有用户不做任何验证。
super：超级用户可以对任意节点进行任意操作。
b、授权对象id
ip：授权对象是IP地址。
digest：授权对象是“用户名 + 密码”。
world：其授权对象只有一个，即anyone。
Super：与digest相同，极权对象为“用户名 + 密码”。
c、权限permission
c：Create，允许授权对象在当前节点下创建子节点。
d：Delete，允许授权对象删除当前节点。
r：Read，允许授权对象读取当前节点的数据内容，及子节点列表。
w：Write，允许授权对象修改当前节点的数据内容，及子节点列表。
a：Acl，允许极权对象对当前节点进行ACL相关的设置。
4、Watcher机制
zk通过Watcher机制实现了发布/订阅模式。原理如下图
1)、watcher事件和状态
事件和状态构成了zookeeper客户端连接描述的两个维度
zookeeper客户端与zookeeper server连接的状态
zookeeper中的watch事件(维护的常量，当zookeeper客户端监听某个znode节点时)
2)、watcher特性
a、一次性：一旦一个watcher被触发，zk就会将其从客户端的WatcherManager中删除，服务端中也会删除该watcher。zk的watcher机制不适合监听变化非常频繁的场景。
b、串行性：对同一个节点的相同事件类型的watcher回调方法的执行是串行的。这为我们保证了顺序，开发时千万不要因为一个Watcher的处理逻辑影响了整个客户端的Watcher回调。
c、轻量级：真正传递给Server的是一个简易版的watcher。回调逻辑存放在客户端，没有在服务端。整个结构只包含三部分：通知状态、事件类型和节点路径。也就是说Watcher通知非常的简单，只会告诉客户端发生了事件，而不会告知其具体内容，需要客户端自己去进行获取，比如NodeDataChanged事件，Zookeeper只会通知客户端指定节点的数据发生了变更，而不会直接提供具体的数据内容。
三、客户端命令
客户端命令就用单节点操作，我电脑有点岁月了，集群有时候CPU100%的时候导致虚拟机死机。
客户端连接本机，也可通过-server ip:port 连接其他服务
查看子节点
创建持久节点
创建顺序持久节点
创建零时节点
创建顺序零时节点
退出重连，零时节点已被删除
删除节点，节点下有子节点则无法删除
查看权限及设置权限
上一篇虽没有万字，也有六七千字，超哥说太长了可以分几次，java客户端的内容和一些典型应用场景就放下次了。年底事多慢慢更新了分享吧。很多东西也不是很细，可以上网搜一搜，都有很多文章的。
