好程序员大数据技术分享Zookeeper集群管理与选举

　　大数据技术的学习，逐渐成为不少程序员的必修课，同时也出现了不少技术论坛供你们探讨，因此今天好程序员分享大数据技术Zookeeper集群管理与选举，你们能够一块儿学习!

　　1.集群机器监控

　　这一般用于那种对集群中机器状态，机器在线率有较高要求的场景，可以快速对集群中机器变化做出响应。这样的场景中，每每有一个监控系统，实时检测集群机器是否存活。过去的作法一般是：监控系统经过某种手段(好比ping)定时检测每一个机器，或者每一个机器本身定时向监控系统汇报“我还活着”。 这种作法可行，可是存在两个比较明显的问题：

　　集群中机器有变更的时候，牵连修改的东西比较多。

　　有必定的延时。

　　利用ZooKeeper有两个特性，就能够实时另外一种集群机器存活性监控系统：

　　客户端在节点x上注册一个Watcher，那么若是 x?的子节点变化了，会通知该客户端。

　　建立EPHEMERAL类型的节点，一旦客户端和服务器的会话结束或过时，那么该节点就会消失。

　　例如，监控系统在/clusterServers节点上注册一个Watcher，之后每动态加机器，那么就往 /clusterServers 下建立一个 EPHEMERAL类型的节点：/clusterServers/{hostname}. 这样，监控系统就可以实时知道机器的增减状况，至于后续处理就是监控系统的业务了。

　　2.Master选举

　　在分布式环境中，相同的业务应用分布在不一样的机器上，有些业务逻辑(例如一些耗时的计算，网络I/O处理)，每每只须要让整个集群中的某一台机器进行执行，其他机器能够共享这个结果，这样能够大大减小重复劳动，提升性能，因而这个master选举即是这种场景下的碰到的主要问题。

　　利用ZooKeeper的强一致性，可以保证在分布式高并发状况下节点建立的全局惟一性，即：同时有多个客户端请求建立 /currentMaster 节点，终究必定只有一个客户端请求可以建立成功。利用这个特性，就能很轻易的在分布式环境中进行集群选取了。

　　另外，这种场景演化一下，就是动态Master选举。这就要用到?EPHEMERAL_SEQUENTIAL类型节点的特性了。

上文中提到，全部客户端建立请求，最终只有一个可以建立成功。在这里稍微变化下，就是容许全部请求都可以建立成功，可是得有个建立顺序，因而全部的请求最终在ZK上建立结果的一种可能状况是这样：

/currentMaster/{sessionId}-1 ,?/currentMaster/{sessionId}-2 ,?/currentMaster/{sessionId}-3….. 每次选取序列号最小的那个机器做为Master，若是这个机器挂了，因为他建立的节点会立刻小时，那么以后最小的那个机器就是Master了。

　　3.搜索系统

　　在搜索系统中，若是集群中每一个机器都生成一份全量索引，不只耗时，并且不能保证彼此之间索引数据一致。所以让集群中的Master来进行全量索引的生成，而后同步到集群中其它机器。另外，Master选举的容灾措施是，能够随时进行手动指定master，就是说应用在zk在没法获取master信息时，能够经过好比http方式，向一个地方获取master。

　　在Hbase中，也是使用ZooKeeper来实现动态HMaster的选举。在Hbase实现中，会在ZK上存储一些ROOT表的地址和 HMaster的地址，HRegionServer也会把本身以临时节点(Ephemeral)的方式注册到Zookeeper中，使得HMaster能够随时感知到各个HRegionServer的存活状态，同时，一旦HMaster出现问题，会从新选举出一个HMaster来运行，从而避免了 HMaster的单点问题

　　学习大数据开发，能够参考好程序员提供的大数据学习路线，该学习路线提供完整的大数据开发知识体系，内容包含Linux&&Hadoop生态体系、大数据计算框架体系、云计算体系、机器学习&&深度学习。