zookeeper入门

zookeeper主要是做分布式系统的协调服务的

高可用性：

zookeeper通过复制实现高可用，只要集群半数以上仍然正常工作zookeeper便可提供服务这也是为什么集群一般都是奇数节点的原因。

举例：当集群节点数为5 坏掉两个 剩下三个 仍然有半数以上的节点正常

           如果节点数为6 坏点三个 剩下三个便不满足大于半数节点的要求 最多只能坏掉两个 这就是为什么节点数一般都是奇数个的              根源

每个子目录项如 NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。 

zookeeper的特点：

数据一致性：zookeeper的数据每台机器都会保存一份副本，当客户端调用时会先查看该值的版本号客户端将会使用最新的且存在数量大于半数节点的数据版本号所对应的版本为不知是简单的本地调用（流言  大多数人说什么就是什么）

更新原子性：zookeeper数据更新只有成功和失败两种结果不存在部分成功部分失败的结果，当半数以上的节点更新成功时便视为操作成功

更新请求顺序：由于客户端不断地更改数据，zookeeper的节点状态更新是顺序进行的，也就是按照你的操作顺序进行的更新

实时性：在一定时间范围内数据更新可以视为实时性，一致性的同步时间延迟不是心跳反馈时间2s而是在毫秒之内，心跳机制是为了让各个节点感知是否是存活状态以便进行数据备份

广播顺序：所有的写请求都会转给leader （领导者）再由领导者发布给其他folloer（跟随者）

zookeeper领导者的选举：如果原来的领导者宕机新的领导者选举只需要200左右毫秒，若原有的领导者恢复正常状态则会成为一盒跟随者，选举时间非常快 在选举的过程中系统性能不会明显的下降

跟随者负责相应读请求，领导者负责相应的写请求

锁：分布式锁能够在一组进程中提供互斥机制，使得在任意时刻只有一个进程可以拥有锁，在任何时刻拥有锁的就是leader

 

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
 

zookeeper有两种类型的队列:

同步队列：当这个队列的队员齐了之后这个队列才可以使用

先进先出：按照先进先出进行入队出队操作

zookeeper是否使用了paxos？

答案是否  具体说是类似于但不完全相同

zookeeper的zab协议类似于paxos 但是在zab操作上是不同的 例如他是靠tcp协议保证消息的顺序

zookeeper选主

首先制定一个znode作为leader

其他想要参加选举的客户端创建暂存的znode  /leader/lock_1   /leader/lock_2  那么下一次选主时 /leader/lock_1 会被选为leader 因为他的序号最小 zookeeper是选主的仲裁者 因为他负责分配序号

观察节点：

zookeeper中存在观察节点（observer node）没有投票权的folloer  不会增加投票延时

zookeeper最重要的是实时性  所以应该单独放在专有的机器上 防止发生抢占产生延迟

zookeeper的myid一般为设置的服务器id  这个文件保存在datadir中

在zookeeper配置文件中必需配置下面这段代码

server.n = hostname:port:port

上面的代码是将集合体中的其他服务器的ID和网络位置告诉所有服务器

这里的两个端口设置第一个用来连接leader第二个用来领导者选举