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
