Zookeeper概述：
分布式应用 协调服务
分布式锁服务 配置维护 组服务 分布式消息队列 分布式通知
封装好容易出错的关键服务
最终一致性：无论连接到哪个server，展示给的都是一个serer
实时性 不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据前调用sync接口
等待无关：慢的失效的客户端不得干预快的客户端
更新操作要么成功要么失败
全局有序：如果在一台服务器上消息a在b前发布，则所有server都是
Zookeeper系统架构：
多个server
有一个leader 多个follower leader由选举算法决定
客户端可以连接任意一个服务节点来都写数据
每个server都保存一份数据副本
使用简单的同步策略，通过以下来基本保证实现数据一致性：1，全局串行化所有写操作
2.保证同一客户端的指令被FIFO执行以及消息通知的FIFO，
所有的读请求由ZKserver本地回应
所有的更新请求将转发给Leader，由leader实施
通过复制来实现高可用性 只要集群中半数以上的机器处于可用状态，他就可以提供服务
ZK会确保对Znode树的每一个修改都会被复制到超过半数的机器上。如果少于半数的机器出现故障，则最少有一台机器会保存最新的状态，那么这台机器就是我们的Leader，其余的副本最终也会更新到这个状态。如果leader挂了，由于其他机器保存了Leader的副本，就可以从中选出一台机器作为新的Leader继续提供服务
领导者：负责投票的发起和决议，更新系统状态
学习者：跟随者：接受客户请求并向客户端返回结果，在选主过程中参与投票
观察者：ObServer可以接受客户端连接，将写请求转发给leader节点，但是他不参加投票过程，只是同步leader的状态，目的是为了扩展系统，提高读取速度
客户端：应用程序客户端，请求发起方
扩展的话可以多个观察者，因为如果一直增加Follower会导致投票很慢，不容易执行
数据读写流程
读：直接访问server 返回数据
写：访问server1，然后转发给leader，leader进行广播，server进行写操作，超过半数即写成功，然后反馈给leader，leader在指定一个server将结果传给客户端
工作原理：原子广播机制，这个机制保证了各个server之间的同步，实现这个机制的协议叫做Zab协议，Zab协议有两种模式，分别是恢复模式和广播模式
1.恢复模式：当服务启动或者领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来且大多数sever完成了和leader的状态同步后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态
广播模式：
一旦Leader已经和多数的Follower进行了状态同步后，他就可以可以开始广播消息了，即进入了广播状态。这时候当一个server加入ZK服务中，他会在恢复模式下启动，发现leader，并和leader进行状态同步。待到同步结束后，它也参与消息广播。ZK服一直维持在Broadcast（广播）状态，直到Leader崩溃了或者Leader失去了大多数Follower的支持
广播状态类似于分布式事务中的2pc：即Leader提起一个决议，有Followers进行投票，Leader对投票结果进行计算决定是否通过该决议，如果通过执行该决议，否则什么也不做
在广播模式下，ZK接受客户端请求，所哟i的写请求都会转发给领导者，再有领导者将更新广播给追随者，但半数以上的追随者已经将修改持久化后，领导者才会提交这个更新，然后客户端然后客户端才收到一个更新成功的相应。
Zookeeper 如何提供服务：
各种服务是具体如何实现的
数据结构Znode
原语：在数据结构上的一些操作
通知机制：watcher监视器
需要通过通知机制将消息以网络的形式发送给分布式应用程序
Zk的相关服务主要通过数据结构+原语+watcher机制这3部分共同来实现
Zk维护者一个树形层次结构，节点为Znode
Znode兼具文件和目录双重特点，每个Znode由三部分组成：stat：状态信息，描述该Znode的版本，权限等信息 data：与该Znode相关的数据 Children：该Znode下的子节点
Znode有两种类型：
短暂的和持久的。Znode的类型在创建时确定并且之后不能再修改
短暂节点：临时借点：在创建短暂Znode的客户端会话结束时，Zk会将该短暂的Znode删除，虽然每个短暂的Znode都会被绑定到一个客户端会话，但是他们对所有的客户端还是可见的。。短暂Znode不可以有子节点，即使是短暂子节点
持久节点：持久Znode不依赖与客户端对话，只有当客户端明确要删除该持久Znode时才会被删除
watcher：
Zk在读操作上设置观察，这些观察可以被写操作触发。当一个观察被触发时会产生一个观察事件，这个观察和触发它的操作共同决定了这个观察事件的类型
ZK所管理的watch可以分为两类：
数据watch：getData和exits负责设置数据watch，返回关于节点的数据信息
孩子watch：getChildren负责设置孩子watch，并返回孩子列表
ZK集群部署：
安装模式：
三种：
单机模式：只运行在一台服务器上，适合测试环境
伪集群模式：一台物理机上运行多个Zk实例适合测试模式
分布式集模式：Zk运行于一个集群中，适合生产环境
ZK集群时钟同步
用上海时间覆盖本地时间
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
覆盖后用网络时钟协议NTP
下载安装ntp yum install ntp
ntpdate pool.ntp.org
(在使用yum下载时提示找不到镜像那个错误，想要去/etc/resolv.conf修改DNS。但是发现改完之后再重启就会没有。 应该是去/etc/sysconfig/network-scripts/ifcfg-eth0增加DNS
这里改完之后DNS的那个文件里也就会有相同的nameserver
节点之间免密码：将节点2，3的密码验证文件里的内容复制到1的密码验证文件里 cat ~/.ssh/id_rsa.pub | ssh root1@hadoop01 'cat >>~/.ssh/authorized_keys'
然后将1的密码验证文件分发（复制）到其他两个节点