浅谈Hadoop容错机制
简单介绍一下Hadoop中数据存储的可靠性和完整性，其中包括HDFS的容错机制、NameNode(元数据结点)的单点失效解决机制、Block数据块的多副本存储机制、
NameNode与DataNode之间的心跳检测机制、数据存储等。
（一）HDFS中NameNode单点问题
HDFS这种分布式的存储系统，存在中心结点，那么这个中心结点的可靠性就是整个集群的可靠性的关键，对于版本0.20.x的hadoop来说，主要是有一个叫做SecondaryNameNode的机制来解决，这个结点周期性的从NameNode 结点上下载磁盘镜像和日志文件，在本地将日志合并到镜像中，产生新的镜像，上传到NameNode，当NameNode结点重启时就会加载此最新的镜像文件，这个过程叫做CheckPoint，那么SecondaryNameNode会周期性的做CheckPoint，但是这种机制对于单点问题来说不是很理想，因为你做CheckPoint只能保存上次的元数据，那么CheckPoint之后的元数据在NameNode 失效后是会丢失的。
FaceBook提出了Avatar机制来解决NameNode 的单点问题，这里多设置了一个叫做 Standby NameNode 的结点，原来的NameNode 叫做 PrimaryNameNode, 另外还有一个结点 NFS 用来存储 Primary NameNode 的日志和镜像文件。这里跟前面的解决机制不同的是 Standby NameNode 这个结点是 热备结点， 它不仅具有前面的CheckPoint的功能，还会周期性的读取 NFS结点上的 PrimaryNameNode 的日志来保持命名空间的同步，此外 DataNode 会同时向 Standby NameNode 和 PrimaryNameNode 发送心跳信息和数据块信息，这样，这两个结点的元数据信息是一致的，因此这也是为什么是热备结点的原因了。
注： 镜像文件存储的是NameNode 的命名空间即目录树，就是将内存中的命名空间持久化到镜像文件中。
CheckPoint的流程如下图：
1. SecondaryNameNode 通知 NameNode 开始做CheckPoint,，并且通过远程RPC调用NameNode的rollEditLog()方法建立临时日志文件
2. SecondaryNameNode从NameNode 上下载镜像和日志文件。
3. SecondaryNameNode将下载的镜像文件和日志文件合并。
4. SecondaryNameNode将合并后的镜像上传到NameNode上。
5. SecondaryNameNode通过远程RPC调用NameNode的rollFsImage()方法，用新的镜像和日志文件代替旧的文件，通知NameNode 结束CheckPoint。
（二）HDFS数据块副本机制
在HDFS中一个文件可能有许多的数据块（Block）组成，每个数据块的副本的默认数量是3，其中两个放在同一个机架中，两一个放在其他机架，对于大数据存储来说，这种机制会造成数据的存储空间翻倍，因此需要一定的机制来节省磁盘空间，比如基于历史统计记录的动态副本策略，和FaceBook 的 RAID机制。
（三）HDFS负载均衡
NameNode 根据 DataNode发送的心跳信息和数据块信息来掌握 DataNode 的当前状态，HDFS有一个 balancer 工具 ， 可以由管理员启动，用来迁移DataNode 之间的数据块，当集群负载较高的时候不宜采用，因为可能会造成网络阻塞，造成客户端延迟过大。
（四）MapReduce容错
运行JobTracker 的结点为主结点，用于调度作业和调度MAP 和 Reduce 任务到 TaskTracker 上， 同样TaskTracker也会周期性的向JobTracker 发送心跳信息，保护任务执行的状况，如果在指定时间内没有收到心跳信号，那么认为此结点已经宕机，重新分配 Map 或者 Reduce 任务到其他的结点上。当TaskTracker没有宕机，但是在其上运行的任务失败次数达到一个阈值的时候，JobTracker 会认为其处于高负载状态，将不会再分配任务给此结点，列入黑名单。
最后关于Avatar机制：
其实就是应用在hadoop-0.20.2上的补丁程序， 现在很多大型的IT 厂商的集群都将其作为NameNode的单点解决方案。
该机制主要是提供了一个 Standby NameNode 结点作为 热备 ，这两个NameNode 结点的元数据会保持一致，在PrimaryNameNode 宕机时，Standby NameNode 切换为 PrimaryNameNode 的时间很短。
参考文献：《实战hadoop》 刘鹏