前言

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架构

结束语

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