版权声明：Collected by Bro_Rabbit only for study https://blog.csdn.net/weixin_38240095/article/details/82987624
1. 基本原理引入：以写操作为例
*防裂说明*：
- Client写入blk_x的第一份副本给某个 DataNode后，继续写blk_x+1的第一份副本给某个DataNode，blk_x的n份副本由第一份副本所在DataNode拷贝给其他DataNode，整个过程是异步进行的；
- 存储小文件降低性能，主要原因为：
- 不会浪费DataNode，因为默认情况下一个Block=128MB，小于128MB的文件同样占用一个Block；
- 但会浪费NameNode，因为元数据meta的存储空间是有限的（也就决定了格式化的meta项数是一定的[类似CPU地址线决定存储单元的个数]）
- 整个FS的理论存储容量=meta的项数*Block大小
2. HDFS副本Replicas放置策略：
- 第一副本一般置于离客户端最近的DataNode；
- 第二副本优先放在另一个机架Rack上的DataNode；
- 第三副本将从本机架Rack随机找一个DataNode；
3. NameNode的meta元数据管理机制[重点]
(1) 一条meta元数据记录：
- 数据结构：NameNode(FileName, Replicas, Block_ids, id2host ...)
- 举例：/test/a.log, 3, {blk_1,blk_2}, [{blk_1:[h0,h1,h2]},{blk_2:[h2,h3,h4]}],...
(2) 写入put时的meta变化
(3)读取get直接通过内存中元数据meta进行操作。内存中的元数据meta实时更新，总是最新的。
(4) meta元数据合并
什么时候CheckPoint?
- fs.checkpoint.period 指定两次 checkpoint 的最大时间间隔，默认3600s
- fs.checkpoint.size 规定edits_log文件的最大值，一旦超过这个值强制checkpoint，不管是否到达最大时间间隔。默认大小是64M。
目前机制的问题：
CheckPoint之前，NameNode宕机，meta可以通过fsimage+edits_log恢复，但是截止到恢复Service不能正常提供。
解决方案：
双NameNode -> HA
*总结：NameNode主要职责
- 维护元数据meta信息
- 维护hdfs的虚拟目录树
- 响客户端请求
4. DataNode真实数据存储
- 从字节流中仅按配置字节切块，不做其他任何改动；
- HDFS默认Block大小是128MB，可以修改hdfs-site.xml中的dfs.block.size来配置块大小；
- HDFS中，如果一个文件小于一个Block大小，并不占用整个Block的存储空间，但仍会占用一条元数据meta记录；
- 副本Replicas默认为3个，可以修改hdfs-site.xml中的dfs.replication来配置块的副本数；