Hadoop生态系统中哪些框架使用到了ZooKeeper HDFS HA HBase Kafka Spark …… HDFS HA是有单点故障的，在生产上面就有一个HA的机制有一个主的和备用的namenode，主的namenode发生故障时，把备用的namenode切换成主的并对外提供服务（透明的，用户不感知的） 自动进行切换就需要zookeeper
HBase中作为Master的选举机制
Kafka需要和zookeeper进行通讯，然后进行一些消息的生产和消费的
掌握ZooKeeper的架构ZK的架构 1）一个ZK集群中由一组Server节点构成 2）这一组Server节点中存在一个角色为Leader的节点，剩下的其他的节点都是Follower 3）当客户端Client连接到ZK集群时，并且执行读写请求，这些请求会被发送到Leader节点上 4）然后Leader上数据变更会同步到集群的其他的Follower节点 5）Leader节点接收到数据变更请求之后，首先将变更写入到本地磁盘（为了以后容错、恢复之用）， 当所有的写请求持久化到磁盘之后，才会将变更应用到内存中 6）当当前的Leader发生故障无法提供服务之后，故障/失败容错是快速响应的，会从Follower中选择 一个做为Leader(选择)，新的Leader继续做为分布式协调服务的中心，处理所有Client发起的请求。
zookeeper架构图
核心主键（Server，Leader，Follower，Client）Server：数目一般选择为奇数（3，5，7）Leader选举算法是采用了Paxos协议：当多数server写成功，则任务数据写成功多数server：只要集群中有过半的机器是正常工作的，那么整个集群对外就是可用的！！2 ZK: 死了1个，还能对外提供服务吗？因为1没有过半，所以2 ZK的死亡容忍度就是03 ZK: 死了1个，剩下2个，已经过半了，所以3 ZK的死亡容忍度就是14 ZK: 死了1个，剩下3个，已经过半了，所以4 ZK的死亡容忍度就是1死了2个，剩下2个，没过半了，所以4 ZK的死亡容忍度就是1....2 => 03 => 14 => 15 => 26 => 2
2n和2n-1的死亡容忍度是一样的，都是n-1
问题：何必增加那么一个不必要的ZK呢？？？？？？结论：ZK中的Server个数就是采用奇数个比较合适：3、5、7
了解ZooKeeper的数据结构及应用场景层次化的目录结构
每个节点在ZK中叫做znodeznode可以包含数据和子节点(EPHEMERAL类型的节点不能有子节点)znode中的数据可以有多个版本，可以通过版本查询数据ZK的数据模型1）层次化的目录结构，命名是有规范2）每个节点叫做znode，znode是有唯一的标识的3）znode的数据是带有版本，比如说某个znode可以存放多个数据版本，在使用时可以直接根据版本号获取数据4）节点数据必须是一次性完成完整的读写
Zonde由路径标注，ZooKeeper中被表示成有反斜杠分割的Unicode字符串，如同Unix中的文件路径。路径必须是绝对的，因此他们必须由反斜杠来字符开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。ZooKeeper的数据结构, 与普通的文件系统极为类似. 见下图：
图中的每个节点称为一个znode. 每个znode由3部分组成:
1.stat：此为状态信息, 描述该znode的版本, 权限等信息.
2.data：与该znode关联的数据.
3.children：该znode下的子节点.
Znode的两种类型：1）短暂的(ephemeral)客户端会话结束，那么zk就会将该类型的node删除，该类型的node是不可以有子节点2）持久的(persistent)不依赖于客户端会话，只有当客户端明确的使用命令或者是API的方式要删除该节点时才会被删除
zokeeper应用场景配置管理在分布式集群中，各个节点的配置文件同步文件。对集群中的一台机器的配置信息修改之后，希望能够快速同步到其他各个节点上，这可以交由ZooKeeper来实现将配置文件信息写入到ZooKeeper的一个znode上，各个节点监听这个znode即可集群管理在分布式集群中，各个节点的实时状态统计将节点信息写入到ZooKeeper的一个znode上，监听这个znode可以获取它的实时状态变化Hbase中Master状态监控和选举
总结：zk核心：仲裁机制，目录式的数据结构zk架构：服务端（奇数个，3，5，7。。。）leader(1) follower(n)数据的读写：客户端zk数据结构：目录树：持久 瞬时