Zookeeper究竟能为集群做点什么？

今天回头看了看zookeeper，系统的看了一下zk，瞬间明了~~
通俗易懂的大白话说一下~
我把zookeeper简称zk：服务协调。几大场景：感知，锁，配置（文件）管理，故障（节点）修复功能~
1.感知：集群“heartbeat”和“heartbeat recheck”机制，耗时比较久。CS端想要读取一份数据，zk可以检查存有这份数据的datanode是否正常，如果正常则返回连接，要是不正常就copy这个节点上的所有数据到集群的其它节点，保证数据不丢失（HDFS只是“尽力去保证不丢失”，一般来说各个节点的数据都是冗余存储的，应该只需要copy部分数据）。其它服务器马上会被zk调用代替这台有故障的节点，并且同时会在zk“列表”删除这台有故障的节点服务器。（zk集群一般有一台leader，众多follower，还有observer用于leader的压力过载协助，只要follower不超过半数挂掉，zk集群就可正常服务！）。


2.锁：当CS端正在读取这份数据，结果又来一个人要修改这份数据，会造成“脏读”或者“幻读”。基于此，zk给我们提供了一个“分布式锁”机制。当这份数据被调用的时候，那么这份数据是不会被更改的，就是说你只能读，但是不能增删改。反过来，如果你在增删改这份数据的同时，这份数据是“不可读”的状态。力求这份数据的准确。


3.配置管理：你有5台服务器的HA集群。逐个修改服务器的配置文件并不难，如果是100台呢？就需要用到zk了。服务器如果依赖这个配置，可以把这个配置放在专门用于存储的服务器上，对需要此配置的服务器就来读取。那如何保证这台存储服务器正常运行？改用zk集群~把配置文件放在zk集群上,当成存储集群。用来保证配置文件正确并不丢失~


4.故障修复：不是自我修复，而是利用监听机制精准的告诉运维人员具体是哪一台服务器下线及原因（如果这台服务器的故障是可以修复的话，zk会自己把这台服务器修复）。与此同时，zk集群中的leader会告诉分布式集群中的所有服务器，这台服务器下线了，从而再合理分配其它节点的计算任务。如果这个分布式集群中namanode下线怎么办？如果是HA集群的话，备用的服务器会从standby自动切换成active状态，用于代替有故障的主节点服务器（即使主节点服务器在运算过程中出现故障，备用服务器也会重新完成没有完成的计算任务），可谓是相当聪明~


注：在zk集群中如何选举leader? 其实zk集群中每一台不用的服务器都有会有一个myid和ZXid（myid: 1-255 数字可随意配，但不可重复）。初始化的是先按照ZXid来选，如果都为0（因为初始化都为0），那么按照myid来选，数字大的当选，一旦有半数服务器通过，这台服务器即为leader（所以一般来说zk集群都为奇数）。但集群运行期间的选举是按照zk内置的算法Paxos来选举（Paxos算法是zk的“灵魂”，详解可以查找CSDN）。万一zk集群中的主节点下线，那么整个zk集群会按照Paxos来进行新一轮的选举，选出一台新的服务器作为leader来继续提供服务，与此类推，除非zk集群中半数服务器挂掉（概率很小）。