ZooKeeper的来源：
分布式的产生，--分布式数据一致性的问题，分布式的节点越多越难达到一致性。
zookeeper产生的目的就是解决分布式数据一致性。
1）hadoop安装的时候，namenode存在单点故障额问题 高可用
namenode可以配置多个，只有一个active的，剩下的都是standby的
standby可以无缝衔接active 保证集群正常运行，数据不丢失
如果standby想要无缝衔接，必须实时和active元数据保持一致（元数据一致）
保持一致如何保持 拷贝--standby定期到active拷贝 不现实 存在数据延迟的问题
最好出现一个第三方的平台 这个平台就是解决数据同步问题 ZooKeeper
CAP:
c:Consistency 一致性：多个副本保持一致 强一致性
A：Availability,可用性：系统提供服务必须一直处于可用，对于用户的每一个操作请求总能在有限时间内返回结果。 高可用 可以持续对外提供服务。
P：Partition Tolerance分区容错性：分布式系统在遇到任何网络分区故障时。任然需要能够保证对外提供满足一致性和可用性的服务。
hdfs的副本，可以对外提供一致性数据。
BASE理论：
Basically Available:基本可用
相应时间的损失
功能上的损失
Soft State:软状态
允许存在不同节点同步数据时出现延迟，且出现数据同步延迟时存在的中间状态也不会影响系统的整体性能。
Eventually Consistent：最终一致性
系统中所有数据副本，在经过一段时间后，都可以达到一致
这个理论可以实现
paxos算法：希腊帮主的选举
投票---过半投票
不是所有人都参与投票，也不是所有人都同时投票的 比如一共5个，来了4个，有三个 人投了一个人，没来的人也不需要投了
角色：
提议者：负责发起新的提议
接受者：负责接收提议 并进行投票
学习者：提议通过以后 学习提议的内容
一个完美实现 --- zookeeper 最完美实现
任何其他的分布式一致性服务都是这个算法的不完美实现
zookeeper是一个分布式的，开放源代码的分布式应用程序协调服务，是Google的Chubby一个开源实现，它提供了简单原始的功能，分布式应用可以基于它实现更高级的服务，比如分布式同步，配置管理，集群管理，命名管理，队列管理。
Zookeeper的文件系统
zookeeper的架构
两大核心：
1.文件系统
1）zookeeper的文件系统类似于linux
2）zookeeper的文件系统的寻址只能通过绝对路径
3）zookeeper中不存在文件也不存在目录，但是既有文件的功能，又有目录功能，叫做znode
4)znode的分类
按照生命周期分：
持久的znode
创建持久znode:
create path data (存储的数据)
创建的时候必须指定存储的数据
临时的znode：
加参数 -e EPHEMERAL
create -e path data(也必须给定存储的数据)
临时节点是当前会话（客户端）结束，自动删除
持久节点只有用户手动删除 才会被删除
按有无编号分：
持久无编号节点
create path "" 创建的就是持久的无编号的
持久有编号节点
加参数：-s SEQUENTIAL 编号（你给的path + 编号）
临时无编号节点
create -e /test02 ""
临时有编号节点
create -e -s /test03 "" 临时有编号
注意：这里的编号是由父节点维护的，同一个父节点维护的编号会顺序增加，只要在相同的父节点下创建子节点，不管这个节点有无编号，都会顺序增加编号，编号是从0开始的，不同的父目录编号是重新开始的。
有编号和无编号的区别：
有编号可以反复创建同名节点 每次都会自动添加一个顺序的编号，无编号节点只能创建一次。 主备切换
5）临时节点不能有子节点
有子节点的节点一定是持久节点
没有子节点的节点不一定是永久节点，也不一定是临时节点
6）有几个zookeeper节点数据就保存几份，但是这几份数据是完全一样的。
7）linux每个存储有上限吗？有 硬盘容量
znode数据存储有上限吗？有 善于存储小数据 每个znode存储的数据不要超过1M，最好不要超过1KB。
①znode存储的数据量越大，一致性越难维护
②znode理论上只存储核心数据就可以了
最多情况下存的是状态信息 0 1 或者znode的存储并不依赖存储数据 依赖于znode节点本身特性 临时节点和永久节点
8）znode可以添加监听 监听添加的地方-------znode上
监听：监测znode状态 监测znode的一举一动
znode参数：
cZxid: 创建 记录全局的创建事件提交顺序的 集群维护
mZxid: 修改 记录的是修改事件的顺序
pZxid: 子节点事件编号
这三个编号全局唯一且顺序的（36）
高18位代表整个集群leader的节点信息，这个不变证明集群没有易主。（在新的leader下创建节点，高18位就会变）
低18位标识事件的提交编号 全局事件的提交顺序。
2.监听机制
监听就是对数据进行监控 zookeeper的监听对象是znode，就会对znode的数据变化添加监听。
通过监听机制，监听文件系统的数据变化 数据变化：数据内容的变化 文件结构的变化等
用户对哪个节点的数据变化感兴趣 那么就在这个节点上添加监听（注册监听） 一旦数据发生改变，就会触发监听。
监听事件：
nodedatachanged 节点数据（内容）改变
nodecreate 节点创建事件
nodedelete 节点删除事件
nodechildrenchanged 子节点变化事件
注册监听：
ls[watch] 显示子节点 子节点发生变化
get/getData[watch] 监听节点数据内容
exist[watch]
触发监听：
create
delete/rmr
set path data
注意：监听添加一次 只生效一次
分布式一致性事情
zookeeper的应用场景
1）命名服务 namespace
当分布式文件系统中需要统一命名的时候，如果节点自己进行命名，有可能产生两个节点同时命名，必然会产生命名冲突。
分布式文件系统中的命名 全局唯一的 统一的
就可以把名字作为zookeeper的一个节点
最好这个事情交给zookeeper 怎么实现命名的(无编号的持久节点)
在zookeeper的根目录添加监听
zookeeper的两大核心：文件系统和文件监听
2) 配置文件管理
Hadoop的时候，修改了一堆的配置文件 ---远程拷贝的
如果集群搭建好了，正在运行，这时候你修改了一个配置文件 dfs.replication = 5
集群中有几个节点就得修改几个节点 最后一个节点修改完成才能最终生效 时间延迟
最理想的状态是一个节点修改完成，其他节点立即也可以修改
怎么做？ 文件系统和监听
配置文件管理：配置文件当做znode的节点 配置文件的内容作为znode的数据
改进版的zookeeper
3）集群管理
1)动态感知集群的上下线：datanode的死亡和添加 datanode判断死亡：630s
zookeeper去做 可以做到立即感知 文件系统加监听
可以将每一个datanode作为zookeeper的一个znode 这些znode在同一个znode下
namenode就可以去监听这个节点
znode：临时节点 无编号 当datanode宕机的时候节点删除
2）选主 选举master 帮助集群选主 在zookeeper中自带的选主机制，利用自带的选主机制进行选主
namenode01 active namenode02 standby
可以将namenode01 namenode02作为一个znode
临时 无编号
4）锁
1）读锁 共享锁 锁作为一个有编号的临时节点
2）写锁 排它锁 无编号的临时节点
3）时序锁 有时序锁 先后顺序锁 先后顺序的锁 编号 请求的先后顺序创建的编号
5）分布式队列
1）同步队列 10 那么表示10个全部到齐才开始执行 运用编号+监听
2）FIFO 类似于时序锁
一致性：
强一致性：实时保持一致性 写入的同时就可以读取
弱一致性：具有延迟 绝大多数保持一致就可以
最终一致性： 接受一定时间的延迟，在一定的时间内达到全部一致性。是弱一致性的特例。
HDFS进行文件上传的时候要求的就是最终一致性。
Zookeeper作为一个集群提供数据一致的协调服务，自然，最好的方式就是在整个集群中的各服务节点进行数据的复制与同步。
zookeeper的配置文件管理
1) 配置文件的内容发生变化 nodedatachanged
2) 配置文件增加 nodecreated
3) 配置文件删除 nodedeleted
数据复制的好处：
1.容错：一个节点出错，不至于让整个集群无法提供服务。
2.扩展性：通过增加服务器节点能提高Zookeeper系统的负载能力，把负载分布到多个节点上。
3.高性能：客户端可访问本地ZooKeeper节点或者访问就近的节点，依次提高用户的访问速度。
zookeeper的相关理论
1.zookeeper的设计特点
协调分布式系统的数据一致性
从客户端读写访问的透明度来看，数据复制集群分为下面两种：
1、写主：对数据修改的请求提交给主节点，对读数据请求没有限制，任何节点都能响应
1）写只能由主节点执行
从节点接受到写请求，把请求转发给主节点 并不进行处理
2）所有节点同步写， 写冲突
特点：（base理论）
1.最终一致性：client不论连接到哪个server,展示给它的都是同一个视图，这是zookeeper重要的特性。
写的过程采取的写主的方式，所有的写操作只能leader进行 follower不能处理写操作，接收到了转发给leader。
在写的过程中也不是强一致性，只要保证有半数以上的节点写成功即可。剩下的没有写成功的暂时不对外服务，写成功了对外提供服务。
2.可靠性：具有简单、健壮、良好的性能，如果消息m被一台服务器接受，那么它将被所有的服务器接收。
3.实时性：zookeeper保证客户端将在一个时间间隔内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，ZooKeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
伪实时 允许一定时间的延迟
有可能一个节点同时处理多个请求，按请求的编号进行处理 后面的请求处于阻塞状态 请求被处理的时候解除。
4.等待无关：假设一个请求由于网络延迟，后面的请求可以继续提交请求，前面的请求无权干预11号请求的提交，但是11号请求提交了之后处于阻塞状态，必须等待10号处理完成。
请求处理的时候严格按照请求的编号处理的。
5.原子性：更新只能成功或者失败，没有中间状态、
6.顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前发布：偏序是指如果一个消息b在消息a后被同一个发布者发布，a必将排在b前面（指客户端）。
zookeeper角色：
1.client:负责发送读写请求 java api zkCli
2.leader:集群的主节点 负责提议或者投票的发起
3.learner:
follower:跟随者 进行接收客户端的读请求 如果接收到写请求转发 对leader发起的提议进行投票 选举权 在leader挂掉的时候 被选举权
observer:观望着 在没有投票的情况下和follower一样，observer不具有 投票权利 被剥夺了政治权利。可以接收客户端的请求 出现的意义：分担整个集群的读的压力。
zookeeper的选主：
1）全新集群的选主： 没有任何其他数据 zookeeper 节点 通过serverid------myid
2) 非全新集群的选主：集群中有数据
paxos 3.4-----------fast paxos
有几个节点就有几份数据
1）逻辑时钟
就是选主的时候投票的轮数 从0开始记录
逻辑时钟最大的代表最近一次投票，如果发现逻辑时钟小的自动忽略
2）version --- 数据版本 数据的版本越高，证明数据越新。
3）serverId
优先级：先根据逻辑时钟，优选选逻辑时钟最大的。
如果逻辑时钟相同的时候根据数据版本。
最后选择serverid serverid高的优先级大 leader
这个选主特点：保证数据不丢失，最终选到的主，是数据最新的。
过半选举同一个节点---leader
zookeeper最好奇数台
数据同步的问题：
过半节点更新，在一定时间内，其他节点也要更新出来。更新不成功就回滚
leader---集群中数据版本高的
follower--可能数据版本比较低 极个别
一旦选主成功，所有follower都向leader注册，目的就是获取数据版本。
1）leader等待follower的心跳 等待follower数据更新请求
2）follower数据更新请求leader,leader会记录当前follower的zxid(请求的顺序编号)，获取follower的需要同步的数据编号范围。
3）follower开始进行数据同步，在数据同步的过程中不对外提供服务。同步数据完成 会将自己的状态改为update
注：我们需要配置选举端口
4. ZAB协议？
ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议。
ZAB协议包括两种基本的模式：崩溃恢复和消息广播。
当整个zookeeper集群刚刚启动或者Leader服务器宕机、重启或者网络故障导致不存在过半的服务器与Leader服务器保持正常通信时，所有进程（服务器）进入崩溃恢复模式，首先选举产生新的Leader服务器，然后集群中Follower服务器开始与新的Leader服务器进行数据同步，当集群中超过半数机器与该Leader服务器完成数据同步之后，退出恢复模式进入消息广播模式，Leader服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。
