文章目录
- 1.zookeeper如何迁移
- 2.zookeeper使用场景
- 3.zookeeper为什么是奇数台
- 4.zookeeper提供什么实现各种服务
- 5.ZAB协议
- 6.zookeeper的数据节点znode类型
- 7.zookeeper的watch机制
- 8.zookeeper角色
- 9.zookeeper的server工作状态
- 10.zookeeper是如何保证事务的顺序一致性
- 11.分布式集群中为什么有master
1.zookeeper如何迁移
先新增一台zookeeper机器同步数据，然后关闭原先的机器
2.zookeeper使用场景
1.数据发布订阅，2.统一命令服务 3.分布式通知与协调 4.分布式锁 5.集群监控
6.分布式队列 7.master选举
3.zookeeper为什么是奇数台
集群容灾数量=集群总节点数/2 -1,假设5台，最多可以挂2台，如果挂三台，集群选举达不到满足条件，6台的话也是最多挂两台，挂三台超过半数
4.zookeeper提供什么实现各种服务
文件系统，通知机制
5.ZAB协议
zab协议是分布式协调服务zookeeper专门设计一种支持崩溃恢复的原子广播协议
zab协议包括两个基本模式,崩溃恢复和消息广播
当整个zookeeper集群刚刚启动或者leader服务器宕机，重启或者网络故障导致不存在过半服务器与leader保持正常通信时，所有进程（服务器）进入崩溃恢复模式，首先选举产生新的leader服务器，然后集群中Follower服务器开始于新的leader服务器进行数据同步，当集群中超过半数机器与该leader服务器完成数据同步之后，由恢复模式进入消息广播模式，leader服务器开始接受客户端事务提案进行事务请求
6.zookeeper的数据节点znode类型
persist持久节点（手动删除）
ephemeral临时节点（与客户端会话相关联）
persistent_sequential 持久顺序节点（手动删除，增加顺序属性,节点名后会追加一个由父节点维护的自增整数型数字）
ephemeral_sequential 临时顺序节点（客户端会话相联，节点名后会追加一个由父节点维护的自增整数型数字）
7.zookeeper的watch机制
zookeeper允许客户端向服务端的某个znode注册一个watcher监听，当服务端的一些指定事件触发了这个watcher，服务端向指定客户端发生一个事件实现分布式通知功能，然后客户端根据watcher通知状态和事件类型做出业务上改变
8.zookeeper角色
1.leader 事务请求的唯一调度和处理者，保证集群事务处理的顺序性，集群内部各服务的调度者
2.follower
处理客户端的非事务请求，转发事务请求给leader服务器，参与事务请求proposal的投票，参与leader选举投票
3.observer 在不影响集群事务处理能力基础上提升集群非事务处理能力，转发给leader
9.zookeeper的server工作状态
looking：寻找leader，当服务器处于该状态，集群中无leader
following：跟随者，表名当前角色是follower
leading：领导者状态，表名当前服务器角色是leader
observing：观察者状态，表明当前服务器角色Observer
10.zookeeper是如何保证事务的顺序一致性
zookeeper采用了全局递增的事务id来标识，所有的proposal（提议）都在被提出时候加上了zxid，实际上是一个64位数字，高 32 位是 epoch 用来标识 leader 周期，如果有新的 leader 产生出来，epoch 会自增，低 32 位用来递增计数。当新产生 proposal 的时候，会依据数据库的两阶段过程，首先会向其他的 server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行
11.分布式集群中为什么有master
在分布式环境中，有些业务逻辑只需要集群中一台机器进行执行，其他的机器可以共享
这个结果，这样可以大大减少重复计算，提高性能，于是就需要进行 leader 选举
