zookeeper:
linux下基本zookeeper安装。
基本数据模型介绍:
1.树形结构tree,或者路径结构/(可以理解为window/linux的文件目录/usr/local/...)。
2.每个节点都称之为znode,它可以有子节点,也可以有数据
3.每个节点分为临时节点或者是永久节点,临时节点在客户端断开后消失
4.每个zk节点都有各自版本号,可以用命令行来显示节点信息
5.每当节点数据发生变化,节点的版本号会累加(乐观锁)
6.删除/修改过时节点,版本号不匹配则会报错。
7.每个zk节点存储节点不一过大,几k即可。
8.节点可以设置权限acl,可以通过权限来限制用户的访问
常用基本命令:
zk服务命令
1. 启动ZK服务: bin/zkServer.sh start
2. 查看ZK服务状态: bin/zkServer.sh status
3. 停止ZK服务: bin/zkServer.sh stop
4. 重启ZK服务: bin/zkServer.sh restart
5. 连接服务器: zkCli.sh -server 127.0.0.1:2181
6. 查看命令/帮助:help
命令行工具的一些常用操作命令如下:
1.ls -- 查看某个目录包含的所有文件,例如:
[zk: 127.0.0.1:2181(CONNECTED) 1] ls /
2.ls2 -- 查看某个目录包含的所有文件,与ls不同的是它查看到time、version等信息,例如:
[zk: 127.0.0.1:2181(CONNECTED) 1] ls2 /
3.create -- 创建znode,并设置初始内容,例如:
[zk: 127.0.0.1:2181(CONNECTED) 1] create /test "test"
Created /test
创建一个新的 znode节点“ test ”以及与它关联的字符串
4.get -- 获取znode的数据,如下:
[zk: 127.0.0.1:2181(CONNECTED) 1] get /test
5.set -- 修改znode内容,例如:
[zk: 127.0.0.1:2181(CONNECTED) 1] set /test "ricky"
6.delete -- 删除znode,例如:
[zk: 127.0.0.1:2181(CONNECTED) 1] delete /test
7.quit -- 退出客户端
zk特性 - watcher机制 -
针对每个节点的操作,都会有一个监督者>watcher事件
当监控的某个对象(znode)发生了变化,则触发watcher事件
zk中的watcher是一次性的,触发后立即销毁(用第三方组件可以配置成永久性的)
父,子节点,增删改都能触发其watcher
ACL(access control lists)权限控制
针对节点可以设置相关读写等权限,目的为了保障数据安全性
权限permissions可以指定不同的权限范围以及角色(类似于shiro的权限控制)
getAcl:获取某个节点的acl权限
setAcl:设置某个节点的acl权限
addauth:输入认证授权信息,注册时输入明文密码登录,但是在zk的系统里,密码是以加密的形式存在的
ACL的构成
zk的acl通过[scheme:id:permissions]来构成权限列表
scheme:代表采用某种权限机制(4种)
id:代表允许访问的用户
permissions:权限组合的字符串
world:world只有一个id,既只有一个用户也就是anyone。那么组合的写法就是world:anyone:[permissions]
auth:代表认证登陆,需要注册用户有权限就行,写法是auth:user:password:[permissions]
digest:需要对密码加密才能访问,组合写法是digest:username:BASE64(SHA1(password)):[permissions]
auth和digest的区别就是,前者明文,后者密文。
ip:当设置为id指定对应的ip地址,此时限制ip访问,比如:ip:192.168.1.1:[permissions]
super:超级管理员,拥有所有权限
权限字符串缩写:crdwa
create:创建子节点
read:获取当前节点/子节点
write:设置节点数据
delete:删除子节点
admin:设置权限
acl的常用使用场景
开发/测试环境分离,可开发人员无权操作测试库的节点,只能查看。
生产环境上控制指定ip的服务可以访问相关节点,防止混乱。
zk集群,主从节点,心跳机制(选举模式)
判断是否已经胜出:
默认是采用投票数大于半数则胜出的逻辑。
选举流程简述:
目前有5台服务器,每台服务器均没有数据,它们的编号分别是1,2,3,4,5,按编号依次启动,它们的选择举过程如下:
服务器1启动,给自己投票,然后发投票信息,由于其它机器还没有启动所以它收不到反馈信息,服务器1的状态一直属于Looking。
服务器2启动,给自己投票,同时与之前启动的服务器1交换结果,由于服务器2的编号大所以服务器2胜出,但此时投票数没有大于半数,所以两个服务器的状态依然是LOOKING。
服务器3启动,给自己投票,同时与之前启动的服务器1,2交换信息,由于服务器3的编号最大所以服务器3胜出,此时投票数正好大于半数,所以服务器3成为领导者,服务器1,2成为小弟。
服务器4启动,给自己投票,同时与之前启动的服务器1,2,3交换信息,尽管服务器4的编号大,但之前服务器3已经胜出,所以服务器4只能成为小弟。
服务器5启动,后面的逻辑同服务器4成为小弟。
zk作用的体现:
1.master节点选举,主节点挂了以后,从节点就会接手工作,并保证这个节点是唯一的,这也是所谓的首脑模式,从二保证我们的集群高可用性。
2.统一配置文件管理,几只需要部署一台服务器,则可以把相同的配置文件同步更新到其他所有服务器上,此操作在云计算中用的特别多(假设修改了redis统一配置)
3.发布与订阅,类似于消息队列mq(amq,rmq...),dubbo发布者把数据存在znode上,订阅者会读取这个数据。
4.提供分布式锁,分布式环境中不同进程直接争夺资源,类似于多线程中的锁
5.集群管理,保证数据的强一致性。
zk中的死锁和活锁:
死锁:类似于悲观锁,顾名思义,悲观锁就是把表锁起来,等它操作完别人才可以进来操作。举例子:a,b,c排队上厕所。a进去把门关了,然后其他人就不能上厕所了,只能等a开门出来才能再进行操作。
活锁:类似于乐观锁,顾名思义,乐观锁就是在查询这个表的时候,其他人也可以进行操作。举例子:a,b,c排队上厕所。a进去没关门,b,c也可以进去等待或者聊聊天抽抽烟等待或者做其他操作,类似于能对表进行查询。
zk中的分布式锁
目的:数据的最终一致性
本站博客:www.wurao.xin