zookeeper
单机部署
分布式应用程序协调服务
export ZK_HOME=/usr/local/src/zookeeper-3.4.10
export PATH=$ZK_HOME/bin:$PATH
[Unit]
Description=cosmo-bdp zookeeper
After=network.target
[Service]
Type=forking
Environment=JAVA_HOME=/usr/local/src/java ZOO_LOG_DIR=/opt/logs
ExecStart=/usr/local/src/zookeeper-3.4.10/bin/zkServer.sh start
ExecStop=/usr/local/src/zookeeper-3.4.10/bin/zkServer.sh stop
ExecReload=/usr/local/src/zookeeper-3.4.10/bin/zkServer.sh restart
[Install]
WantedBy=multi-user.target
systemctl daemon-reload
systemctl enable zookeeper
systemctl restart zookeeper
集群部署
leader:数据的写(主要) 数据的读
follower： 数据的读 参与leader的选举
observer: 数据的读 不参与leader的选举
tickTime=2000
dataDir=/var/run/zookeeper/data
dataLogDir=/var/run/zookeeper/log
clientPort=2181
initLimit=5
syncLimit=2
server.1=IP1:2888:3888
server.2=IP2:2888:3888
server.3=IP3:2888:3888
第一个端口为：leader与follower通信的端口、数据同步端口
第二个端口为：leader选举端口
命令行操作
创建持久节点
# create /test1 abc
创建临时节点
# create -e /test2
创建有序节点
# create -s /test3
创建容器节点
# create -c /test1/test4
查看节点
# get -s /test1 或 stat /test1
监听节点（只能监听一次）
# get -w /test1 监听节点
# ls -w /test1 监听子节点
# ls -w -R /test1 监听所有节点
删除节点
# delete /test1
# deleteall /test1/test4 递归删除
ZAB协议
zab协议：保证主从数据同步、故障恢复
leader选举机制：(选票格式:myid、zxid)
第一轮投票:生成一张自己的选票，将自己的票投出去，然后将zxid或myid更大的票投进箱子。
第二轮投票：将手上较大的选票投出去，然后将zxid或myid更大的票投进箱子
节点的状态：Looking状态、follower状态、leader状态、abserver状态
故障恢复：节点之间会有socket通信，当leader宕机后，follower节点将会变成Looking状态，然后重新选举leader.
数据主从:
客户端向主节点发送数据
NIO:通过多路复用保证多任务运行
BIO的使用:故障恢复阶段，从节点会与主节点保持socket通信，投票通信端口
CAP理论
只能同时满足两个
C：一致性
A：可用性
P：分区容错性
zookeeper虽然追求CP(强一致性),但是实际上还是顺序一致性(事务id的存在能保证一致性)
数据迁移与恢复
zookeeper的事务日志
事务日志指zookeeper系统在正常运行过程中，针对所有的更新操作，在返回客户端“更新成功”的响应前，zookeeper会保证已经将本次更新操作的事务日志已经写到磁盘上，只有这样，整个更新操作才会生效。
事务日志的可视化：
事务日志为二进制文件，vim工具不能查看，但是通过自带的jar包可以查看
安装目录下：zookeeper-3.4.10.jar lib库下：slf4j-api-1.6.1.jar
放在同一个目录下：
# java -classpath .:slf4j-api-1.6.1.jar:zookeeper-3.4.10.jar org.apache.zookeeper.server.LogFormatter /tmp/zookeeper/version-2/log.1
zookeeper的snapshot
zookeeper的数据在内存中是以树形结构进行存储的，而快照就是每隔一段时间就会把整个DataTree的数据序列化后存储在磁盘中，这就是zookeeper的快照文件。
迁移
zookeeper有时候需要进行数据迁移，下面就是数据迁移的步骤：
数据迁移关键的两个文件就是日志文件(增量文件)、数据文件(全量文件)
# cd /usr/local/src/zookeeper-3.4.10/
# vim conf/zoo.cfg
找到datadir、logdir安装目录
# cd version-2/
复制log.*、snapshot.*文件并同步到其它机器
1、复制log.*、snapshot.*
2、停止zookeeper服务，导入数据，重新开启即可。
处理
日志文件与快照文件的备份：
1、zookeeper配置自动清理
在版本3.4.0后自带了清理功能，在zoo.cfg中配置即可
autopurge.purgeInterval=48 保留48小时以内的日志
autopurge.snapRetainCount=60 保留60个快照文件
缺点：需要重启zookeeper服务才能生效
2、使用自定义清理脚本
dataDir=/tmp/zookeeper/version-2
dataLogDir=/tmp/zookeeper/version-2
logDir=/usr/local/zookeeper/logs
count=60
count=$[$count+1]
ls -t $dataLogDir/log.* | tail -n +$count | xargs rm -f
ls -t $dataDir/snapshot.* | tail -n +$count | xargs rm -f
ls -t $logDir/zookeeper.log.* | tail -n +$count | xargs rm -f
crontab -e 0 2 * * * /bin/bash /usr/local/zookeeper/bin/clean_zook_log.sh > /dev/null 2>&1
每天凌晨两点执行并保存60份
3、使用zkCleanup.sh清理
sh /usr/local/zookeeper/bin/zkCleanup.sh 数据目录 -n 20 保留20份数据即可
由于在版本3.4.0后添加了自动清理日志和快照的功能，因此一般选择脚本的方式执行
恢复
当zookeeper崩溃时，我们如何能最大限度地恢复数据
log和snapshot的后缀名就是事务id，zookeeper的snapshot是全量数据的snapshot，后缀名表示最后一个写进snapshot的事务id，log的后缀名表示第一个写进事务log的事务id，所以理论上只要拿到最大的事务id的snapshot和log，就可以最大程度的恢复集群的数据。
由于集群的性质，最大事务id的snapshot和log很可能不在同一个节点，所以要查看集群的所有机器，备份之前先关掉集群，然后备份这两个文件。
1、停止集群，找到事务id最大的log和snapshot
2、删除集群的事务日志和快照文件
3、copy 事务id最大的log和snapshot 到一台机器上，启动该机器
4、启动其它机器
用户名密码
进入zookeeper
查看权限
'world,'anyone
: cdrwa
添加账号密码
给根目录添加权限
cZxid = 0x0
ctime = Thu Jan 01 08:00:00 CST 1970
mZxid = 0x0
mtime = Thu Jan 01 08:00:00 CST 1970
pZxid = 0x1000000e2
cversion = 13
dataVersion = 0
aclVersion = 1
ephemeralOwner = 0x0
dataLength = 0
numChildren = 11
'digest,'admin:mvt3POQWAl605wI1GLKcLZaSLOk=
: cdrwa
取消认证
ip白名单添加
