day49-hadoop-zookeeper
day49-hadoop-zookeeper
hadoop-zookeeper
zookeeper的配置参数的解读
通信心跳数,Zookeeper服务器与客户端心跳时间,单位毫秒
tickTime=2000
LF初始通信时限
initLimit=10
LF同步通信时限:leader发送一个请求到flower,leader并接受一个flower确认的尝试的次数
syncLimit=5
数据保存路径
dataDir=path
客户端端口号
clientPort=2181
Zookeeper的四字命令
需要在Zookeeper的配置文件中加入如下配置
41w.commands.whitelist=*
通过nc连接服务
yum install nc -y
nc hostname port
常用四字命令
| 命令 | 说明 |
|---|---|
| ruok | 测试服务是否处于正确状态,如果确实如此,那么服务返回imok,否则不做任何相应 |
| conf | 打印配置信息 |
| cons | 列出所有连接到这台服务器的客户端全部会话详细信息。包括 接受/发送的包数量,会话id,操作延迟,最后的操作执行等信息 |
| crst | 重置所有连接的连接和会话统计信息 |
| dump | 列出那些比较重要的会话和临时节点。这个命令只能在leader节点上有用 |
Zookeeper内部原理
节点类型
持久节点(Persisten):客户端和服务器断开连接后,创建的节点不删除
普通持久节点
带序号的普通持久节点
短暂节点(Ephemeral):客户端和服务器断开连接后,创建的节点自己删除
普通临时节点
带序号的临时普通节点
Stat结构体
znode的属性
cZxid = 0x0
ctime = Thu Jan 01 08:00:00 CST 1970
mZxid = 0x0
mtime = Thu Jan 01 08:00:00 CST 1970
pZxid = 0x0
cversion = -2
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 2
1. czxid 创建节点的事务zxid
每次修改Zookeeper状态都会收到一个zxid形式的时间戳,也就是ZooKeeper事务ID
事务ID是ZooKeeper中所有修改总的次序。每个修改都有唯一的zxid,如果zxid1小于zxid2,那么zxid1在zxid2之前发生。
2. ctime-znode被创建的毫秒数(从1970年开始)
3. mzxid-znode最后跟新的事务zxid
4. mtime-znode最后修改的毫秒数(从1970年开始)
5. pZxid-znode最后更新的字节点zxid
6. cversion-zonde子节点变化号,znode子节点修改次数
7. dataversion-zonde数据变化号
8. aclVersion-znode访问控制列表的变化好
9. ephemeralOwner -如果是临时节点,这个是znode拥有者的sessionid。如果不是临时节点则是0
10. dataLength-zonde的数据长度
监听器原理

Paxos算法
Paxos算法是一种基于消息传递并且具有高度容错特性的一致性算法。
分布式系统中的节点通信存在两种模型:共享内存(Shared memory)和消息传递(Messages passing)。基于消息传递通信模型的分布式系统,不可避免的会发生以下错误:不考虑可能出现消息篡改即拜占庭错误的情况。Paxos算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致,保证不论发生以上任何异常,都不会破坏决议的一致性。
选举机制
基于ZAB协议(paxos算法)
1. 半数机制:集群中半数以上机器存活,集群可用。所以Zookeeper适合安装奇数台服务器。
2. Zookeeper虽然在配置文件中并没有指定Master和Slave。但是,Zookeeper工作,是有一个节点为Leader,其他则为Follower,Leader是通过内部的选举机制临时产生的。
3. 以一个简单的例子来说明整个选举的过程
假设有5台服务器组成的Zookeeper集群,他们的id从1-5,同时他们都是最新启动的,也就是没有历史数据,在存放数量这一点上,都是一样的。假设这些服务器依次启动,看看会发生什么。
选举过程
1. 集群启动的选举过程(zxid一致)
① 假设集群有5台机器,每台机器有自己的唯一编号(myid),分别是1,2,3,4,5,且机器启动的顺序为1 2 3 4 5,且机器启动的顺序为1 2 3 4 5
② 先启动机器1(muid为1),为自己投票(zxid,myid),实际投的票为(0,1),因为机器没有达到半数以上,选举失败
③ 启动机器2(myid为2),为自己投票(zxid,myid),实际投的票为(0,2),机器1和机器2交换选票,此刻机器1得到的投票信息为(0,1)(0,2),机器1发现机器2的投票信息的myid比自己的大,机器1改变投票,改投(0,2),对于机器2,得到的投票信息为(0,1),(0,2),机器2发现自己的myid比机器1的大,维持当前自己的投票(0,2),最终机器2得到两票。但是因为没有达到半数以上,选举失败
④ 启动机器3(myid为3),机器1的投票(0,1),机器2的投票(0,2),机器3的投票(0.3),相互交换投票,此刻机器1和机器2发现机器3的myid最大,改投(0,3),机器3维持原有的投票,最终,机器3得到3票。因为已经满足半数以上,机器3当选为leader,机器1和机器2服从机器3的领导,作为follower。
⑤ 机器4和机器5启动,因为已经选举出leader,只能作为follower。
2. 集群工作情况下leader故障后的选举过程
每台机器都发出投票(zxid,mid),交换选票,会先比较zxid,如果自己投票中的zxid小于别人的投票的zxid。则改投zxid大的。最终zxid大的机器会当选leader。
如果每台机器的zxid都一致,就是myid大的会当选leader
写数据流程

Zookeeper实战
分布式安装部署
集群规划
在node1、node2和node3三个节点上部署Zookeeper
解压安装
配置服务器编号
1. 在/opt/modult/zookeeper/目录下创建zkData
2. 在zkData目录下创建一个myid的文件
3. 编辑myid,在文件中添加与server对应的编号:1
4. 拷贝配置好的zookeeper到其他机器上
5. 修改不同机器上的编号
配置zoo.cfg
1. 修改zoo.sample.cfg为zoo.cfg
2. 修改数据存储路径配置
dataDir=/opt/module/zookeeper-3.5.7/zkData
3. 添加如下配置
server.1=node1:2888:3888
server.2=node2:2888:3888
server.3=node3:2888:3888
4. 同步zoo.cfg配置文件
server.A=B:C:D
A是一个数字,表示这个是第几号服务器;
集群模式下配置一个文件myid,这个文件在dataDir目录下,这个文件里面有一个数据就是A的值,Zookeeper启动时读取此文件,拿到里面的数据与zoo.cfg里面的配置信息比较从而判断到底是哪个server
B 是这个服务器的地址
C 是这个服务器Follower与集群中的Leader服务器交换信息的端口
D 是万一集群中Leader服务器挂了,需要一个端口来重新进行选举,选出一个新的Leader,而这个端口就是用来执行选举时服务器相互通信的端口
集群操作
集群管理脚本
#!/bin/bash
if [ $# -lt 1 ]
then
echo "Input args Error....."
fi
for node in node1 node2 node3
do
case $1 in
start)
echo "$node $1"
ssh $node /opt/module/apache-zookeeper-3.5.7/bin/zkServer.sh start
;;
status)
echo "$node $1"
ssh $node /opt/module/apache-zookeeper-3.5.7/bin/zkServer.sh status
;;
stop)
echo "$node $1"
ssh $node /opt/module/apache-zookeeper-3.5.7/bin/zkServer.sh stop
;;
*)
echo "Input args Error....."
;;
esac
done
客户端命令行
| 命令 | 说明 |
|---|---|
| help | 显示所有操作命令 |
| ls path | 使用ls 命令查看当前znode的子节点(可监听) -w 监听子节点变化 -s 附加次级信息 |
| create | 普通创建 -s 含序列号 -e 临时 |
| get path | 获取节点的值(可监听) -w 监听节点内容变化 -s 附加次级信息 |
| set | 设置节点的具体值 |
| stat | 查看节点状态 |
| delete | 删除节点 |
| deleteall | 递归删除节点 |

浙公网安备 33010602011771号