zookeeper简介与梳理

zookeeper就是分布式的注册中心

配置文件

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/app/soft/zookeeper-3.4.6/data (换成真实输出目录)
clientPort=2181
#tickTime:这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔,也就是每个 tickTime 时间就会发送一个心跳,以毫秒为单位。
#initLimit:LF初始通信时限,集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数(tickTime的数量)
#syncLimit:集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数(tickTime的数量)。
#dataDir:顾名思义就是 Zookeeper 保存数据的目录,默认情况下,Zookeeper 将写数据的日志文件也保存在这个目录里。
#clientPort:这个端口就是客户端连接 Zookeeper 服务器的端口,Zookeeper 会监听这个端口,接受客户端的访问请求。   
#dataLogDir:日志文件目录,Zookeeper保存日志文件的目录
#服务器名称与地址:集群信息(服务器编号,服务器地址,LF通信端口,选举端口),规则如:server.N=yyy:A:B
#其中N表示服务器编号,YYY表示服务器的IP地址,A为LF通信端口,表示该服务器与集群中的leader交换的信息的端口。B为选举端口,表示选举新leader时服务器间相互通信的端口(当leader挂掉时,其余服务器会相互通信,选择出新的leader)。一般来说,集群中每个服务器的A端口都是一样,每个服务器的B端口也是一样。但是当所采用的为伪集群时,IP地址都一样,只能时A端口和B端口不一样。
server.1= 127.0.0.1:2888:3888
server.2= 127.0.0.1:2889:3889
server.3= 127.0.0.1:2890:3890

#server.A=B:C:D  其中A是一个数字,代表这是第几号服务器;B是服务器的IP地址;C表示服务器与群集中的“领导者”交换信息的端口;当领导者失效后,D表示用来执行选举时服务器相互通信的端口。
zkServer.sh status可以查看该服务器是什么类型的服务器

1.节点

主要分为临时节点和永久节点,其中又分为无序和有序

2.选举

选举服务器最好是基数,因为zookeeper的可用性是只要在一半以上服务器可用就整体可用,偶数个比及数个更浪费,5个服务器可损失的服务器是2个,6个服务器可损失的服务器也是两个,过半原则导致偶数服务器看上去有些浪费。

2.1选举在leader和follower中进行,比较zxid,如果zxid一致则比较myid,myid是可以设置的,在zoo.cfg中server.0=ip:port1:port2

其中0就是myid,ip就是各个服务器的ip地址,port1是leader和followerd的通信端口,port2是leader和follower的选举端口

在 ZAB 协议的事务编号 ZXID 设计中,ZXID 是一个 64 位的数字,其中低 32 位可以看作是一个简单的递增的计数器,针对客户端的每一个事务请求,Leader 都会产生一个新的事务 Proposal 并对该计数器进行 + 1 操作。

而高 32 位则代表了 Leader 服务器上取出本地日志中最大事务 Proposal 的 ZXID,并从该 ZXID 中解析出对应的 epoch 值,然后再对这个值加一。

高 32 位代表了每代 Leader 的唯一性,低 32 代表了每代 Leader 中事务的唯一性。同时,也能让 Follwer 通过高 32 位识别不同的 Leader。简化了数据恢复流程。

基于这样的策略:当 Follower 链接上 Leader 之后,Leader 服务器会根据自己服务器上最后被提交的 ZXID 和 Follower 上的 ZXID 进行比对,比对结果要么回滚,要么和 Leader 同步。

3.脑裂

如果leader和两个follower在一个网络区域,另外三台follower在一个网络区域,当两个网络区域断掉的时候,实施重新选举。

3.1情况一,选举出新leader后联通,则使用新leader

3.2情况二,在选举时原有leader联通了,则使用原有leader

4.同步

ZAB协议是为zookeeper专门设计的一种支持奔溃恢复的原子广播协议。

ZAB协议主要的作用在于三个方面1、选举出leader;2、同步节点之间的状态达到数据一致;3、数据的广播

假设1:Leader 在复制数据给所有 Follwer 之后崩溃,怎么办?
假设2:Leader 在收到 Ack 并提交了自己,同时发送了部分 commit 出去之后崩溃怎么办?

针对这些问题,ZAB 定义了 2 个原则:

  1. ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。
  2. ZAB 协议确保丢弃那些只在 Leader 提出/复制,但没有提交的事务。

所以,ZAB 设计了下面这样一个选举算法:
能够确保提交已经被 Leader 提交的事务,同时丢弃已经被跳过的事务。

针对这个要求,如果让 Leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群总所有机器编号(即 ZXID 最大)的事务,那么就能够保证这个新选举出来的 Leader 一定具有所有已经提交的提案。
而且这么做有一个好处是:可以省去 Leader 服务器检查事务的提交和丢弃工作的这一步操作。

5.zookeeper观察者

首先,在每一个想要成为观察者节点的配置文件中,你必须加入这一行:

peerType=observer  这一行告诉ZK这个服务端想要成为观察者。

第二,在每一个服务端的配置文件中,你必须在每一个观察者的服务者定义那一行加入:observer。例如:

server.1=localhost:2181:3181:observer

这告诉每一个其它服务端server.1是一个观察者,并且他们应该不要求它来投票。这是所有你需要增加的配置。现在你可以连接上它就好像它是一个普通的追随者。试试。通过运行下面的命令:

bin/zkCli.sh -server localhost:2181

 

这里的localhost:2181是观察者的主机名和端口号,正如在每一个配置文件中指定的那样。你应该可以看到一个命令行提示,通过它你可以发起像ls的命令来查询ZK服务。

6.zookeeper分布式锁

https://www.jianshu.com/p/5d12a01018e1

7.调用

https://blog.csdn.net/shaun_luotao/article/details/87098482

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章