1.HDFS的存储机制（读写流程）
总体：
- 按块（block）存储，默认按照128M大小进行文件数据拆分，将不同拆分的块数据存储在不同datanode服务器上
- 三副本机制：为了保证HDFS的数据的安全性，避免数据丢失，HDFS对每个块数据进行备份，默认情况下块数据会存储3份，叫做三副本，副本块存储在不同服务器上
- 默认存储策略由BlockPlacementPolicyDefault类支持。也就是日常生活中提到最经典的3副本策略。
- 1st replica 如果写请求方所在机器是其中一个datanode,则直接存放在本地,否则随机在集群中选择一个datanode.
- 2nd replica 第二个副本存放于不同第一个副本的所在的机架
- 3rd replica 第三个副本存放于第二个副本所在的机架,但是属于不同的服务器节点
写入数据流程：
1）客户端向NameNode请求上传文件 ，NameNode检查目标文件是否已存在 ，父目录是否存在。
2）NameNode返回是否可以上传。
3）客户端请求第一个 block上传到哪几个datanode服务器上。
4）NameNode返回3个datanode节点 ，分别为dn1、dn2、dn3。
5）客户端请求dn1上传数据 ，dn1收到请求会继续调用dn2 ，然后dn2调用dn3 ，将这个通信管道建立完成。
6）dn1、dn2、dn3逐级应答客户端
7）客户端开始往dn1上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位 ，dn1 收到一个packet就会传给dn2 ，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答
8）当一个block传输完成之后 ，客户端再次请求NameNode上传第二个block的服务器。（重复执行3-7步）
读取数据流程：
1）客户端向NameNode请求下载文件 ，NameNode通过查询元数据 ，找到文件块所在的datanode地址。
2）挑选一台datanode（就近原则 ，然后随机）服务器 ，请求读取数据。
3）datanode开始传输数据给客户端（从磁盘里面读取数据放入流 ，以packet为单位来做校验）。
4）客户端以packet为单位接收 ，先在本地缓存 ，然后写入目标文件。
2.Secondary NameNode工作机制
NameNode管理着元数据信息，其中有两类持久化元数据文件：edits操作日志文件和fsimage元数据镜像文件。新的操作日志不会立即与fsimage进行合并，也不会刷到NameNode的内存中，而是会先写到edits中(因为合并需要消耗大量的资源)，操作成功之后更新至内存
SecondaryNameNode有两个作用，一是镜像备份，二是日志与镜像的定期合并。两个过程同时进行，称为checkpoint（检查点）。
这个过程大体就是三个步骤：拷贝、合并、替换
fsimage是存储文件系统的快照（元数据镜像文件）
- fsimage文件其实是Hadoop文件系统元数据的一个永久性的检查点，其中包含Hadoop文件系统中的所有目录和文件idnode的序列化信息；fsimage包含Hadoop文件系统中的所有目录和文件idnode的序列化信息；对于文件来说，包含的信息有修改时间、访问时间、块大小和组成一个文件块信息等；而对于目录来说，包含的信息主要有修改时间、访问控制权限等信息。
edits记录对文件系统的更改，也就是编辑日志，存放的是Hadoop文件系统的所有更新操作的路径，文件系统客户端执行的所以写操作首先会被记录到edits文件中
checkpoint机制的触发条件：
checkpoint机制是secondname和NameNode之间的数据操作
该机制决定了secondname什么时候进行元数据的持久化保存
条件一 距离上一次保存时间过去了1个小时
条件二 文件的事务操作(文件写入，文件修改，文件删除)达到了100万次
两个条件任意一个满足就执行checkpoint
第一阶段：NameNode启动
（1）第一次启动NameNode格式化后 ，创建fsimage和edits文件。如果不是第一次启动 ，直接加载编辑日志和镜像文件到内存。
（2）客户端对元数据进行增删改的请求
（3）NameNode记录操作日志 ，更新滚动日志。
（4）NameNode在内存中对数据进行增删改查
第二阶段：SecondaryNameNode工作：
（1）Secondary NameNode询问NameNode是否需要checkpoint。直接带回NameNode是否检查结果。
（2）Secondary NameNode请求执行checkpoint。
（3）NameNode滚动正在写的edits日志
（4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode
（5）Secondary NameNode加载编辑日志和镜像文件到内存 ，并合并。
（6）生成新的镜像文件fsimage.chkpoint
（7）拷贝fsimage.chkpoint到NameNode
（8）NameNode将fsimage.chkpoint重新命名成fsimage
3.NameNode与SecondaryNameNode的区别与联系？
机制流程同上
区别：
- NameNode负责管理整个文件系统的元数据，以及每一个路径（文件）所对应的数据块信息。
- SecondaryNameNode主要用于定期合并命名空间镜像和命名空间镜像的编辑日志。
联系：
- SecondaryNameNode中保存了一份和NameNode一致的镜像文件（fsimage）和日志文件（edits）。
- 在主NameNode发生故障时（假设没有及时备份数据），可以从SecondaryNameNode恢复数据。
4.服役新数据节点和退役旧节点步骤
节点上线操作：
当要新上线数据节点的时候，需要把数据节点的名字追加在 dfs.hosts 文件中
（1）关闭新增节点的防火墙
（2）在 NameNode 节点的 hosts 文件中加入新增数据节点的 hostname
（3）在每个新增数据节点的 hosts 文件中加入 NameNode 的 hostname
（4）在 NameNode 节点上增加新增节点的 SSH 免密码登录的操作
（5）在 NameNode 节点上的 dfs.hosts 中追加上新增节点的 hostname,
（6）在其他节点上执行刷新操作：hdfs dfsadmin -refreshNodes
（7）在 NameNode 节点上，更改 slaves 文件，将要上线的数据节点 hostname 追加到 slaves 文件中
（8）启动 DataNode 节点
（9）查看 NameNode 的监控页面看是否有新增加的节点
节点下线操作：
（1）修改/conf/hdfs-site.xml 文件
（2）确定需要下线的机器，dfs.osts.exclude 文件中配置好需要下架的机器，这个是阻止下架的机器去连接 NameNode。
（3）配置完成之后进行配置的刷新操作./bin/hadoop dfsadmin -refreshNodes,这个操作的作用是在后台进行 block 块的移动。
（4）当执行三的命令完成之后，需要下架的机器就可以关闭了，可以查看现在集群上连接的节点，正在执行 Decommission，会显示：Decommission Status : Decommission in progress 执行完毕后，会显示：Decommission Status : Decommissionedasdad
（5）机器下线完毕，将他们从excludes 文件中移除。
5.NameNode挂了怎么办
方法一：将SecondaryNameNode中数据拷贝到namenode存储数据的目录；
方法二：使用-importCheckpoint选项启动namenode守护进程 ，从而将SecondaryNameNode中数据拷贝到namenode目录中。
步骤如下：
拿一台和原来机器一样的机器，包括配置和文件，一般来说最快的是拿你节点机器中的一台，立马能用（部分配置要改成NameNode的配置）创建一个空的文件夹，该文件夹就是配置文件中dfs.name.dir所指向的文件夹。拷贝你的secondary NameNode checkpoint出来的文件，到某个文件夹，该文件夹为fs.checkpoint.dir指向的文件夹执行命令bin/hadoop namenode -importCheckpoint这样NameNode会读取checkpoint文件，保存到dfs.name.dir。但是如果你的dfs.name.dir包含合法的fsimage，是会执行失败的。因为NameNode会检查fs.checkpoint.dir目录下镜像的一致性，但是不会去改动它。
6.Hadoop的NameNode宕机怎么解决
如果只是节点挂了 ，重启即可 ，如果是机器挂了 ，重启机器后看节点是否能重启 ，不能重启就要找到原因修复了
先看宕机后的损失如何，如果是内存中的数据丢失，但磁盘数据还在，可以将 secondary namenode 的工作目录 copy 到 namenode 的工作目录中，恢复上一次 checkpoint 的数据，这样可以恢复大部分数据，但不能恢复所有数据，因为有些数据还没做 checkpoint。
也可以设置 namenode 的工作目录在多块磁盘上，那么 edits 日志文件就会同时写在多块磁盘上，如果一个磁盘坏了，那另一块磁盘上仍保存着数据。这两个磁盘是可以并发的，磁盘 IO 不会起冲突。
最终解决方案是在建立集群初期的时候建立 NameNode HA 高可用模式。
HA机制通过配置两个NameNode节点，一个作为Active NameNode，另一个作为Standby NameNode，共同承担元数据管理的职责。Active NameNode负责处理客户端的请求，而Standby NameNode则作为热备节点，实时同步Active NameNode的元数据，确保在Active NameNode发生故障时能够迅速接管其职责。
实现NameNode的HA机制，需要依赖一些关键组件和技术，如ZKFailoverController和Zookeeper集群。ZKFailoverController负责监控NameNode的健康状况，并在主NameNode故障时借助Zookeeper实现自动的主备选举和切换。Zookeeper集群则为主备切换控制器提供主备选举支持，确保切换过程的高可用性和可靠性。
