ZOOKEEPER

Zookeeper 是一个开源分布式，为分布式应用提供协调服务的项目

zookeeper作用以及优缺点
 

作用包括存储数据和监听机制

优点
有序消息
序列化
在读请求多的情况下，速度很快
扩展性强
可靠性，容错
原子性
实时性

缺点
增加新的服务器是可能导致数据丢失
不能迁移
节点数，集群中存活过半接对外可用，但是会有脑裂的情况发生
不支持技嘉感知
不支持减少pod数据
在虚拟网路上不支持弃用kerberos
 

应用场景
        1. 配置中心，发布者将新的配置发送到配置中心，所有服务节点即可自动下载配置更新
                分布式系统的所有服务节点可以对某个Znode注册监听，之后只需要将新的新的配置写入改Znode,所有服务节点都会受到该事件
         2.master 选举
         3.分布式锁   （携程美团 向12306订票用到分布式锁）
可以通过Zookeeper的临时节点和Watcher机制来实现分布式锁
这里以排它锁为例进行说明：分布式系 统的所有服务节点可以竞争性地去创建同一个临时ZNode，由于Zookeeper不能有路径相同的ZNode，必 然只有一个服务节点能够创建成功，此时可以认为该节点获得了锁。其他没有获得锁的服务节点通过在 该ZNode上注册监听，从而当锁释放时再去竞争获得锁。锁的释放情况有以下两种： 当正常执行完业务 逻辑后，客户端主动将临时ZNode删除，此时锁被释放； 当获得锁的客户端发生宕机时，临时ZNode会 被自动删除，此时认为锁已经释放。 当锁被释放后，其他服务节点则再次去竞争性地进行创建，但每次 都只有一个服务节点能够获取到锁，这就是排他锁。
         4.集群管理
Zookeeper还能解决大多数分布式系统中的问题：
如可以通过创建临时节点来建立心跳检测机制。
如果  分布式系统的某个服务节点宕机了，则其持有的会话会超时，此时该临时节点会被删除，相应的监听事 件就会被触发。
分布式系统的每个服务节点还可以将自己的节点状态写入临时节点，从而完成状态报告 或节点工作进度汇报。
通过数据的订阅和发布功能，Zookeeper还能对分布式系统进行模块的解耦和任 务的调度。
通过监听机制，还能对分布式系统的服务节点进行动态上下线，从而实现服务的动态扩容。
         5. 事务操作
在ZooKeeper中，能改变ZooKeeper服务器状态的操作称为事务操作。
一般包括数据节点创建与删除、数 据内容更新和客户端会话创建与失效等操作。
对应每一个事务请求，ZooKeeper都会为其分配一个全局 唯一的事务ID，用 ZXID 表示，通常是一个64位的数字。每一个 ZXID对应一次更新操作， 从这些 ZXID 中 可以间接地识别出 ZooKeeper 处理这些事务操作请求的全局顺序。

Zookeeper的选举策略，leader和follower的区别？

3.4.0版本开始，ZooKeeper废弃了0、1、2这三种Leader选举算法
选举机制是半数机制，只要集群中已上机器存活，机器就可用
Leader服务器挂了，那么整个集群将暂停对外服务

5台机器
（新集群选举 集群里每个节点都没有数据）
1 机器启动，发起选举，1投自己一票
2 机器启动，发起选举，2投自己一票 ，1发现2的ID比1自己的ID 大，修改选票，推举2号，2号两票，没过半数，继续选举
3 机器启动，发起选举，此时12机器发现3的ID比自己大，推举三号位leader，3台机器满足过半，服务器3号位leader，12机器为following
45号机器少数服从多数，为FOLLOWING

（集群重启 集群里每个节点都有数据，或者leader宕机，ZXID大为准）

Leader挂后，余下的非Observer服务器都会讲自己的服务器状态变更为LOOKING，然后开 始进入Leader选举过程。
优先检查ZXID。ZXID比较大的服务器优先作为Leader。（这个很重要：是数据最新原则，保证数 据的完整性）
id：被推举的Leader的SID。 zxid：被推举的Leader事务ID。

如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。（集群的节点标识）

Leader 仅有1个
       1. 发起与提交写请求
leader 接收到一个写请求后，发送给所有Follower，统计Follower写入成功的数两，超半数，就认为写请求提交成功，通知Follower  提交这个写操作
       2. 监控Follower，与Follower保持心跳
       3. 崩溃恢复时负责恢复数据以及同步数据到Learner
Follower  多个
        1）与老大Leader保持心跳连接
        2）当Leader挂了的时候，经过投票后成为新的leader。leader的重新选举是由老二Follower们内部投票决 定的。
        3）向leader发送消息与请求
        4）处理leader发来的消息与请求

Zookeeper集群角色 服务器状态

服务器具有四种状态，分别是LOOKING、FOLLOWING、LEADING、OBSERVING。
LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入 Leader选举状态。
FOLLOWING：跟随者状态。表明当前服务器角色是Follower。
LEADING：领导者状态。表明当前服务器角色是Leader。
OBSERVING：观察者状态。表明当前服务器角色是Observer。

Leader不直接接收client的请求，但接受由其他Follower和Observer转发过来的client请求。
此外，Leader 还负责投票的发起和决议，即时更新状态和数据。

Follower角色接手客户端请求并返回结果，参与Leader发起的投票和选举，但不具有写操作的权限。

Observer角色接受客户端连接，将写操作转给Leader，但Observer不参与投票（即不参加一致性协议的 达成），只同步Leader节点的状态，Observer角色是为集群系统扩展而生的。

Clinet 连接Zookeeper集群的使用者，请求的发起者，独立于Zookeeper集群的角色。
 

Zookeeper 内存数据库 结构 树形 每个节点称作一个ZNode。容量为1m ，不可做数据库，容量不高

ZNode有两种类型 
短暂（ephemeral）：客户端和服务器端断开连接后，创建的节点自己删除
持久（persistent）：客户端和服务器端断开连接后，创建的节点不删除

Zookeeper 分布式锁
共享锁与排他锁的区别在于，加了排他锁之后，数据对象只对当前事务可见，而加了共享锁之后，数据 对象对所有事务都可见。

Watch机制简介

ZooKeeper 提供了分布式数据发布/订阅功能，一个典型的发布/订阅模型系统定义了一种一对多的订阅 关系，能让多个订阅者同时监听某一个主题对象，当这个主题对象自身状态变化时，会通知所有订阅 者，使他们能够做出相应的处理。

ZooKeeper 中，引入了 Watch 机制来实现这种分布式的通知功能。
ZooKeeper 允许客户端向服务端注册一个 Watch 监听，当服务端的一些事件触发了这个 Watch ，那么就 会向指定客户端发送一个事件通知，来实现分布式的通知功能。

ZooKeeper 支持watch(观察)的概念。客户端可以在每个znode结点上设置一个观察。如果被观察服务端 的znode结点有变更，那么watch就会被触发，这个watch所属的客户端将接收到一个通知包被告知结点 已经发生变化，把相应的事件通知给设置过Watcher的Client端。 Zookeeper里的所有读取操作：getData(),getChildren()和exists()都有设置watch的选项

Zookeeper怎么保证一致性的

依赖了ZAB协议
ZAB协议是伪分布式协调服务Zookeeper专门设计的一种崩溃恢复的原子广播协议

它有两种基本的模式：
崩溃恢复（半数选举 后新的Leader服务器进行 数据同步，当集群中超过半数机器与该Leader服务器完成数据同步之后，退出恢复模式进入消息广播模 式） 
消息广播（Leader服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。）

Zookeeper的Paxos算法

 

1）Paxos算法包括两个阶段：第一个阶段主要是贿选，还没有提出提议；第二个阶段主要根据第一阶段 的 结果，明确接受谁的提议，并明确提议的内容是什么（这个提议可能是贿选胜出“提议者”自己的提 议， 也可能是前任意见领袖的提议，具体是哪个提议，见下面第3点原则）。

2 ）编号（贿赂金额）很重要，无论在哪个阶段，编号（贿赂金额）小的，都会被鄙视（被拒绝）。

3）在第一阶段中，一旦“接受者”已经接受了之前意见领袖的提议，那后面再来找这个“接受者”的“提议 者”，即便在贿赂中胜出，也要被洗脑，默默将自己的提议改为前任意见领袖的提议，然后他会在第二 阶段提出该提议（也就是之前意见领袖的提议，以力争让大家的意见趋同）。如果“接受者”之前没有接 受过任何提议，那贿选胜出的“提议者”就可以提出自己的提议了。

Zookeeper从三台扩容到七台怎么做？

先检查三台设备的状态，两台为follower，一台为leader；
修改节点数量，由三台增加到七台，修改相应的zoo.cfg文件；
完成相关配置后，启动对应zk实例，确认启动ok，节点四到七依次验证实例状态；
在leader节点上查看目前状态同步的follower数，确认新增节点已经成功加入集群；
确认新增节点加入集群后，滚动更新原有集群的配置，并重启，这里需要注意，在重启follwer节点 的时候并无任何影响，不过在重启leader节点的时候，这个时候会触发一次新的leader选举，zxid最新的 默认优先当选新的leader，当zxid相同，myid最大的优先当选新的leader。