概览
https://zookeeper.apache.org/
前面用redis实现分布式锁的时候,会显得很复杂;用zookeeper实现会简单很多
当然,zookeeper不只用来实现分布式锁,还有很多其他的功能.
ZooKeeper是用于分布式应用程序的分布式,开放源代码协调服务。
它公开了一组简单的原语,分布式应用程序可以基于这些原语来实现用于同步,配置维护以及组和命名的更高级别的服务。
使用了按照文件系统熟悉的目录树结构样式设置的数据模型。
zk也是二进制安全的,按byte[]存储.
- ZooKeeper很简单。
ZooKeeper允许分布式进程通过共享的分层名称空间相互协调,该命名空间的组织方式类似于标准文件系统。名称空间由数据寄存器(在ZooKeeper中称为znodes)组成,它们类似于文件和目录。
与设计用于存储的典型文件系统不同,ZooKeeper数据保留在内存中,这意味着ZooKeeper可以实现高吞吐量和低延迟数。 - 以主从复制的形式实现高可用集群,一个leader,多个follower,读写分离,leader读写,follower读.
如果leader挂了,进入无主状态,它可以快速的重新选一个leader(官方压测不到200ms) - 每个client连接到zk时,都会产生一个session作为身份标识,每个session对应一个临时节点,当client挂了或者断开连接时,session就消失了
之前我们用redis实现分布式锁时,要设置过期时间,还要再起个线程监听它挂没挂;
如果用zk,客户端连接到zk,建立了session会话,在zk里创建了一把锁,客户端挂掉后锁就释放了,也可以手动释放锁;依靠session这把锁可以很简单的实现. - 目录树结构,类似与文件系统,每个节点都可以存1M内的数据(二进制安全);
节点分为持久节点和临时节点,临时节点依托于session
只要创建znode的会话处于活动状态,这些znode就会存在。会话结束时,将删除znode.
ZK旨在分布式协调,不要把它当数据库用,即不要频繁的写,因为ZK的优势在于读
曾经的Spark消费Kafka里的数据,会把消费的offset记录到zk里, 以做到分布式协调;但这其实是把ZK当数据库用了,频繁的修改数据,不能发挥ZK的优势. - 节点支持序列化,
- 特点:
顺序一致性,客户端的更新将按发送顺序应用(写操作转交给leader)
原子性,写操作会写到每一个节点上(最终一致性)
单系统镜像,无论客户端连接到哪个服务器,客户端都将看到相同的服务视图(包括session,也统一)。
可靠性(持久性)-应用更新后,此更新将一直持续到客户端覆盖更新为止。
及时性-确保系统的客户视图在特定时间范围内是最新的(最终一致性)。
性能测试图:
this is a throughput graph of ZooKeeper release 3.2 running on servers with dual 2Ghz Xeon and two SATA 15K RPM drives.
安装
需要安装JDK>=1.7
官网下载解压zookeeper后,进入conf文件夹,
复制出一份配置文件cp zoo_sample.cfg zoo.cfg,
然后编辑 zoo.cfg,常用配置说明:
- tickTime=2000 心跳间隔,单位时毫秒
- initLimit=10 节点间日常同步时,超过多少个心跳后就认为该节点有问题
- syncLimit=5 写操作时,follower响应,超过多少个心跳后就认为该follower有问题
- dataDir=/data/data/zookeeper 快照的存储路径
- clientPort=2181 客户端连接时的端口号
- #maxClientCnxns=60 最大客户端连接数
当leader挂掉后,需要投票选出新leader,“过半通过”;在redis的哨兵主从模式下,我们不需要配置所有节点,需要手动配置一个"票数"