赞
踩
zookeeper,它是一个分布式服务框架,是大数据中的重要组件,它是一个具有高吞吐量的分布式协调系统,它的主要作用是为分布式系统提供协调服务,如:统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
Dubbo官方推荐使用zookeeoer作为注册中心,注册中心负责服务地址的注册和查找,相当于目录服务。
什么是注册中心?举个简单的例子 ,就像字典目录 ,你要查个字, 找到目录, 然后找到对应的页, 然后字就找到了。
zk也是一个意思,把你要注册的服务给到zk ,然后这台服务就注册到zk上了, 当我们想通过zk找到一个服务的时候,zk把我们的请求指向这个对应的服务端上,你的请求就完美的过去了。
Zookeeper至少具有以下特点:
1)可以用作分布式锁,可以用于集群管理,统一管理配置信息,负载均衡。
2)高可用性。一个Zookeeper服务通常由多台服务器节点构成,只要其中超过一半的节点存活,Zookeeper即可正常对外提供服务,所以Zookeeper具有高可用的特性。
3)高吞吐量特性,Zookeeper具有高吞吐量的特性,故而有很好的性能表现。
CAP. - CAP指的是:数据一致性(Consistency)、服务可用性(Availability)、分区容错性(Partition tolerance)。 - CAP原则指的是:在一个分布式系统中,这三个要素最多只能同时实现两点,不可能三者兼顾。 - 分布式系统中,必须要容忍网络的卡顿和延迟,所以分布式系统必须有个P(即,分区容错性). - zookeeper保证的是CP, 即:数据一致性,分区容错性. eureka保证的是ap,即:服务可用性,分区容错性.
zookeeper保证的是C,数据一致性;即,任何时刻对ZooKeeper的访问请求能得到一致的数据结果,
同时分布式系统中,一定可能会有网络的卡顿和延迟,即,P,分区容错性;
zookeeper不能保证每次服务请求的可用性; 比如:在一些极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果。所以说,ZooKeeper不能保证服务可用性。
再比如,zookeeper在进行leader选举时,整个zookeeper集群都是不可用的。
当master主节点出现故障时,剩余的从节点们会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 而选举期间整个zookeeper集群都是不可用的,这就导致在选举期间,注册服务直接瘫痪;
所以说,ZooKeeper不能保证服务可用性。
注意,这里的服务可用性和zookeeper的高可用性是两码事;
Zookeeper具有高吞吐特性的主要原因有以下几点:
Zookeeper集群的任意一个服务端节点都可以直接响应读请求(写请求会不一样些),并且可以通过增加服务器节点进行横向扩展。这是其吞吐量高的主要原因。
Zookeeper将全部数据存储于内存中,从内存中读取数据,不需要进行磁盘IO,所以速度非常快。
Zookeeper的写请求,或者说事务请求,因为要进行不同服务器节点之间状态的同步,所以在一定程度上会影响其吞吐量。故而简单的增加Zookeeper的服务器节点数量,并不一定能够提升Zookeeper的吞吐量。服务器节点增加,有利于提升读请求的吞吐量,但会延长节点间数据同步的时间。
Zookeeper非常类似于一个文件系统,它的每个节点都叫数据节点(znode),znode节点上可以存储数据,也可以再产生多个子节点。 Zookeeper的节点不能称为目录或者文件,要叫做znode节点,既可以存储数据又可以产生子节点。
znode分为四种节点
持久节点,是最常见的Znode类节点,一旦创建将一直存在于Zookeeper中,即便服务器断开连接、zookeeper重启等,持久节点还是存在着的。除非通过删除操作进行删除,否则会永久的保存在zookeeper中。
只要客户端(即其他的服务模块)存储数据,会永久的保存在zookeeper中,并且会在zookeeper中生成一个唯一并且有序的节点,先进来的节点值较小。
当客户端断开连接后,会自动删除节点信息。
只要客户端(即其他的服务模块)存储数据,会生成一个唯一并且有序的节点,先进来的节点值较小。
当客户端断开连接后,自动删除该节点。
可以有多个客户端(即其他的服务模块)监听zookeeper的某一个znode节点.
每当被监听的节点,发生了增删改等操作之后,zookeeper就会通知给监听当前节点的所有客户端。
leader节点管理着整个zookeeper集群中的全部节点,leader节点主要负责写操作、和数据同步操作。
leader节点的写操作:
在Zookeeper中,只有leader节点可以进行写操作;
为了保证数据的同步,当leader节点进行写操作时,会对外广播(我这边变动了数据,你们那边也同步一下),当从节点们接收到广播后,会开始持久化新的数据到本地(此时还没有commit);
从节点持久化完成后,会给leader一个反馈; 当超过半数以上的从节点持久化完成后,leader节点会再次广播,通知从节点们开始commit。
最后,从节点都同步数据完毕,leader才算完成了一次写操作。
所以Zookeeper有一个特点:如果有超过半数的从节点持久化数据失败,那么此次写操作也宣布失败,所有的持久化的从节点全部回滚。
follower指的是追随leader的从节点,主要负责读操作。
follower从节点当接收到写操作的请求后,会第一时间将这个写操作请求呈交给leader主节点处理。
当leader主节点突然挂掉时,follower从节点们会发起投票选举,选举出新的leader。
observer观察者节点 和 follower从节点 几乎一样,也是追随leader,主要负责读操作;
也是当接收到写操作的请求后,会第一时间将这个写操作呈交给leader主节点处理.
不同的是:当leader主节点挂掉时,observer节点不会参与投票选举,它只会等待一个新的leader出现后,直接去追随新的leader。
如果leader已经存在,这个新节点会直接变为follower从节点,追随当前的leader节点.
如果leader不存在,该looking节点会直接发起一次选举leader的投票,直到leader选出来后,该节点再由looking变成follower从节点,去追随leader主节点。
zookeeper为了保证数据的有序性,会给每一个写操作的数据,编写一个全局唯一的zxid.
zxid是一个64位的数字:前32位会是由当前节点参与的选举次数决定,后32位是存储数据的全局唯一id。
因为先生成的节点值较小、后生成的节点值较大的特点,故而 后存储的数据的zxid 一定大于 先存储的数据的zxid。
拓展:zookeeper在执行写操作时,是不会阻塞IO的,每次收到写操作的请求后,leader主节点会先把这个请求放到一个队列中,然后挨个的进行处理。
答:zxid和myid;
哪个节点的zxid越大,说明数据越新越全,则会被选举为leader
每一个znode节点启动时,都会有一个全局唯一的myid(数字); 在选举leader时,如果zxid一致,则根据myid的值,来决定选举的leader.
详见: https://blog.csdn.net/qq_44750696/article/details/123759164
ZooKeeper的内部是一个分层的文件系统目录树结构,而且,同一个目录下只能有一个唯一的文件名。
临时有序节点;
先创建的节点的节点值比较小;
(1)创建一个目录mylock;
(2)线程A想获取锁,就必须先在mylock目录下创建一个 临时顺序节点;
(3)创建之后,线程A再查看一下mylock目录下所有的子节点,看一下是否存在有比自己这个临时有序节点还小的兄弟节点,如果不存在,则说明当前线程的顺序号最小,于是获得锁;
(4)同理,线程B也要先创建一个临时顺序节点,然后获取所有的节点,再判断自己的节点是不是最小节点。不是,则监听比自己次小的那个节点;
(5)线程A处理完请求,删除掉自己的节点,线程B监听到变更事件,再次判断自己是不是最小的节点,如果是则获得锁。还不是,则继续监听比自己次小的节点。
1. 查询节点. ls 节点名称 -> 查询当前节点下的子节点. get 节点名称 -> 查看当前节点的数据. 2. 创建节点. create [-s] [-e] path data acl 创建 [有序] [临时] 节点路径 节点数据 节点访问权限 3. 修改节点. set path data -> 修改指定节点的数据. 4. 删除节点. delete path -> 删除没有子节点的节点. rmr path -> 递归删除节点(慎用) 5. 查看节点状态. stat path -> 查看节点的状态...
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。