学习Dubbo需要用到注册中心,前来学习
ZooKeeper本身是分布式的,是一个为分布式应用提供协调服务的一个Apache项目,常用于注册中心
底层基于观察者模式设计,主要负责存储和管理数据并且接收观察者的注册,数据更新时通知观察者
ZK的数据模型和Linux的文件系统类似,整体看成一棵树,每个节点称为ZNode。每一个ZNode默认可存储1MB的数据,每个ZNode通过其路径唯一标识,其主要用于协调服务,而不是存储数据
1.2.1 节点类型分为:
1.2.2 节点数据分为:
[zk: 127.0.0.1:2181(CONNECTED) 0] get /dubbo
# data 存放的数据
192.168.XXX.XXX
# stat 格式化输出有下表内容
node 状态信息 | 解释 |
---|---|
cZxid | create ZXID,即该数据节点被创建时的事务 id |
ctime | create time,即该节点的创建时间 |
mZxid | modified ZXID,即该节点最终一次更新时的事务 id |
mtime | modified time,即该节点最后一次的更新时间 |
pZxid | 该节点的子节点列表最后一次修改时的事务 id,只有子节点列表变更才会更新 pZxid,子节点内容变更不会更新 |
cversion | 子节点版本号,当前节点的子节点每次变化时值增加 1 |
dataVersion | 数据节点内容版本号,节点创建时为 0,每更新一次节点内容(不管内容有无变化)该版本号的值增加 1 |
aclVersion | 节点的 ACL 版本号,表示该节点 ACL 信息变更次数 |
ephemeralOwner | 创建该临时节点的会话的 sessionId;如果当前节点为持久节点,则 ephemeralOwner=0 |
dataLength | 数据节点内容长度 |
numChildren | 当前节点的子节点个数 |
ACLZooKeeper 采用 ACL(AccessControlLists)策略来进行权限控制,类似于 UNIX 文件系统的权限控制
zoo.cfg
# 修改数据的存放地址
dataDir=../zkData
客户端操作需要添加依赖 Curator
命令比较简单,列出概要自己探索一下即可
# 创建节点
create [-e/-s] 节点 关联内容 create /howl 12346
# 更新节点内容
set 节点 关联内容 set /howl 11111
# 查看某路径的子节点
ls 节点路径 ls /howl
# 获取节点内容
get [watch监听] 节点 get /howl
# 删除节点
delete/rmr 节点 delete /howl
# 退出客户端
quit
其为半数机制,即集群中半数以上存活才有效。虽然配置文件中没有指定Master和Slave,但Leader是通过内部的选举机制临时产生的,其流程如下:
假设5台服务器一个个依次启动:
# 在 /zkData 目录下创建一个myid文件
touch myid
# 往里面添加编号,一个数字即可
1
#############Cluster###############
server.2 = 127.0.0.1:22:22
server.3 = 127.0.0.1:23:23
server.4 = 127.0.0.1:24:24
客户端与ZooKeeper建立会话是用TCP长连接的,使用心跳检测来保持会话有效,这个连接可请求响应,以及接收监听事件。断开时长不超过sessionTimeout,那么重连后之前创建的会话有效
多个系统访问锁节点
,那么每个系统都会在锁节点下
创建一个带序号的临时节点
序号最小的临时节点获取到锁,执行完操作则删除自身的临时节点
其余临时节点监听序号比自己小1的节点
最常见的集群就是主从复制了,采用Master选举方法。
Master负责提供写服务、而其他Slave负责异步同步数据,提供读服务
1. 协调者向参与者发送prepare,要参与者执行事务但不提交并记录undo,redo日志,执行后反馈给协调者
2. 当所有参与者准备好后,协调者发送commit请求,即参与者全提交、所有参与者没有准备则进行rollback
单点故障问题:协调者挂了
阻塞问题:协调者发送prepare请求阻塞挂了,参与者占有资源不释放
数据不一致:协调者发送了一部分commit就挂了
1. 向所有参与者发送CanCommit,查看是否都可以执行事务,是就进入预备状态
2. 向所有参与者发送PreCommit,参与者执行事务不提交写日志响应结果。若收到一阶段NO或超时,会群发中断请求
3. 在二阶段全部YES之后,群发DoCommit进行提交事务,并接收响应。若收到二阶段NO或超时,群发中断请求
解决了阻塞问题,有超时机制
Paxos算法是基于消息传递且具有高度容错特性的一致性算法,是目前公认的解决分布式一致性问题最有效的算法之一
1. 每个提案者提案时获取一个全局唯一性编号N,赋予提案
每个表决者接受某提案后,将编号存到本地,以后仅接受大于本地编号的提案,最后将最大编号反馈给提案者
2. 当提案者的提案超过半数表决者接受,那么此提案为真,群发此提案内容和编号
表决这收到为真的提案,比较自己本地最大编号,大于则接受,小于则反馈NO
有提案A被批准,提案B又批准,那么A编号小于B,重新提出编号+1的死循环
解决思路:只有一个提案者
参考: