Zookeeper： zookeeper是一个分布式的小文件管理存储系统； zookeeper可以提供客户端监控存储在zk内部数据的功能
zookeeper架构：
zookeeper特点：
zookeeper数据结构与监听机制znode的类型
在zookeeper中，事务表示能给改变zookeeper服务器状态的操作（create,update data,更新子节点），也称事务操作或更新操作。
zookeeper监听器：客户端可以对一个不存在的节点进行子节点变更的监听。一旦客户端对一个节点注册了子节点列表变更监听之后，那么当该节点的子节点列表发生变更时，服务端都会通知客户端，并将最新的子节点列表发送给客户端。该节点本身的创建或删除也会通知到客户端。
Leader选举：首次启动：半数机制：集群中半数以上机器器存活，集群可用。所以Zookeeper适合安装奇数台服务器。Zookeeper虽然在配置⽂文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其它为Follower，Leader是通过内部的选举机制产生的。非首次启动：每个节点在选举时都会参考自身节点的zxid值（事务ID）；优先选择zxid值大的节点称为Leader!!
ZAB协议ZAB 协议是为分布式协调服务 Zookeeper 专门设计的⼀一种支持崩溃恢复和原子广播协议。
广播消息：ZAB 协议的消息⼴广播过程类似于二阶段提交过程。对于客户端发送的写请求，全部由 Leader 接收，Leader 将请求封装成一个事务 Proposal(提议)，将其发送给所有 Follwer ，如果收到超过半数反馈ACK，则执行 Commit 操作（先提交自己，再发送 Commit 给所有 Follwer）。不能正常反馈Follower恢复正常后会进入数据同步阶段最终与Leader保持一致！！Leader接收到Client请求之后，会将这个请求封装成一个事务，并给这个事务分配一个全局递增的唯一 ID，称为事务ID（ZXID），ZAB 协议要求保证事务的顺序，因此必须将每一个事务按照 ZXID进行先后排序然后处理。ZK集群为了保证任何事务操作能够有序的顺序执行，只能是 Leader 服务器接受写请求，即使是Follower 服务器接受到客户端的请求，也会转发到 Leader 服务器进行处理。
Leader宕机后，被选举的新Leader需要解决的问题： ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。 ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。实现以上目的需要：保证选举出的新Leader拥有集群中所有节点最大编号(ZXID)的事务!!
Zookeeper的两大特性： 1.客户端如果对Zookeeper的数据节点注册Watcher监听，那么当该数据节点的内容或是其子节点列表发生变更时，Zookeeper服务器就会向订阅的客户端发送变更通知。 2.对在Zookeeper上创建的临时节点，一旦客户端与服务器之间的会话失效，那么临时节点也会被自动删除。利用其两大特性，可以实现集群机器存活监控系统，若监控系统在/clusterServers节点上注册一个Watcher监听，那么但凡进行动态添加机器的操作，就会在/clusterServers节点下创建一个临时节点：/clusterServers/[Hostname]，这样，监控系统就能够实时监测机器的变动情况。
zk实现分布式锁：
Hadoop HA1. 元数据管理理⽅方式需要改变内存中各自保存一份元数据；Edits日志只有Active状态的NameNode节点可以做写操作；两个NameNode都可以读取Edits；共享的Edits放在一个共享存储中管理（qjournal和NFS两个主流实现）；2. 需要⼀一个状态管理理功能模块实现了一个zkfailover，常驻在每一个namenode所在的节点，每一个zkfailover负责监控自己所在NameNode节点，利用zk进行状态标识，当需要进行状态切换时，由zkfailover来负责切换，切换时需要防止brain split现象的发生（集群中出现两个Active的Namenode）。3. 必须保证两个NameNode之间能够ssh⽆无密码登录4. 隔离（Fence），即同一时刻仅仅有一个NameNode对外提供服务
Hadoop HA工作机制
测试题：1.以下属于zookeeper应用场景数据发布订阅设计模式的是（C,D） A.添加（add）模式 B.提交（commit）模式 C.推（push）模式 D.拉（pull）模式2.leader进程和所有的follower进程之间都通过心跳检测机制来感知彼此的情况
