zookeeper分布式协调
安装笔记
准备 node01~node04
1、所有虚拟机安装jdk,并设置javahome
3、下载zookeeper zookeeper.apache.org
3、tar xf zookeeper.*.tar.gz
4、mkdir /opt/mashibing
5、mv zookeeper /opt/mashibing
6、vi /etc/profile
export ZOOKEEPER_HOME=/mashibing/apache-zookeeper-3.7.0-bin
export PATH=$PATH:$ZOOKEEPER_HOME/bin
7、cd zookeeper/conf
8、cp zoo.sem*.cfg zoo.cfg
9、vi zoo.cfg
dataDir=配置持久化目录,尽量不要使用默认配置
//有几台写几台
server.1=node1:2888:3888
server.2=node2:2888:3888
server.3=node3:2888:3888
server.4=node4:2888:3888
node1去vim /etc/hosts 中设置映射关系,格式为198.168.134.25:node1
如果想设置那台机器角色为observer,只需在后面加上:observer即可
10、mkdir -p /var/mashibing/zk
11、echo 1> /var/mashibing/zk/myid
12、cd /opt && scp -r ./mashibing/ node02:`pwd`
13、node02~node04 创建myid,在dataDir的设置目录下创建
14、启动顺序 1,2,3,4
15、zkServer.sh start-foreground
集群模式
zookeeper表面上看上去是一种主从集群,主为leader,从为follower
增删改,只能发生在leader身上,查询可以发生在所有节点
zookeeper有两种运行状态
1、可以状态
2、不可用状态
3、不可用状态恢复到可用状态应该越快越好
分层命名
与节点的相似
节点和临时节点
类似于文件夹,但是与文件夹的不同,实际为节点的,节点既可以放下一个节点,又可以存放数据,只能存放少量数据,大概为1M
节点划分
持久节点
临时节点:create-e
client通过代码可以实现分布式锁,场景:一个线程拿到了临时节点,其他线程获取该线程的信息就可以,不需要想redis一样需要设置过期时间和通过第二个线程刷新过期时间
序列节点:create-s
如果锁依托与父节点,且具备-s,代表父节点下可以有多把锁,并且如果后面的锁根据前面的锁才能运行,可以是事务所或者队列锁
zookeeper理论上可以当数据库用,但是不要把zookeeper当数据库
特征/保障
顺序一致性:客户端的更新将按发送顺序应用,因为leader只有一个,会一次请求leader
原子性:更新要么成功或要么失败,没有部分结果
统一视图:无论服务器连接到那个服务器,客户端都将看到相同的服务视图
可靠性:一单应用了更新,它将从那时起持续到客户端覆盖更新
及时性:系统的客户视图保证在特定时间范围内是最新的
命令:
ls:查看所有节点
get children:检索所有子节点
create:创建节点,可以在节点后面跟上数据值
-e:创建一个临时节点,一个客户端创建的时候会创建一个sessionid,而这个临时节点归属于连接的session,且session是会消耗事务id的(因为其他zookeeper也需要看到session的临时节点,所以其他zookeeper在该zookeepersession创建的时候,消耗一个事务id来创建该session的id),当该session消失,那么这个临时节点就会过期
-s:创建一个序列节点,防止同时操作一个节点的值导致覆盖,会在后面添加序列值,该序列值为递增
get:获取节点中的值
set:设置节点中的值
czxid:0X200000002的表示顺序值,16进制,后面表示你是第几个leader
ctime:创建时间
mzxid:修改的id
mtime:修改时间
pzid:当前节点下创建最后那个节点的czxid
ptime:当前节点下创建的下个节点
exists:监测该节点是否变化,产生新的事务
quit:退出命令行模式
sync:等待数据传播
stat:查看当前目录状态
状态属性 | 说明 |
---|---|
cZxid | 数据节点创建时的事务ID |
ctime | 数据节点创建时的时间 |
mZxid | 数据节点最后一次更新时的事务ID |
mtime | 数据节点最后一次更新时的时间 |
pZxid | 数据节点的子节点列表最后一次被修改(是子节点列表变更,而不是子节点内容变更)时的事务ID |
cversion | 子节点的版本号 |
dataVersion | 数据节点的版本号 |
aclVersion | 数据节点的ACL版本号 |
ephemeralOwner | 如果节点是临时节点,则表示创建该节点的会话的SessionID;如果节点是持久节点,则该属性值为0 |
dataLength | 数据内容的长度 |
numChildren | 数据节点当前的子节点个数 |
zookeeper的原理
zk的数据状态不在内存,用磁盘来保存日志
扩展性
observer仅仅是为了放大查询能力设计的,并不参与选举
可靠性
可靠性可以快速恢复leader,当一个leader挂掉,并没有新的leader确定的时候,并不能对外提供服务,防止错误的数据提供给client,并且其中的底层中用到了paxos算法,和zab广播算法。
paxos算法
分布式必用到的算法。保证的是在分布式情况下数据的正确与可靠。
https://blog.csdn.net/cnh294141800/article/details/53768464?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522164568287516780366582083%2522%252C%2522scm%2522%253A%252220140713.130102334…%2522%257D&request_id=164568287516780366582083&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2allsobaiduend~default-2-53768464.first_rank_v2_pc_rank_v29&utm_term=paxos&spm=1018.2226.3001.4187
paxos算法是通过事务id与投票机制来确定
ZAB广播
通过广播和分阶段两次提交的形式,来保证过半的人是最新数据,来达到效率更高的效果
Watch手表监控观察
两个client可以通过心跳的方式来确保对方是否还在连接,但是会比较多慢
更快的方法就是通过监控对方的临时节点来确定对方是否正常连接
Zookeeper的分布式锁
什么情况下使用锁
多个线程多同意资源的访问,要保证在该资源下,同步执行(只能执行一个)
zookeeper分布式锁的各种情况
1、多个线程争抢锁,只有一个人能获取锁
2、获得锁的人出现问题保证不死锁,需要设置基于session的临时节点,这样当获取锁的人挂掉了,锁会随着session的消失而消失
3、获取锁的人没有出现问题,释放锁
4、锁被释放,删除,别人怎么知道的?
4.1、主动轮询,心跳,每一秒进行一次获取锁的操作
弊端:a、锁可能有延迟 b、假设一千个每一秒进行一次轮询,会对zookeeper造成压力
4.2、watch:解决延迟问题
弊端:当过期还是会有多个同时争抢锁,还会造成压力
4.2、sequen(序列节点)+watch:watch自己的前一个序列节点,最小的序列节点获取锁,当它释放锁,只有他的下一个会watch到,同时获取锁
优势:zk只给他的下一个线程产生回调
5、重入锁