目录
zookeeper集群的搭建:
配置解释:
特点:
常规搭建方式,进行操作:
A.关闭防火墙(测试环境)
B.启动 服务,每个规划的 zookeeper 节点都要进行启动
C.启动客户端
D.命令使用
1. help
2. ls 查看当前存在的根目录
3. znode 节点
4. create 创建节点
a. 创建临时节点,获得临时节点的数据
b.创建持久化节点,获得临时节点的数据
c.创建子节点
d.创建孙子节点
e.znode节点数据结构
E.数据同步
恢复模式
广播模式
zookeeper集群的搭建:
1. 常规的搭建(推荐)??
2. docker 容器搭建?
?
配置解释:
tickTime:发送心跳的间隔时间,单位:毫秒
dataDir:zookeeper保存数据的目录。
clientPort:客户端连接 Zookeeper 服务器的端口,Zookeeper 会监听这个端口,接受客户端的访问请求。
initLimit: 这个配置项是用来配置 Zookeeper 接受客户端(这里所说的客户端不是用户连 接 Zookeeper 服务器的客户端,而是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器)初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 5 个心跳的 时间(也就是 tickTime)长度后 Zookeeper 服务器还没有收到客户端的返回信息,那么表 明这个客户端连接失败。总的时间长度就是 5*2000=10 秒
syncLimit:这个配置项标识 Leader 与 Follower 之间发送消息,请求和应答时间长度,最长不能超过多少个 tickTime 的时间长度,总的时间长度就是 2*2000=4 秒
server.A=B:C:D:其 中 A 是一个数字,表示这个是第几号服务器;B 是这个服务器的 ip 地址;C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口;D 表示的是万一 集群中的 Leader 服务器挂了,需要一个端口来重新进行选举,选出一个新的 Leader,而这 个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式,由于 B 都是 一样,所以不同的 Zookeeper 实例通信端口号不能一样,所以要给它们分配不同的端口号
?
特点:
角色功能:?
领导者(leader)负责进行投票的发起和决议,更新系统状态
学习者(learner)包括跟随者(follower)和观察者(observer),follower用于接受客户端请求并向客户端返回结果,在选主过程中参与投票
Observer可以接受客户端连接,将写请求转发给leader,但observer不参加投票过程,只同步leader的状态,observer的目的是为了扩展系统,提高读取速度
客户端(client)请求发起方
?集群特点:
特点说明
最终一致性为客户端展示同一个视图,这是zookeeper里面一??个非常重要的功能
可靠性如果消息被一台服务器接受,那么它将被所有的服务器接受。
实时性Zookeeper不能保证两个客户端能同时得到刚更新??的数据,如果需要最新数据,应该在读数据之前调??用sync()接口。
独立性各个Client之间互不干预
原子性更新只能成功或者失败,没有中间状态。
顺序性所有Server,同一消息发布顺序一致。
?
常规搭建方式,进行操作:
A.关闭防火墙(测试环境)
systemctl stop firewalld.service
B.启动 服务,每个规划的 zookeeper 节点都要进行启动
zkServer.sh status
C.启动客户端
zkCli.sh
D.命令使用
1. help
2. ls 查看当前存在的根目录
3. znode 节点
ls 显示的节点: 数据模型Znode, 不是file 文件
znode 数据模型: 层次的,目录型结构,包含最大1MB的数据信息,记录了Zxid等元数据信息
Znode有两种类型,短暂的(ephemeral)和持久的(persistent)
Znode的类型在创建时确定并且之后不能再修改
Znode有四种形式的目录节点
PERSISTENT? ?
EPHEMERAL? ?
PERSISTENT_SEQUENTIAL? ?
EPHEMERAL_SEQUENTIAL
4. create 创建节点
a. 创建临时节点,获得临时节点的数据
短暂znode的客户端会话结束时,zookeeper会将该短暂znode删除,短暂znode不可以有子节点
create -e /tmp xiaoming
get /tmp
?
查看节点的详细信息
get -s /tmp
?
b.创建持久化节点,获得临时节点的数据
创建序列节点(不指定 -e 参数,则表示是持久化节点)====》持久化的序列节点
create -s /yang yang
c.创建子节点
create /yang0000000049/zzu zzu
获得子节点的数据
get -s /yang0000000049/zzu
d.创建孙子节点
create /yang0000000049/zzu/abc abc
?
e.znode节点数据结构
get -s /tmp
znode数据模型的数据?
xiaoming节点数据
cZxid = 0x470000006b创建的事务id(递增的形式)
ctime = Sat Oct 03 10:54:44 CST 2020创建时间
mZxid = 0x470000006b修改的事务id (递增的形式)
mtime = Sat Oct 03 10:54:44 CST 2020修改时间
pZxid = 0x470000006b最新创建的子节点的事务id
cversion = 0?
dataVersion = 0?
aclVersion = 0?
ephemeralOwner = 0x2001b8d03f80007表示临时节点(持久化的节点的值为: 0x0)
dataLength = 8节点数据的长度
numChildren = 0直接的子节点的数量,不包含孙子节点
?
E.数据同步
原子广播,实现这个机制的协议叫做Zab协议。
Zab协议有两种模式: 恢复模式? ? ? ? 广播模式。
恢复模式
当服务启动或者在领导者崩溃后 Zab就进入了恢复模式, 当领导者被选举出来,且大多数server的完成了和leader的状态同步以后,恢复模式就结束了。
leader 选举
在无主的模型下首先进行的是自我投票,在选举过程中,如果发现对方的zxid 比自己的大,则选择对方为主,否则选择自己
广播模式
广播模式需要保证提议(proposal)被按顺序处理,因此zk采用了递增的事务id号(zxid)来保证。 所有的提议 ?(proposal)都在被提出的时候加上了zxid。 实现中zxid是一个64为的数字,它高32位是epoch用来标识 ?leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch,低32位是个递增计数。
提议,比如说创建表的时候会产生,cZxid、mZxid、pZxid 同一个 Zxid 被成为是一个 提议
提议的概念是从?paxos (帕克西)算法来的。
按照从客户端发起请求1,到收到请求6? 这个过程中,?比如说是创建一个节点
这个时候收到请求的节点会向主节点发送请求,
主机节点生成一个 提议(pronosal)广播到所有的从节点(follower)出去,
当超过半数的 从节点(follower)返回 ack(同意信息),则该条提议通过,
主节点向全部的节点(从节点(follower)和观察节点(observer)) 广播进行通知该 提议(pronosal)
之后当其他客户端访问任意一个从节点的时候,都能返回 刚才创建的节点的信息?