zookeeper在分布式中的地位
在分布式组件中,比如redis、kafaka,都能看到zookeeper思想。可以认为,zk在分布式这一块是非常成功的。分布式系统相关理论
zookeeper的本质
zk最核心的,是在集群高并发环境中,使用zab协议保证节点数据的最终一致性,可用于服务发现,分布式锁,分布式领导选举,配置管理等。zk的一次数据写入过程本质上是一次2PC提交的过程。
zookeeper数据结构
zk是树状结构,有唯一一个根结点。
zk数据节点如何保证安全
使用zab协议保证数据节点安全。zab协议
zk数据节点的监听机制
zk服务端提供了基于节点创建、删除、修改的监听机制。zk客户端使用-w参数可以告诉服务端,自己要监听这个节点信息。
zk的支持的节点类型
- PERSISTENT:持久的节点。
- EPHEMERAL:暂时的节点。断开客户端连接后,自动删除。
- PERSISTENT_SEQUENTIAL:持久化顺序编号目录节点。持久节点后自动拼接递增数字。
- EPHEMERAL_SEQUENTIAL:暂时化顺序编号目录节点。
zk数据节点的权限设置
zk服务端允许给节点设置权限,其他客户端如果要对节点做操作,必须在会话中携带权限信息。
- 创建节点并设置权限,格式是name:pwd:authlist。权限列表c-创建,d-删除,w-写,r-读,a-设置权限。
create /test abc auth:xiaoming:123456:cdwra
- 其他客户端会话中携带权限信息(添加摘要)才能操作该节点,digest-摘要。
addauth digest xiaoming:123456
Curator客户端
guava对java的支持,正如curator对zookeeper的支持。使用Curator操作zk客户端非常方便。后面也将使用Curator来操作zookeeper。
zk实现分布式锁
读锁
- 创建一个临时序号节点,节点数据为read,表示读锁
- 获取比自己小的所有兄弟节点
- 判断最小的节点是不是读锁,如果是读锁,则获取读锁成功。否则,进入在该节点设置监听,阻塞等待。唤醒后,继续步骤2。
写锁
- 创建一个临时序号节点,节点数据是write,表示写锁
- 获取所有兄弟节点
- 判断自己是否是最小节点。如果是,获取写锁成功。如果不是,监听最小节点,阻塞等待。唤醒后进入步骤2。
羊群效应
如果用上述上锁方式,只要节点变化,就会触发所有节点的监听,这对zk的压力是非常大的。可以调整为链式监听,即监听自己的上一个节点。本质上不要让所有客户端都去监听同一个节点,而是分摊开来。curator客户端已经帮助我们实现了这点。
zookeeper中NIO和BIO的应用
NIO
- 客户端连接服务端时,使用NIO与客户端建立连接
- 客户端watch服务端时,使用NIO等待客户端的回调
BIO
集群在选举时,多个投票的端口,使用BIO通信