ZOOKEEPER的理论框架图
2021-09-27 08:56:43 0 举报
zookeeper理论框架图,扫盲专用
作者其他创作
大纲/内容
node01
原子:成功、失败。没有中间状态(队列+2PC)广播:分布式多借点的。全部知道!(过半)队列:FIFO,顺序性zk的数据状态在内存用磁盘保存日志
ZOOKEEPER: 分布式协调服务
ok
扩展性
临时节点
完成分布式协调分布式锁
Leader
zookeeper分布式协调扩展,可靠性,时序性快速!!!!
读写分离observer放大查询能力
比较碎
持久节点
队列
M 1Z 8
1create(ooxx)
4-2write
client
M 4Z 8
Follower
node02+3
4-2 write
node02
框架架构
心跳验证
follower
分布式锁临时节点
session8
1,leader肯定会挂2,服务不可用3,不可靠的集群4,事实,zk集群及其高可用5,如果有一种方式可以快速的恢复出一个leader
心跳,自己实现watch基于zk方向性、时效性
角色
ZAB作用在可用状态有Leader时
及时性 - 系统的客户视图保证在特定时间范围内是最新的。
Client
leader
队列式事务的锁
1,统一配置管理<- 1M数据2,分组管理 <- path结构3,统一命名 <- sequential4,同步 <- 临时节点
4台机器过半3台
1,场景,第一次启动集群2,重启集群,leader挂了后
over-ok
node可以存数据1MB
可靠性 - 一旦应用了更新,它将从那时起持续到客户端覆盖更新。
原子性 - 更新成功或失败。没有部分结果。
Watch 手表 监控 观察
/ooxx/a会有事件:eventcreatedeletechangechildren
不要把zookeeper当数据库用
M 2Z 8
特征/保障
1,paxos2,ZAB3,watch4,API : 不怕写zk client5,callback -> reactive 响应式编程更充分压榨OS,HW 资源、性能
4-1-ok
session
node:/ooxx/a
client代码实现
序列节点
https://www.douban.com/note/208430424/
顺序一致性 - 客户端的更新将按发送顺序应用。
分布式
write
锁依托一个父节点且具备-s代表父节点下可以有多把锁
统一视图目录树结构
zookeeper有2中运行状态1,可用状态2,不可用状态3,不可用状态恢复到可用状态应该越快越好
统一视图 - 无论服务器连接到哪个服务器,客户端都将看到相同的服务视图。
4-1:log
可靠性
安装 验证 简单使用
zoo.cfgserver.1=node01:2888:3888server.2=node02:2888:3888server.3=node03:2888:3888server.4=node04:2888:3888:observer
Observer
只有Follower才能选举
2create(ooxx)
node04
M 3Z 7
快速恢复Leader
200ms恢复?
node03
zookeeper是一个目录树结构
攘其外必先安其内
Followersync可选项!
HA,选主
http://zookeeper.apache.org/
session+Enode
攘其外一致性?最终一致性*过程中,节点是否对外提供服务!!!
数据 可靠 可用一致性
3888: 选主投票用的2888: leader接受write请求
redis单实例的内存-快复制集群HA sentinel不是绝对的实时同步可能连最终一致性都谈不上集群模式 分片
3,callback
0 条评论
下一页