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