HDFS 2.X HA高可用原理

先上图

ha模式

在hdfs1.x的时候，主要组件有namenode、secondnode、datanode，但是正如我们知道的，namenode的稳定性决定了整个系统的稳定性，这是存在的一大问题，所以在2.x版本中添加了如下如见

之前的一个namenode成了两个，但是这两个namenode被赋予了一个状态，active/standby，意思很明显，一主一备，也就是说，在2.x版本中，也只能有一个namenode，如果有两个，则会出现split brain现象，现在来具体说受2.x的各个组件及它们的作用

namenode(Active) :

这个节点也就是主节点，跟1.x中的namenode的功能是一样的

namenode(Standby):

备用节点，为何叫备用？能成为备用，必须具备什么条件？

那就是，需要这个备用节点在主节点不可用的时候，能够马上代替主节点工作，也就是，备用节点必须具备主节点的所有数据。所以，每个dataNode在报告块信息的时候，会同时向主节点和备用节点报告，如此，便保证了主备两个节点的块信息是一致的，但是，我们想想，在namenode上面难道只有块信息？不止，还有其他元数据，比如块的大小，偏移量，MD5验证信息等，我们知道，hdfs客户端只会与一个节点进行沟通，那就是主节点，也就是说，每个块的上传信息，只有主节点上面有，那这些数据备用节点如何得到呢？那就出来了这个服务器JN

同时呢，在1.x版本中我们知道，有一个secondnode,去哪里了呢，基于内存存储的namenode难道不怕掉电吗，当然怕，所以这个功能还是存在的，现在这个角色的任务，现在交给了这个备用节点，所以，备用节点，还有一大功能，就是负责日志文件与镜像文件的整合工作

JN(journal name):

这个节点主要负责就是用了主节点和备用节点的数据的同步工作，如何同步？

主节点在接收客户端的任务后，会生成一个日志文件，在日志文件每次更新的时候主节点会将这个日志文件写入到JN中，备用节点则负责去JN中将日志文件接收下来，并且自己执行一遍，以达到与主节点状态一直的目的

但是，为什么会有三台呢？

其实在最初的时候，确实只有一天，但是，发现，如果这台负责通过工作的节点挂掉了怎么办？

所以，有了如今的3台，形成一个集群，如果一台机器挂了，另外一台接替工作

那为什么一定是3台呢，不能是4台吗？

当然可以，但是，在集群高可用的概念中，有一种思想，“过半可用”，也就是说，整个集群，当一半的节点失效的时候，整个集群也就瘫痪了，如果有4台，瘫痪的概率是50%，如果是3台呢，必须挂掉2台，整个集群才算瘫痪，也是就是瘫痪概率33.3%，所以，在集群的搭建原则中，一般搭建台数为奇数

好了，现在如果主节点坏了，能够用备用节点替换了。那么问题来了，由谁去启动切换呢？当然是你啦！还要我给你去切换啊，但是这样切换似乎不太现实，谁知道他什么时候崩啊！总不能搬个凳子坐那看着吧，还下不下班啦！

所以这个时候，我们就需要了解一个东西了，zookeeper，我们知道（管你知不知道），zookeeper组件在集群中应用很广泛，因为它具有监控通知功能。如何监控？如何通知？

zookeeper:

首先，我们的主节点和备用节点，必须都去向zookeeper进行注册，注册能干嘛？首先呢，谁注册得早，谁就是主节点，另外一个就是备用节点，其次，在主备进行了注册后，zookeeper将会在主备节点上分别启动一个FailoverController进程，简称zkfc,这个进程的目的就是监控主备的健康状况，每隔一定的时间，会向zookeeper发送心跳，如果主节点挂掉了，那么这个心跳也就消失了，zookeeper察觉到这个异常后，会马上通知备用节点，让备用节点上位，接替主节点的工作。如果主节点被救回来了呢？就回来也就是当个备用了，咋的，回来了就想上位啊？这点与zookeeper集群有些不同（稍微拓展下），三个zookeeper共同合作，其中有一个loader,其余两个flower，在它们之间也是有一些竞选机制的，这里面有一个比较简单的竞选的机制，那就是根据myid，我们在部署zookeeper就设置了这个myid,这个id的作用就是与竞选有关，数字越大，在集群启动的时候，越容易当loader。

整个过程就是这样，如有叙述有误，欢迎指点！