zoo.cfg配置文件
tickTime:用于计算的时间单元。比如session超时:N*tickTime
initLImit:用于集群,允许从节点连接并同步到master节点的初始化连接时间,以tickTime的倍数来表示
syncLimit:用于集群,master主节点与从节点之间发送消息,请求和应答时间的长度。(心跳机制)
dataDir:数据存放位置,必须配置。
dataLogDir:日志目录,如果不配置会和dataDir公用。
clientPort:连接服务器的端口,默认2181
基本概念
- zk的数据模型也可以理解为Linux/Unix的文件目录:/usr/local/..
- 每一个节点都称之为znode,它可以有子节点,也可以有数据。
- 每个节点分为临时节点和永久节点,临时节点在客户端断开后消失。
- 每个zk节点都有各自的版本号,可以通过命令行来显示节点信息。
- 每当节点数据发生变化,那么该节点的版本号会累加(乐观锁)。
- 删除/修改过时??节点,版本号不匹配则会报错。
- 每个zk节点存储的数据不宜过大,几K即可。
- 节点可以设置权限acl,可以通过权限来限制用户的访问。
zk作用体现
- master节点选举,主节点挂了以后,从节点就会接手工作,并且保证这个节点是唯一的,这也是所谓首脑模式,从而保证我们的集群是高可用的。
- 统一配置文件管理,即只需要部署一台服务器,就可以把相同的配置文件同步更新到其他所有服务器,此操作在云计算中用的特别多(假设修改了redis统一配置)
- 发布与订阅。类似消息队列MQ(amq,rmq...),dubbo发布者把数据存在znode上,订阅至会读取这个数据。
- 提供分布式锁,分布式环境中不同进程之间争夺资源,类似于多线程中的锁。
- 集群管理,集群中保证数据的强一致性。
zk特性——watcher机制
- 针对每个节点的操作,都会有一个监督者-->watcher。
- 当监控的某个对象(znode)发生了变化,就会触发watcher事件。
- zk中的watcher是一次性的,触发后立即销毁。
- 父节点,子节点增删改都能够触发其watcher。
- 针对不同类型的操作,触发的watcher事件也不同:1)(子)节点创建事件。2)(子)节点删除事件。3)(子)节点数据变化事件。
ACL的构成
- zk的ACL通过[scheme : id : permissions]来构成权限列表
scheme:代表采用的某种权限机制
id:代表允许访问的用户
permissions:权限组合字符串
scheme
- world:world下只有一个id,即只有一个用户,也就是anyone,那么组合的写法就是world:anyone:[permissions]
- auth:代表认证登录,需要注册用户有权限就可以,形式为auth:user:password:[permissions]
- digest:需要对密码加密才能访问,组合形式为digest:username:BASE64(SHA!(password)):[permissions]
简而言之,auth与digest的区别就是,前者明文,后者密文
setAcl /path auth:username:password:cdrwa
与
setAcl /path auth:username:BASE64(SHA!(password)):cdrwa
是等价的,在通过
addauth digest username:password后都能操作指定节点的权限。
permissions权限字符串缩写 crdwa
c:创建子节点
r:获取节点/子节点
d:删除子节点
w:设置节点数据
a:设置权限
world:anyone:cdrwa
auth:user:pwd:cdrwa
digest:user:BASE64(SHA1(pwd)):cdrwa
addauth digest user:pwd