hdfs架构与高可用性

96
trieyouth
2016.04.17 22:48* 字数 999

前言

hdfs对于超大文件具有超优越的性能,这篇来看看hdfs架构和他的高可用性基础,毕竟不知道原理的程序员不是好的程序。

架构概念

hdfs基本架构
  • namenode
    从图中可以看出,namenode是一个管理者,namenode包含了元数据和datanode存储的数据块的id,我们展开联想,他就是武侠小说里那个知道事件背后的所有的秘密的人物,client就像是主人公,每次想知道秘密都必须去询问这个namenode。namenode本身是没有数据的,所有的数据都在datanode。namenode为了给客户端提供良好的服务,所以在内存中也存储了一份元数据和datanode存储的数据块的id。

  • datanode
    datanode就是真正的数据储藏室,是真的数据存放的地方。hdfs面对超大文件是把大文件切割成小块存储,所以datanode就是存储这些小块的地方。

  • namenode的掌控力
    namenode为什么可以知道datanode的存储了那些数据?也就是datanode与namenode之间如何的通信?答案就是心跳。datanode定时会像namenode发出心跳,保证数据存储信息同步到namenode。

架构的危机

正如武侠小说中那个知道的秘密的人被凶手杀了,一切的线索就断了那样,namenode挂了,或者namenode的数据丢失了,整个hdfs就会瘫痪了。

怎么样当namenode挂了的时候保证hdfs的可用性

举个例子,年事已高的皇帝,为了自己百年之后国家不会大动乱,会提前立一个太子。所以这里其实是同理,找一个替身,当namenode挂了之后,替身继续工作,这就是SecondNameNode进程,在前面配置伪分布式测试环境的时候大家使用jps都会看到这个进程。那么问题来了,SecondNameNode怎么知道NameNode挂了?想法如下:

  • 第一种想法:心跳机制
    就像太子每天去看看皇帝挂了没有一样,SecondNameNode定时去ping一下NameNode看看挂了没。

不足之处:由于可能是网络链路原因导致心跳不通,所以这个方法不是太可行。

  • 第二种想法:磁盘心跳
    就是皇帝有一个爱妃,皇帝每天都见她,然后他和太子有勾结,然后太子就知道了皇帝挂了没(太污了)。这里其实就是NameNode每天都会在磁盘上做一个标记,比如是当前存活的时间,SecondNameNode也去这个磁盘上读这个标记,然后这个标记存在而且时间不是特别久远,就认为NameNode还活着。

不足之处:爱妃挂了,那么整个机器就挂了。

  • 第三种想法:第三方的仲裁
    这种方式就是太子没有任何野心,每天等啊等啊等,直到有一天朝中的几个重臣宣读皇帝遗旨,这时候太子上位。这里用的是ZooKeeper,这个有时间了再讲ZooKeeper这个分布式神器。

怎么保证hdfs中namenode的数据不丢失

答案还是冗余,将namenode的数据放在三个节点上,三个节点同时丢失的概率就很小了。

那么现在整体的架构就演变成为:

hdfs架构

结束语

思想真的是想通的,保证数据可靠性不丢失永远是冗余,无非就是直接备份与使用一些算法减少冗余产生的数据的体积。这里的实时通信依旧是心跳,还有判断挂了没就是第三方仲裁。

随笔
Web note ad 1