zookeeper
zookeeper
为分布式系统提供服务
分布式系统：是一个硬件或软件组件分布在网络中的不同计算机上，彼此之间通过消息传递进行通信和协作的系统
特征：分布性，对等性，并发性，缺乏全局时钟，故障必然会发生
典型的问题: 通信异常，网络分区，三态(成功，失败，超时),节点故障
CAP
P: 分区容错性
CP： 一致性，容错性
AP：可用性，容错性
数据要一致才有效，所以即使是可用性（AP），最终数据还要转换为一致
BASE：
BA：基本可用
S： 软状态（不同的节点，在同一时间，特定窗口下获取的数据可以不一致）
E：最终一致性
软状态，是数据节点的中间状态，但最终要保持一致性
最终一致性：因果一致性，会话一致性，单调读一致性，单调写一致性，读已之所写一致性
保证分布式系统的一致性多种协议
2PC：2 Phase-commit 两段式提交
3PC: 3 Phase-commit 三段式提交
paxos:
Google Ghubby,分布式锁服务， GFS/Big Table 都用到了chubby
分布式协作：元数据存储，master选举
分布式系统进程，要相互通信进行协调，因此每个服务要向服务注册一个会话，分布式系统通过寻找会话，来确定每一台服务是否可用，为确保注册服务器挂机，注册服务器应是高可用（分布式）
zookeeper是一个开源的分布式协调服务，它是chubby的开源实现，换句话讲zk是一个典型的分布式数据一致性解决方案。分布式应用程序可以基于它实现数据的发布/订阅，负载均衡，名称服务，分布式协调/通知，集群管理，master选举，分布式锁，和分布式队列
基本概念
集群角度: leader,Follower,observer(观察员）
Follower和Observer 都是读节点，都可以参与选举过程，但不同的是observer不能够被选举
Leader: 选举产生，读/写
Follower: 参与选举，可以被选举，读服务
Observer: 参与选举，不可被选举，提供读服务
会话： zk中，客户端和服务端，建立的TCP的长连接，直到客户端不在参与分布式系统或宕机时，才会关闭连接
数据节点（zNode）：即zk数据模型中的数据单元，zk的数据都存储在内存中，数据模型为树状结构（zNode Tree），每个zNode都会保存自己的数据于内存中
持久节点： 仅显示删除才消失
临时节点： 会话终止即自动消失
版本（version）：zk会为每个zNode维护一个称之为stat的数据结构，记录了当前zNode的三个版本
Vesrion：当前版本
cversion： 当前zNode，的子节点版本
aversion： 当前zNode的ACL的版本
ACL： zk使用ACL机制进行权限控制，CREATE,READ,WRITE,DELETE,ADMIN
ACL的权限发生改变，其版本也会发生变化
事件监听器（watcher）：zk上，由用户指定的触发机制，在某些事件产生时，zk能够通知客户端
zookeeper:使用ZAB协议（zookeeper Atomic Broadcast），zk原子广播协议（崩溃保护机制，用于leader崩溃，用来选举新的leader，确保数据的完整性和一致性）这里的选举，指zk自己的选举
ZAB协议的三种状态：
- Looking 找组织的过程，选举的过程
- Following，Follower节点所处的状态
- Leading，leader节点所处的状态
每个节点都在这三种状态之间进行转换，选举出leader后，ZAB协议进入原子广播阶段，leader与自己同步的每个Follower节点，创建一个同步序列（Follower节点可能与leader节点的数据不一致），leader节点要与Follower节点进行心跳检测机制（心跳检测，Follower会常常想leader请求，更新自己的数据版本或时间戳），如果Follower一个超出时间内，没有更新自己的状态，Leader就会判定Follower失去联系
四个阶段
- 选举 election
- 发现 discovery
- 同步 sync
- 广播 Broadcast
选举：指在Looking阶段，选举出leader
zookeeper的安
部署方式
单机模式、伪分布式、分布式
https://zookeeper.apache.org/
安装
安装jdk
yum -y install java-1.8.0-openjdk
下载zookeeper
tar -xvf zookeeper-3.4.14.tar.gz -C /opt
ln -s /opt/zookeeper-3.4.14/ /opt/zookeeper
cd /opt/zookeeper/conf/
cp zoo_sample.cfg zoo.cfg
grep -v "^#" zoo.cfg
tickTime=2000 向zk发送心跳的时长，单位是毫秒
initLimit=10 初始化同步阶段，需要多少个心跳时长
syncLimit=5 发送请求，需要多少个tick周期
dataDir=/data/zookeeper 数据目录
clientPort=2181 客户端端口
maxClinetCnxns=60 客户端的最大并发连接数
server.1=10.0.0.11:2888:3888
server.2=10.0.0.12:2888:3888
server.3=10.0.0.15:2888:3888
scp -r /opt/zookeeper-3.4.14 root@10.0.0.12:/opt
scp -r /opt/zookeeper-3.4.14 root@10.0.0.15:/opt
---------------------------------------------------------------------------------------------------
server.id=IP:PORT:PORT
ID:是各主机的数字标识，一般从1开始
IP：为各主机的IP
PORT：做集群节点通信使用，一般为2888:3888，只要服务器没有占用其端口即可
mkdir -p /data/zookeeper
10.0.0.11
echo 1 > /data/zookeeper/myid
10.0.0.12
echo 2 > /data/zookeeper/myid
10.0.0.15
echo 3 > /data/zookeeper/myid
/opt/zookeeper-3.4.14/bin/zkServer.sh start 启动
/opt/zookeeper-3.4.14/bin/zkClinet.sh 进入zookeeper内部
[zk: localhost:2181(CONNECTED) 0] ? 获取帮助
[zk: localhost:2181(CONNECTED) 1] create -e /test "test" 创建临时节点
[zk: localhost:2181(CONNECTED) 3] create /test1 "test1" 创建永久节点
[zk: localhost:2181(CONNECTED) 2] get /test 获取节点信息test
[zk: localhost:2181(CONNECTED) 4] stat /test1
cZxid = 0x100000003 //c（create），z(zookeeper),xid(事务)标识该节点是由哪个事务产生的
ctime = Tue Jun 16 15:41:02 CST 2020 // create time
mZxid = 0x100000003 // 更新该节点的事务ID
mtime = Tue Jun 16 15:41:02 CST 2020 //更新时间
pZxid = 0x100000003 // 该节点的子节点的事务列表
cversion = 0 //子节点的版本号
dataVersion = 0 //数据版本号
aclVersion = 0 //ACL的版本号
ephemeralOwner = 0x0 //创建该临时节点的分发ID，如果不是临时节点则为0
dataLength = 5 //数据长度
numChildren = 0 //子节点的个数
默认在zookeeper中使用了乐观锁机制，相对应悲观锁的机制，各事务之间一定会出现干扰，但事务之间的隔离要宽松些，乐观锁，表示各事务并发不会相互干扰，因此事务之间不会出现锁机制，悲观锁表示每一次事务开始之前，都会请求锁。mysql悲观锁。因此zookeeper，在每个事务修改数据之前，都要监控其他事务是否正在修改此数据，如果存在更新，则当前事务进行回滚
分布式客户端
watcher(监听器）：client端特别关注的数据在zk上，会给该数据注册一个监听器，当zk上的数据发生改变时，会通知client 进行修改，监听器是一次 性的，如果已经使用过了，就必须重新注册一个监听器
监控zk的四字命令
telnet IP 2181
ruok
stat
srvr
conf
cons
wchs
envi
zkCli.sh 接口命令
create
ls
ls2
stat
delete
rmr
get
set
zoo.cfg 配置参数
#基本的配置参数
clientport=2181
dataDir=/data/zookeeper
dataLogDir=... 事务日志文件路径，使用AOF机制
tickTime= 向zk发送的心跳时长
#存储配置
preAllocSize：为事务日志预先分配的磁盘空间量 默认为65535kb
snapCount: 每多少次事务后执行一次快照操作，每事务平均大小100字节
事务日志空间/事务大小 = 事务次数的快照
autopurge.snapRetainCount:快照清零之后，保留快照的个数
autopurge.purgeInterval：purge操作的时间间隔，0表示不启动
fsync.warningthresholdms:zk进行事务日志，fsync操作时消耗的时长报警阈值
fsync操作时间长的原因: 1从内存写入磁盘的数据过多 2 磁盘的IO压力过大
wegint.X=N:判定quorum时投票的权重，默认为1
#网络配置
maxClientCnxns: 即每个IP的最大连接数
ClientPortAddress: zk监听的IP地址
minSessionTimeout:会话最短的超时时间
maxSessionTimeout:最大会话的超时时长
#集群配置
initLimit: Follower进入leader并完成数据同步的时长
syncLimit:心跳检测的最大延迟
leaderServes:默认zk的leader接收读写请求，额外还要负责协调各Fllower发来的事务，因此为使得leader集中处理zk集群内部的信息，建议不让leader直接提供服务，而是把所有写请求直接发给Follower，统一向leader请求
cnxTimeout：leader选举期间，各服务器之间创建TCP连接的超时时间
ellectionAlg：选举算法，目前仅支持FastleaderElection算法一种
sever.id=[hostname]:port:port[:observer]
observer是配置成观察员的
第一个port：Follower与leader进行通信和数据同步时所用的端口
第二个port：是leader选举时用的端口
运行为集群模式时：在数据目录下创建 echo ID > myid，已标识各个主机分别是谁
zookeeper典型的应用场景
分布式数据发布订阅，负载均衡，当客户端访问服务时，不会直接访问服务，而是访问zookeeper，由zookeeper进行调度命名服务，分布式协调通知，集群管理，master选举（比如hbase分布式之间，要通过zookeeper进行选举，kafka选举）
