Zookeeper原理与简述
Zookeeper原理与实现
Zookeeper官网
zookeeper.apache.org
什么是ZooKeeper？
官网介绍:
ZooKeeper是一项集中式服务，用于维护配置信息，命名，提供分布式同步和提供组服务。所有这些类型的服务都以某种形式由分布式应用程序使用。每次实施它们时，都会进行很多工作来修复不可避免的错误和竞争条件。由于难以实现这类服务，因此应用程序最初通常会跳过它们，这会使它们在存在更改的情况下变得脆弱并且难以管理。即使部署正确，这些服务的不同实现也会导致管理复杂。
简单点说,zookeeper是为了帮助分布式项目做分布式协调的.我们的分布式服务往往会非常庞大,那么在各个服务中总会存在各种调用,配置,他们看起来混乱,难以管理,zookeeper的目的就是让你能拥有上帝视角,能够替我们管理这些服务之间的调用与配置.
Zookeeper部署集群结构图
在zookeeper中有两种运行状态
1.可用状态
2.不可用状态
我们使用zookeeper做协调服务,就需要保证服务的可用性,那么zookeeper是如何做到高可用的呢.
在实际项目中,我们的zookeeper leader是肯定会宕机,leader如果宕机会导致整个zookeeper集群不可用,如果服务不可用,说明该集群为一个不可靠的集群,然而事实上,zookeeper集群是及其高可用的,根据官网描述,zookeeper可以在200ms恢复集群的可用性.
官网描述中表明,zookeeper具有以下几个特性
1.顺序一致性 - 客户端的更新将按照发送顺序应用
2.原子性 - 更新要么成功,要么失败
3.统一视图 - 无论服务器连接到哪个服务器,客户端都将看到相同的服务视图
4.可靠性 - 一旦应用了更新,它将从那时起持续到客户端覆盖更新
5.及时性 - 系统的客户视图保证在特定时间范围内是最新的
zookeeper选主机制
在每个zookeeper节点中,服务都会占用2888,3888两个端口,这两个端口都是提供集群之间的通信,2888端口的作用是leader接收follower,observer节点write请求使用,3888节点是follower选主投票使用的,在正常集群中,节点启动三个,服务的选主机制就会运行,200ms内会选出leader节点,zookeeper的选主机制是谦让制的,即每个节点会有一个数字id,主节点往往是3个节点中最大id的那一个.但是当leader宕机需要重新选主的时候,zookeeper又是怎么进行的呢,leader宕机后,又如何保证数据的一致性的呢,zookeeper保证一致性的算法是zab算法,它是对paxos算法的一个简化版本,具体paxos算法推荐查看https://www.douban.com/note/208430424/.
在zookeeper中,每个节点的数据一旦发生新增,修改,删除,都会维护一个递增id(Zxid),leader如果宕机,3888端口就会造成节点间两两通信,只要有任何节点发起投票,都会触发准leader发起自己的投票,选票中包含每个节点自身维护的Zxid以及myid,各节点会首先会对比Zxid,如果Zxid相同,再比较myid,来确定新主,并且个子节点会从新的主节点中更新数据到最新.
Zookeeper存储结构
zookeeper的数据存储结构为一个目录树结构,类似于windows文件夹,每个节点可以存储1M容量的数据,节点分为持久节点,临时节点
持久节点:可以持久化保存在zookeeper节点中
临时节点:通过session建立连接创建临时节点,session一旦断开,临时节点会在一段时间后自动删除
持久节点与临时节点可以对其进行顺序化,顺序节点开启后会在节点后添加10位数字,保存当前节点当前的顺序是第几位.
zookeeper提供的元指令
zookeeper只提供简单的元指令,功能实现需要开发者自己实现,保证功能的灵活性.
1.create - 创建一个子节点
2.read - 从一个节点或者子节点列表中获取存储的数据
3.write - 写入数据到节点中
4.delete - 删除一个子节点
5.admin - 设置权限
3.write - 写入数据到节点中
4.delete - 删除一个子节点
5.admin - 设置权限
本文主要是对zookeeper的一些描述,纯属个人认知,若有失误,还请谅解.至于zookeeper如何实现分布式锁,配置中心等实践有时间会发布相关案例.