扣丁学堂大数据开发Zookeeper集群管理与选举

今天扣丁学堂大数据培训老师给大家介绍一下关于大数据开发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的单点问题

　　以上就是关于扣丁学堂大数据开发Zookeeper集群管理与选举的详细介绍，扣丁学习提供在线从零到一的大数据学习路线，其内容包含Linux&&Hadoop生态体系、大数据计算框架体系、云计算体系、机器学习&&深度学习。

作者：扣丁学堂
链接：https://www.jianshu.com/p/07de2d9b341f