zookeeper分布式协调

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-2_allsobaiduend~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、重入锁