zookeeper 学习,详细了解
角色:leader:主节点,负责数据的写入follower:从节点,负责数据的读取observer:功能一就如同他的名字,只是一个观察者,对leader和follower的工作进行观察监听。 功能二就是动态扩展zookeeper集群,而又不影响集群的性能,接收客户端连接,执行leader更新系统状态的命令,不影响集群的性能是因为观察者节点不参与投票,即使是观察者节点宕机了,对集群的运行状态没有影
ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。
顺序一致性:客户端的更新将按顺序应用(主节点负责写)
原子性:更新要么成功要么失败
单个系统映像:无论客户端连接到哪个服务器,客户端都将看到相同的服务视图。也就是说,即使客户端故障转移到具有相同会话的其他服务器,客户端也永远不会看到系统的较旧视图
可靠性:应用更新后,此更新将一直持续到客户端覆盖更新为止。
及时性:确保系统的客户视图在特定时间范围内是最新的。
zookeeper 使用的是最终一致性。作为协议协议的一部分,来自客户端的所有写请求都转发到称为领导者的单个服务器。
zk的数据存在内存,用磁盘来保存日志。
角色:
leader:主节点,负责数据的写入
follower:从节点,负责数据的读取
observer:功能一就如同他的名字,只是一个观察者,对leader和follower的工作进行观察监听。
功能二就是动态扩展zookeeper集群,而又不影响集群的性能,接收客户端连接,执行leader更新系统状态的命令,不影响集群的性能是因为观察者节点不参与投票,即使是观察者节点宕机了,对集群的运行状态没有影响。
只有follower 才能选举。follower越少选举速度越快。其余的为observer即可,放大查询能力。
zookeeper 需要启动前在配置文件中配置好有那些节点,以及端口。例如 server.1=zoo1:2888:3888 3888 是用来节点间传递消息的。过半选举推荐机制。 server.后面的值越大越容易选举为主节点。
zookeeper目录节点分类:
临时节点 和 永久节点
临时节点:zookeeper有一个session的概念,当session断开,创建的临时节点对应消失。
永久节点:一直存在,相当于持久化。
Persistent是临时节点、
Persistent_sequential是临时有序节点。如00000、000001.....
Ephemeral是永久节点、
Ephemeral_sequential是永久有序节点
CreateMode.PERSISTENT_SEQUENTIAL 对应命令 create -s -e /path CreateMode.PERSISTENT 对应命令 create -e /path CreateMode.Ephemeral 对应命令 create /path CreateMode.Ephemeral_sequential 对应命令 create -s /path
-s 即代表序列的意思。临时节点不能有子节点
简单的API
ZooKeeper的设计目标之一是提供一个非常简单的编程界面。因此,它仅支持以下操作:
-
create:在树中的某个位置创建一个节点
-
delete:删除节点
-
存在:测试某个位置是否存在节点
-
获取数据:从节点读取数据
-
设置数据:将数据写入节点
-
获取子节点:获取节点子节点的列表
-
sync:等待数据传播
使用命令:get /目录信息
cZxid=0x200000002 创建事务ID
mZxid=0x200000004 修改事务ID
pZxid=0x200000002 当前节点最后创建事务的ID(属于自己的事务ID)
ephemeralOwner=64325234 当前节点归属的session ID
cZxid 是一个64位的数字,高32位代表leader节点id,当新的leader产生则会发生变化,低32位用来递增。
当A连上1,产生一个sessionId,当1挂掉了,A去连接 2 。此时,2也会认A的这个sessionId。因为zookeeper每个节点间的数据长得都是一样的,会进行同步。包括A在1上面产生的数据。
当第一个客户端创建一个目录数据得到 cZxid = 0x800000a22
第二个客户端连接并创建目录数据得到 cZxid = 0x800000a24
新客户端进行连接的时候会消耗掉一个 cZxid ,即 0x800000a23 被消耗掉了。
无论客户端连入还是删除节点等都会消耗一个事务ID
zookeeper选举
每个节点有自己的mid,不同的zxid。
当leader挂掉后,zxid(事务ID)最新的可以获得投票,当投票数过半可以获得选举。如果很多个zxid都相同,则mid最大的被选为leader。
当选出leader后, czxid 、mxid、pzxid 的 高32位都会在上一个leader 事务ID 的基础上+1,后续节点的操作ID会从当前leader 对应的 czxid 高32位 重新开始递增。在这个leader之前的节点信息的事务ID保持不变,除非发生更改。
ZAB协议
一、消息广播:过半通过
leader将客户端的请求记录为一个 Proposal 提议,并为每个follower 准备了一个fifo队列,队列里面放的就是 Proposal ,所以多个 Proposal 都是顺序性的。然后每个fifo 队列里的消息会广播到对应的 follower去,并对 Proposal 做出 ack 反馈。当leader 收到半数(包括自己)的 ack 后,这个 Proposal 则通过了,及时其余的follwer没有反馈。leader 开始对所有的follower 进行通知 commit 写入。
二、崩溃恢复:数据最全的做主
当leader进行通知的时候,如果leader挂了怎么办呢?
当leader挂了,follower 开始进行选举。A 、B、C 开始拿出自己的 ZXID 选举,ZID最大的那一个选举成功。如果最后发现都一样,就拿出各自的 id 选举,最大的那一台当选。
为什么ZXID最大的选举可以成功?
ZXID 和 Proposal 挂钩,最大的说明数据最全。ZXID是过半通过之后才代表成功写入的,即大家都赞同的,就是说最大的ZXID是半数以上的 follower 都有的。
https://baijiahao.baidu.com/s?id=1666465070459184658&wfr=spider&for=pc
zookeeper多节点配置
修改zoo.cnf
server.1=127.0.0.1:2888:3888
server.2=127.0.0.2:2888:3888
server.3=127.0.0.3:2888:3888
server.4=127.0.0.4:2888:3888
- 2888 -- leader与follower 之间的通信
- 3888 -- leader挂掉时节点间的通信。
- 2181: 对外提供服务的端口
本机多台的话配置:
server.1=127.0.0.1:2888:3888 server.2=127.0.0.1:2889:3889 server.3=127.0.0.1:2890:3890
mq 对比
https://blog.csdn.net/liuzhixiong_521/article/details/84849184
rabbitmq 支持exchange(交换器)功能
更多推荐
所有评论(0)