Hadoop 介绍
Hadoop是Apache的一个开源的分布式计算平台，核心是以HDFS分布式文件系统和MapReduce分布 式计算框架构成，为用户提供了一套底层透明的分布式基础设施
Hadoop框架中最核心设计就是:HDFS和MapReduce。HDFS提供了海量数据的存储,MapReduce提 供了对数据的计算。
- HDFS是Hadoop分布式文件系统，具有高容错性、高伸缩性，允许用户基于廉价硬件部署，构建分 布式存储系统，为分布式计算存储提供了底层支持
- MapReduce提供简单的API，允许用户在不了解底层细节的情况下，开发分布式并行程序，利用大 规模集群资源，解决传统单机无法解决的大数据处理问题
hdfs 分布式文件系统
NameNode
- 维护整个文件系统的文件目录树，文件目录的元信息和文件数据块索引
- 以FsImage和EditLog形式存储在本地
- 整个系统的单点，存在SPOF(Simple Point of Failure)
Secondary NameNode
- 又名CheckPoint Node，定期合并FsImage和EditLog
- 不接收客户端的请求，作为NameNode的冷备
datanode
- 实际存储数据的单元
- 以Block为单位
- 数据以普通文件形式保存在本地文件系统
Client:
- 与HDFS交互，进行读写、创建目录、创建文件、复制、删除等操作
- HDFS提供了多种客户端:命令行Shell、Java API、Thrift接口、C library、WebHDFS等
QJM
Hadoop中的QJM（Quorum Journal Manager）是一种用于提供NameNode高可用性的机制。在Hadoop的HA（高可用性）模式中，通常会使用QJM来管理和维护多个NameNode之间的元数据的一致性
Hadoop中的QJM（Quorum Journal Manager）是一种用于提供NameNode高可用性的机制。
在Hadoop的HA（高可用性）模式中，通常会使用QJM来管理和维护多个NameNode之间的元数据的一致性。
QJM的主要作用是管理NameNode的编辑日志（Edit Log）。在Hadoop的HA模式下，存在多个NameNode实例，其中一个为Active NameNode，负责处理客户端的读写请求，其他为Standby NameNode，处于备用状态。
为了保证Active和Standby NameNode之间的元数据一致性，QJM会将NameNode的编辑日志（Edit Log）复制到一个或多个Journal节点中，并确保多数节点（即Quorum）都已成功接收并写入了这些编辑日志
以下是QJM的一些关键特点和工作原理：
- 多副本复制： QJM将NameNode的编辑日志复制到多个Journal节点上，以确保数据的持久性和一致性。默认情况下，QJM会将每个编辑日志条目复制到多个Journal节点上，直到多数节点都已成功接收并写入这些条目。
- Quorum： QJM使用Quorum机制来确保数据的一致性。只有在大多数Journal节点都已成功接收和写入某个编辑日志条目后，该条目才被认为已经提交，从而保证了数据的一致性。
- 自动故障转移： 如果Active NameNode发生故障，QJM可以自动将Standby NameNode切换为Active状态，并接管服务。这样可以确保服务的连续性和高可用性。
- ZooKeeper协调： QJM通常会与ZooKeeper等协调服务配合使用，以便协调和管理NameNode的状态和切换过程。ZooKeeper负责监控和管理Active和Standby NameNode之间的切换过程，以及Journal节点的状态。
Fencing
QJM的fencing
QJM的fencing，确保只有一个NN能写成功
在Hadoop的HA（高可用性）环境中，为了保证系统的一致性和可靠性，在进行主备切换时需要确保之前的主节点（Active NameNode）不会继续对外提供服务。这种机制被称为"fencing"，即隔离或禁止之前的主节点，以防止其继续访问共享资源，从而避免数据损坏或服务冲突。
在Hadoop中，Quorum Journal Manager（QJM）使用了"fencing"机制来确保只有一个NameNode实例能够对外提供服务。具体来说，QJM使用了两种常见的"fencing"方法：
-
节点禁用（Node Fencing）： 在节点禁用中，QJM通过执行一些操作来禁用之前的主节点，例如关闭其网络连接或停止其所在的服务器。这样可以确保之前的主节点无法继续对外提供服务，从而避免数据损坏或服务冲突。
-
标记（Token-Based Fencing）： 在标记机制中，QJM使用了一种基于令牌的机制来禁用之前的主节点。具体来说，QJM会向集群中的所有节点发送一个特殊的令牌，并要求每个节点在收到令牌后进行响应。如果之前的主节点无法响应或在超时时间内没有响应，那么它将被认为已经被禁用，从而确保新的主节点可以安全地接管服务。
DataNode的Fencing
DataNode的fencing，确保只有一个NN能命令DN。(HDFS-1972)
- 每个NN改变状态的时候，向DN发送自己的状态和一个序列号(类似Epoch Numbers)。
- DN在运行过程中维护此序列号，当failover时，新的NN在返回DN心跳时会返回自己的active状 态和一个更大的序列号。DN接收到这个返回则认为该NN为新的active。
- 如果这时原来的active NN恢复，返回给DN的心跳信息包含active状态和原来的序列号，这时 DN就会拒绝这个NN的命令。
客户端的fencing
客户端fencing，确保只有一个NN能响应客户端请求。
让访问Standby NN的客户端直接失败:
-
在RPC层封装了一层，通过FailoverProxyProvider以重试的方式连接NN。
-
通过若干次连接一个NN失败后尝试连接新的NN，对客户端的影响是重试的时候增加一定的延 迟。
-
客户端可以设置重试次数和时间
ZKFailoverController HA设计之 透明切换(failover)
主备切换的实现:ZKFC
ZKFC即ZKFailoverController，作为独立进程存在，负责控制NameNode的主备切换，ZKFC会监测 NameNode的健康状况，当发现Active NameNode出现异常时会通过ZooKeeper集群进行一次主 备选举，完成Active和Standby状态的切换。
ZKFailoverController是Hadoop HDFS（分布式文件系统）中的一个组件，用于在NameNode故障转移时协调主备切换的过程。它通常作为NameNode进程的一部分运行，负责与ZooKeeper协调服务的状态和切换过程。
具体来说，ZKFailoverController在Hadoop HDFS的HA（高可用性）模式下运行，而且每个NameNode节点都有一个对应的ZKFailoverController实例。在HA模式中，有一个Active NameNode和一个或多个Standby NameNode，每个NameNode节点上都会运行一个ZKFailoverController来确保故障转移的顺利进行。
ZKFailoverController的主要功能包括：
-
监控Active NameNode的状态：ZKFailoverController会监控Active NameNode的状态，并在检测到其故障或不可用时触发故障转移过程。
-
与ZooKeeper交互：ZKFailoverController通过与ZooKeeper协调服务的状态，以及与其他NameNode节点通信，来实现故障转移的过程。它使用ZooKeeper来选择新的Active NameNode，并确保所有节点之间的状态一致性。
-
启动和停止NameNode服务：ZKFailoverController负责启动和停止NameNode服务，以确保故障转移的顺利进行。当一个NameNode节点被选为新的Active节点时，ZKFailoverController会启动该节点上的NameNode服务，并停止之前Active节点上的服务。
综上所述，ZKFailoverController是Hadoop HDFS中用于实现NameNode故障转移的关键组件之一，在HA模式下的每个NameNode节点上都存在。它通过与ZooKeeper协调服务的状态和与其他节点通信，确保故障转移过程的顺利进行，从而提高了HDFS的可靠性和容错性。
HDFS RBF
基于路由的Federation方案是在服务端添加了一个Federation layer，这个额 外的层允许客户端透明地访问任何子集群。Federation layer将Block访问引导 至适当的子群集，维护namespaces的状态。
Federation layer包含多个组件。Router是一个与NameNode具有相同接口的 组件，根据State Store的元数据信息将客户端请求转发给正确的子集群
Router(无状态)
一个系统中可以包含多个Router，每个Router包含两个作用:
- 为客户端提供单个全局的NameNode接口，并将客户端的请求转发到正 确子集群中的Active NameNode 上。
- 收集NameNode的心跳信息，报告给State Store，这样State Store维护 的信息是实时更新的。
State Store( 分布式)
在State Store里面主要维护以下几方面的信息:
- 子集群的状态，包括块访问负载、可用磁盘空间、HA状态等; 2. 文件夹/文件和子集群之间的映射，即远程挂载表;
- Rebalancer操作的状态;
- Routers的状态。
RBF访问流程
- 客户端向集群中任意一个Router发出某个文件的读写请求操作;
- Router从State Store里面的Mount Table查询哪个子集群包含这个文件，并从State Store里 面的Membership table里面获取正确的NN;
- Router获取到正确的NN后，会将客户端的请求转发到NN上，然后也会给客户端一个请求告诉 它需要请求哪个子集群;
- 此后，客户端就可以直接访问对应子集群的DN，并进行读写相关的操作
FsImage和EditLog
为了解决什么问题？
-
NameNode的内存中有整个文件系统的元数据，例如目录树、块信息、权限信息等等。
-
当NameNode异常宕机时，内存中的元数据将全部丢失。
-
为了让重启的NameNode获得最新的宕机前的元数据，才有了FsImage和Editlog
FsImage
- FsImage是整个NameNode内存中元数据在某一时刻的快照(Snapshot)。
- FsImage不能频繁的构建，生成FsImage需要花费大量的内存。
- 目前FsImage只在NameNode重启时才构建。
