zk

node01

ZOOKEEPER:   分布式协调服务

ok

zookeeper

完成分布式协调分布式锁

Leader

读写分离observer放大查询能力

持久节点

队列

1，争抢锁，只有一个人能获得锁2，获得锁的人出问题，临时节点（session）。3，获得锁的人成功了。释放锁。4，锁被释放、删除，别人怎么知道的？4-1：主动轮询，心跳。。。弊端：延迟，压力4-2：watch：  解决延迟问题。。  弊端：压力4-2：sequence+watch：watch谁？watch前一个，最小的获得锁~！一旦，最小的释放了锁，成本：zk只给第二个发事件回调！！！！

client

4-2 write

watch

node02

框架架构

follower

A

分布式锁临时节点

Follower

资源

session8

心跳，自己实现watch基于zk方向性、时效性

ZAB作用在可用状态有Leader时

Client

leader

1，场景，第一次启动集群2，重启集群，leader挂了后

https://github.com/msbbigdata

原子性 - 更新成功或失败。没有部分结果。

不要把zookeeper当数据库用

session

分布式锁

序列节点

https://www.douban.com/note/208430424/

顺序一致性 - 客户端的更新将按发送顺序应用。

write

zk增加删除修改是顺序执行的cZxid = 0x300000004   创建的事务idctime = Wed Sep 02 05:34:46 CST 2020mZxid = 0x300000008  修改的事务idmtime = Wed Sep 02 05:57:07 CST 2020pZxid = 0x300000005  当前节点下创建最后的节点的事务idcversion = 1dataVersion = 2aclVersion = 0ephemeralOwner = 0x0  临时节点的归属者，sessioniddataLength = 2numChildren = 1 

锁依托一个父节点且具备-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

队列式事务的锁

1，统一配置管理<-  1M数据2，分组管理 <- path结构3，统一命名 <- sequential4，同步 <- 临时节点

4台机器过半3台

over-ok

node可以存数据1MB

可靠性 - 一旦应用了更新，它将从那时起持续到客户端覆盖更新。

Watch  手表  监控  观察

/ooxx/a会有事件：eventcreatedeletechangechildren

特征/保障

1，paxos     一种算法2，ZABZab借鉴了Paxos算法，但又不像Paxos那样，是一种通用的分布式一致性算法。它是特别为Zookeeper设计的支持崩溃恢复的原子广播协议。Zookeeper 客户端会随机的链接到 zookeeper 集群中的一个节点，如果是读请求，就直接从当前节点中读取数据；如果是写请求，那么节点就会向 Leader 提交事务，Leader 接收到事务提交，会广播该事务，只要超过半数节点写入成功，该事务就会被提交。3，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

只有Follower才能选举

M 3Z 7

快速恢复Leader

200ms恢复？

zookeeper是一个目录树结构

HA，选主

http://zookeeper.apache.org/

paxos和zab的区别ZAB主要是用来实现保持各集群中主备副本之间的数据一致性。当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进人恢复模式并选举产生新的Leader服务器。这个过程大致是这样的：   1. Leader election（选举阶段）：节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准 leader。   2. Discovery（发现阶段）：在这个阶段，followers 跟准 leader 进行通信，同步 followers 最近接收的事务提议。   3. Synchronization（同步阶段）：同步阶段主要是利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本。同步完成之后 准 leader 才会成为真正的 leader。   4. Broadcast（广播阶段）：到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。ZAB和PAXOS算法的相同和区别？相同点：两者都存在一个类似于Leader进程的角色，由其负责协调多个Follower进程的运行Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将一个提案进行提交不同点：ZAB协议中，每个Proposal中都包含一个 epoch 值来代表当前的Leader周期，Paxos中名字为Ballot。ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。在Paxos算法中，一个新选举产生的主进程会进行两个阶段的工作。第一阶段被称为读阶段，在这个阶段中，这个新的主进程会通过和所有其他进程进行通信的方式来收集上一个主进程的提案，并将他们提交。第二阶段被称为写阶段，在这个阶段，当前主进程开始提出他自己的提案

攘其外一致性？最终一致性*过程中，节点是否对外提供服务！！！

数据 可靠 可用一致性

3888:   选主投票用的2888:   leader接受write请求

redis单实例的内存-快复制集群HA  sentinel不是绝对的实时同步可能连最终一致性都谈不上集群模式 分片

3，callback