Zookeeper原理
2021-09-30 09:16:01 0 举报ZK内部原理
作者其他创作
大纲/内容
node01
ZOOKEEPER: 分布式协调服务
4-2 createok
zookeeper
完成分布式协调分布式锁
Leader
读写分离observer放大查询能力
持久节点
队列
1，争抢锁，只有一个人能获得锁2，获得锁的人出问题，临时节点（session）。3，获得锁的人成功了。释放锁。4，锁被释放、删除，别人怎么知道的？4-1：主动轮询，心跳。。。弊端：延迟，压力4-2：watch： 解决延迟问题。。 弊端：压力4-3：sequence+watch：watch谁？watch前一个，最小的获得锁~！一旦，最小的释放了锁，成本：zk只给第二个发事件回调！！！！
client
广播过来的内容可以慢慢的去消费队列的内容，达到最终一致性
ephemeral节点短暂的
leader是单机顺序执行的，类似redis，所以维护cZxid的事务id自增即可。
4-2 create操作write内存
watch
node02
框架架构
follower
A
分布式锁临时节点
Follower
资源
session8
心跳，自己实现watch基于zk方向性、时效性
ZAB（原子广播协议）作用在可用状态有Leader时
二阶段提交
Client
leader
1，场景，第一次启动集群2，重启集群，leader挂了后
https://github.com/msbbigdata
原子性 - 更新成功或失败。没有部分结果。
不要把zookeeper当数据库用
如果有30台机器，有7台用来选主即可，其他的用来做Observer即可，放大查询的能力。
session
分布式锁
序列节点
paxos的理解https://www.douban.com/note/208430424/
顺序一致性 - 客户端的更新将按发送顺序应用。
write
锁依托一个父节点且具备-s代表父节点下可以有多把锁
统一视图目录树结构
zookeeper有2中运行状态1，可用状态2，不可用状态3，不可用状态恢复到可用状态应该越快越好
可靠性
安装 验证 简单使用
重入
2.create(ooxx)
node04
node03
攘其外必先安其内
Followersync可选项！
session+Enode
M 2Z 8
zookeeper 分布式协调。。。 配置 分布式锁！！！！
原子：成功、失败。没有中间状态（队列+2PC）广播：分布式多节点的。全部知道！(只要接收log成功的过半，就都发送)队列：FIFO，顺序性zk的数据状态在内存用磁盘保存日志
扩展性
临时节点
zookeeper分布式协调扩展，可靠性，时序性快速！！！！
M 1Z 8
1.create（ooxx）
M 4Z 8
node02+3
如果不用zk，那就要用心跳验证
想象：1，leader是单机的肯定会挂2，服务不可用3，不可靠的集群现实：4，事实上，zk集群是及其高可用的5，如果有一种方式可以快速的恢复出一个leader
角色
修改
get
及时性 - 系统的客户视图保证在特定时间范围内是最新的。最终一致性。
zookeeper配置数据data
队列式事务的锁
1，统一配置管理<- 1M数据2，分组管理 <- path结构3，统一命名 <- sequential4，同步 <- 临时节点
4台机器过半3台
5.over-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
Observer级别比follower更低，不参与选举，一旦leader选出，同步leader数据，用于读取
只有Follower才能选举
没创建一个session都会消耗一个事务id，为了进行同步操作。
M 3Z 7
快速恢复Leader
200ms恢复
zookeeper是一个目录树结构
6.ok
HA，选主
http://zookeeper.apache.org/
攘其外一致性？最终一致性*过程中，节点是否对外提供服务！！！
数据 可靠 可用一致性
3888: 无主时，选主投票用的端口2888: 选出leader后，启动2888，其他节点通过leader的2888端口进行交互，leader接受write请求
redis单实例的内存-快复制集群HA sentinel不是绝对的实时同步可能连最终一致性都谈不上集群模式 分片
3，callback
0 条评论
下一页
