Table of Contents
一.前言
二. Block、 Replica、 BlocksMap
2.1.Block
2.2.BlockInfo
2.3.BlockUnderConstructionFeature
2.4.BlocksMap类
2.5. Replica类状态
2.6.Block类状态
三.数据块副本状态
3.1.BlockManager数据结构
3.2.CorruptReplicasMap类
3.3.InvalidateBlocks类
3.4.LowRedundancyBlocks
一.前言
Namenode维护着HDFS中两个最重要的关系。
■ HDFS文件系统的目录树以及文件的数据块索引。文件的数据块索引即每个文件对应的数据块列表[INodeFile.blocks]。
■ 数据块和数据节点的对应关系，即指定数据块的副本保存在哪些数据节点上的信息。
数据块的副本保存在哪些数据节点上的信息是在Datanode启动时， 由Datanode上报给Namenode的。 也就是说，这个信息是Namenode动态构建起来的， 而不是从fsimage文件中加载的。Namenode会定期将文件系统目录树以及文件与数据块的对应关系保存至fsimage文件中， 然后在Namenode启动时读取fsimage文件以重建HDFS第一关系。 这里要注意的是第二关系并不会保存至fsimage文件中， 也就是说， fsimage并不记录数据块和数据节点的对应关系。 这部分数据是由Datanode主动将当前Datanode上保存的数据块信息汇报给Namenode， 然后由Namenode更新内存中的数据， 以维护数据块和数据节点的对应关系。
二. Block、 Replica、 BlocksMap
INodeFile.blocks字段记录了一个HDFS文件拥有的所有数据块， 也正是通过这个字段HDFS第一关系与第二关系发生了关联。 从INodeFile.blocks字段入手， 查看HDFS是如何抽象数据块、 如何实现描述数据块和数据节点对应关系的数据结构， 以及如何在内存
中保存这些数据结构的。
INodeFile.blocks字段是一个BlockInfo类型的数组， BlockInfo类是Block的子类， HDFS使用Block类抽象Namenode中的数据块.
2.1.Block
Block类用来唯一地标识Namenode中的数据块， 是HDFS数据块最基本的抽象接口。 Block类实现了Writable接口， 是可以序列化的。 Block类还实现了Comparable接口，按照blockid大小排序。
Block类定义了三个核心字段：
①blockId唯一地标识这个Block对象；
②numBytes是这个数据块的大小（单位是字节） ;
③generationStamp是这个数据块的时间戳 。
/*************************************************** A Block is a Hadoop FS primitive, identified by a long.***************************************************/
@InterfaceAudience.Private
@InterfaceStability.Evolving
public class Block implements Writable, Comparable<Block> {// block 的前缀public static final String BLOCK_FILE_PREFIX = "blk_";// metadata的扩展名public static final String METADATA_EXTENSION = ".meta";// blockId唯一地标识这个Block对象；private long blockId;// numBytes是这个数据块的大小（单位是字节） ;private long numBytes;//generationStamp是这个数据块的时间戳（联想GenerationStamp这个类）private long generationStamp;// 其他代码略...}hdfs系统存储的目录示例:
2.2.BlockInfo
BlockInfo类扩展自Block类， 是Block类的补充说明。
BlockInfo类定义了replication字段保存该数据块的副本数. 定义了bcId 用于标识block的ID.
BlockInfo类定义了storages字段保存这个Block的副本存储在哪些数据节点上， storages是一个DatanodeStorageInfo类型的数组.
public abstract class BlockInfo extends Blockimplements LightWeightGSet.LinkedElement {public static final BlockInfo[] EMPTY_ARRAY = {};/*** Replication factor.*/private short replication;/*** Block collection ID.*/private volatile long bcId;/** For implementing {@link LightWeightGSet.LinkedElement} interface. */private LightWeightGSet.LinkedElement nextLinkedElement;// Storages this block is replicated onprotected DatanodeStorageInfo[] storages;private BlockUnderConstructionFeature uc;/*** Construct an entry for blocksmap* @param size the block's replication factor, or the total number of blocks* in the block group*/public BlockInfo(short size) {this.storages = new DatanodeStorageInfo[size];this.bcId = INVALID_INODE_ID;this.replication = isStriped() ? 0 : size;}}
2.3.BlockUnderConstructionFeature
HDFS在加载fsimage时， 如果当前加载的文件处于正在构建状态， 也就是INodeFile中包含BlockUnderConstructionFeature特性， 则将该INodeFile的最后一个数据块设置为BlockInfoUnderConstruction， 表明最后一个数据块正在构建中。 这里要注意处于构建状态的INodeFile除最后一个数据块为BlockUnderConstructionFeature外， 其他均为正常的BlockInfo。
当Datanode汇报当前数据块对应的构建中副本的状态为FINALIZED， 并且当前数据块的状态为COMMITTD， 且数据块的副本数目大于等于最小副本数目（最小副本数目默认为1） 时， Namenode会将当前数据块由BlockUnderConstructionFeature转变为BlockInfo， 并将数据块状态设置为COMPLETE。 这里需要注意， BlockInfoUnderConstrution还通过数据结构replicas记录了当前数据块对应的所有正在备份的副本的引用
/*** 当客户端对数据块进行追加写操作时会调用这个方法，** 它将一个BlockInfo对象转换为 BlockUnderConstructionFeature 对象，* 也就是将该BlockInfo对应的数据块状态变为了构建中状态** Add/Update the under construction feature.*/public void convertToBlockUnderConstruction(BlockUCState s,DatanodeStorageInfo[] targets) {if (isComplete()) {uc = new BlockUnderConstructionFeature(this, s, targets,this.getBlockType());} else {// the block is already under constructionuc.setBlockUCState(s);uc.setExpectedLocations(this, targets, this.getBlockType());}}
2.4.BlocksMap类
BlocksMap是Namenode上与数据块相关的最重要的类， 它管理着Namenode上数据块的元数据， 包括当前数据块属于哪个HDFS文件， 以及当前数据块保存在哪些Datanode上。 当Datanode启动时， 会对Datanode的本地磁盘进行扫描， 并将当前Datanode上保存的数据块信息汇报到Namenode。 Namenode收到Datanode的汇报信息后， 会建立数据块与保存这个数据块的数据节点的对应关系， 并将这个信息保存在BlocksMap中。 所以无论是获取某个数据块对应的HDFS文件， 还是获取数据块保存在哪些数据节点上， 都需要通BlocksMap对象.
详情: Hadoop3.2.1 【 HDFS 】源码分析 : BlocksMap解析
2.5. Replica类状态
在HDFS中还有两个比较重要的概念需要我们区分， 那就是数据块（block） 和副本（replica） 。 我们将Namenode中的数据块信息叫作数据块， 但是将Datanode中保存的数据块称之为副本。
HDFS定义的副本主要有5种状态。
| 序号 | 参数 | 描述 |
| 1 | FINALIZED | Datanode上的副本已完成写操作， 不再修改。 FINALIZED状态的副本使用FinalizedReplica类描述。 |
| 2 | RBW （ReplicaBeingWritten） | 刚刚被创建或者追加写的副本， 处于写操作的数据流管道中， 正在被写入， 且已写入副本的内容还是可读的。 RBW状态的副本使用ReplicaBeingWritten类描述 |
| 3 | RUR （ReplicaUnderRecovery） | 租约（Lease） 过期之后发生租约恢复和数据块恢复时副本所处的状态。 RUR状态的副本使用ReplicaUnderRecovery类描述。 |
| 4 | RWR（ReplicaWaitingToBeRecovered） | 如果一个Datanode挂掉并且重启之后，所有RBW状态的副本都将转换为RWR状态。 RWR状态的副本不会出现在数据流管道中， 结果就是等着进行租约恢复操作。 RWR状态的副本使用ReplicaWaitingToBeRecovered类描述 |
| 5 | TEMPORARY （ReplicaInPipeline） | Datanode之间传输副本（ 例如cluster rebalance） 时， 正在传输的副本就处于TEMPORARY状态。 和RBW状态的副本 不同的是， TEMPORARY状态的副本内容是不可读的， 如果Datanode重启， 会直 接删除处于TEMPORARY状态的副本。 TEMPORARY状态的副本使用ReplicaInPipeline类描述。 |
2.6.Block类状态
Namenode中的数据块有四种状态:
| 序号 | 参数 | 描述 |
| 1 | COMPLETE | 数据块的length（ 长度） 和gs（ 时间戳） 不再发生变化， 并且Namenode 已经收到至少一个Datanode报告有FINALIZED状态的副本（ replica）（ Datanode上的副本状态发生变化时会通过blockReceivedAndDeleted()方法向Namenode报告） 。 一个COMPLETE状态的数据块会在Namenode的内存中保存所有FINALIZED副本的位置。 只有当HDFS文件的所有数据块都处于COMPLETE状态时， 该HDFS文件才能被关闭。 |
| 2 | UNDER_CONSTRUCTION | 文件被创建或者进行追加写操作时， 正在被写入的数据块就处于UNDER_CONSTRUCTION状态。 处于该状态的数据块的长度（ length） 和时间戳（ gs） 都是可变的， 但是处于该状态的数据块对于读取操作来说是可见的。 |
| 3 | UNDER_RECOVERY | 如果一个文件的最后一个数据块处于UNDER_CONSTRUCTION状态时， 客户端异常退出， 该文件的租约（lease） 超过softLimit过期， 该数据块就需要进行租约恢复（Lease recovery） 和数据块恢复（Block recovery） 流程释放租约并关闭文件， 那么正在进行租约恢复和数据块 恢复流程的数据块就处于UNDER_RECOVERY状态。 |
| 4 | COMMITTED | 客户端在写文件时， 每次请求新的数据块（addBlock RPC请求）或者关闭文件时， 都会顺带对上一个数据块进行提交（commit） 操作（上一个数据块从UNDER_CONSTRUCTION状态转换成COMMITTED状态） 。 COMMITTED状态的数据块表明客户端已经把该数据块的所有数据都发送到了Datanode组成的数据流管道（pipeline） 中， 并且已经收到了下游的ACK响应，但是Namenode还没有收到任何一个Datanode汇报有FINALIZED副本。 |
三.数据块副本状态
Namenode通过BlocksMap ( Hadoop3.2.1 【 HDFS 】源码分析 : BlocksMap解析 ) 维护了数据块副本与数据节点之间的对应关系。 在HDFS运行时， 一个数据块副本可以存在很多不同的状态， 系统发生异常或者用户执行特定操作时都会对数据块副本状态产生影响 。
在HDFS源码中并没有使用一个枚举类给出数据块副本的状态定义以及状态之间的转移操作， 而是通过BlockManager中的数据结构、 不同的数据块副本类（例如BlockUnderConstruction和Block） 以及副本所在Datanode的状态（Datanode处于撤销状态） 来记录数据块副本的状态。
3.1.BlockManager数据结构
BlockManager类来管理和维护所有与数据块相关的操作。 先了解BlockManager中用于保存不同状态数据块副本的数据结构.
| 序号 | 集合 | 描述 |
| 1 | final CorruptReplicasMap corruptReplicas | 损坏的数据块副本集合 Datanode的数据块扫描器发现的错误的数据块副本会放入这个集合中 |
| 2 | final InvalidateBlocks invalidateBlocks | 等待删除的数据块副本集合 加入这个队列中的数据块副本会由Namenode通过名字节点指令向对应的Datanode下发删除指令。 |
| 3 | final Set<Block> postponedMisreplicatedBlocks | 推迟操作的数据块副本结合 当Namenode发生异常， 进行了Active与Standby切换时， 多余的副本不能立即删除， 需要先放入postponedMisreplicatedBlocks队列中， 直到这个数据块的所有副本所在的Datanode都进行了块汇报。 |
| 4 | final LowRedundancyBlocks neededReconstruction |
等待复制的数据块副本集合 |
代码:
/*** 损坏的数据块副本集合** Store blocks -> datanodedescriptor(s) map of corrupt replicas** corruptReplicas：* CorruptReplicasMap类的实例， 保存损坏的数据块副本（corruptReplica） ，* Datanode的数据块扫描器发现的错误的数据块副本会放入这个集合中。** CorruptReplicasMap保存的是损坏的数据块副本与保存这个副本的Datanode的对应关系（Block ->Datanode的映射关系） ，* 注意这里同时还保存了这个副本损坏的原因。* */final CorruptReplicasMap corruptReplicas = new CorruptReplicasMap();/*** 等待删除的数据块副本集合* Blocks to be invalidated.* For a striped block to invalidate, we should track its individual internal* blocks.** invalidateBlocks:* InvalidateBlocks类的实例， 保存等待删除的数据块副本。* 加入这个队列中的数据块副本会由Namenode通过名字节点指令向对应的Datanode下发删除指令。**/private final InvalidateBlocks invalidateBlocks;/**** 推迟操作的数据块副本结合** postponedMisreplicatedBlocks：** 当Namenode发生异常， 进行了Active与Standby切换时，多余的副本不能立即删除，* 需要先放入postponedMisreplicatedBlocks队列中，* 直到这个数据块的所有副本所在的Datanode都进行了块汇报。*** After a failover, over-replicated blocks may not be handled* until all of the replicas have done a block report to the* new active.** This is to make sure that this NameNode has been* notified of all block deletions that might have been pending* when the failover happened.**/private final Set<Block> postponedMisreplicatedBlocks = new LinkedHashSet<Block>();/**** 多余的数据块副本集合* Maps a StorageID to the set of blocks that are "extra" for this* DataNode. We'll eventually remove these extras.*/private final ExcessRedundancyMap excessRedundancyMap = new ExcessRedundancyMap();BlockManager的很多数据结构都没有简单地使用集合类， 而是重新定义了新的类作为容器。
3.2.CorruptReplicasMap类
CorruptReplicasMap类用于保存损坏的数据块副本（corruptReplica） 集合。
客户端发现损坏的数据块时会通过ClientProtocol.reportBadBlocks()方法向Namenode汇报损坏的数据块副本， 数据节点会通过DatanodeProtocol.reportBadBlocks()方法汇报损坏的数据块副本，之后BlockManager会将损坏的副本加入这个数据结构中。
CorruptReplicasMap保存的是损坏的数据块副本与保存这个副本的Datanode的对应关系（Block ->Datanode的映射关系） ， 注意这里同时还保存了这个副本损坏的原因[六种]。
| 序号 | 名称 | 描述 |
| 1 | NONE | 没有指明 |
| 2 | ANY | 未知原因 |
| 3 | GENSTAMP_MISMATCH | Datanode上副本的时间戳与Namenode上数据块的时间戳不一致 |
| 4 | SIZE_MISMATCH | Datanode上副本的大小与Namenode上数据块的大小不一致 |
| 5 | INVALID_STATE | 无效的状态 |
| 6 | CORRUPTION_REPORTED | client或datanode报告了损坏 |
直接看代码:
// CorruptReplicasMap底层的 HashMap 结构private final Map<Block, Map<DatanodeDescriptor, Reason>> corruptReplicasMap = new HashMap<Block, Map<DatanodeDescriptor, Reason>>();/*** 副本损坏的原因** The corruption reason code* */public enum Reason {// 没有指明NONE, // not specified.// 通配情况ANY, // wildcard reason// Datanode上副本的时间戳与Namenode上数据块的时间戳不一致GENSTAMP_MISMATCH, // mismatch in generation stamps// Datanode上副本的大小与Namenode上数据块的大小不一致SIZE_MISMATCH, // mismatch in sizes// 无效的状态INVALID_STATE, // invalid state// 客户端或者数据节点汇报CORRUPTION_REPORTED // client or datanode reported the corruption}
3.3.InvalidateBlocks类
InvalidateBlocks类用于保存等待删除的数据块副本集合。 它使用 HashMap 保存了Datanode（使用DatanodeInfo标识） 到该Datanode上所有等待删除的副本集合的映射。 这里使用LightWeightHashSet对象保存一个Datanode上所有等待删除的副本集合，LightWeightHashSet 是Hadoop定义的占用较少内存的Hashset的实现。
private final Map<DatanodeInfo, LightWeightHashSet<Block>> nodeToBlocks = new HashMap<>();private final Map<DatanodeInfo, LightWeightHashSet<Block>> nodeToECBlocks = new HashMap<>();private final LongAdder numBlocks = new LongAdder();private final LongAdder numECBlocks = new LongAdder();private final int blockInvalidateLimit;private final BlockIdManager blockIdManager;
BlockManager的ReplicationMonitor线程会定期执行删除操作， 每次删除时ReplicationMonitor线程都会从InvalidateBlocks中
选出nodeToProcess个Datanode执行删除操作， 然后再从每个Datanode上选出limit（由dfs.block.invalidate.limit配置项配置， 默认值为1000） 个副本删除。
我们直接看run方法, 里面核心的一共三个方法:
@Overridepublic void run() {while (namesystem.isRunning()) {try {// Process recovery work only when active NN is out of safe mode.if (isPopulatingReplQueues()) {//统计任务.computeDatanodeWork();//处理重试挂起任务processPendingReconstructions();// 删除那些已经不是stale状态的副本。rescanPostponedMisreplicatedBlocks();}TimeUnit.MILLISECONDS.sleep(redundancyRecheckIntervalMs);} catch (Throwable t) {if (!namesystem.isRunning()) {LOG.info("Stopping RedundancyMonitor.");if (!(t instanceof InterruptedException)) {LOG.info("RedundancyMonitor received an exception"+ " while shutting down.", t);}break;} else if (!checkNSRunning && t instanceof InterruptedException) {LOG.info("Stopping RedundancyMonitor for testing.");break;}LOG.error("RedundancyMonitor thread received Runtime exception. ",t);terminate(1, t);}}}这里我就不啰嗦了, 直接看代码,没兴趣的可以忽略掉.
记忆几个参数:
1.最多复制datanode节点数2倍的block. 为了防止网络阻塞. 最少会删除block所在的datanode的数量.
2.只有三分之一的datanode 会进行删除操作.
3.每个进行删除操作的Datanode最多可以删除blockInvalidateLimit [1000]个副本
/*** 计算 DataNode 节点上 块复制& 块失效的任务* DataNode 通过下次心跳的时候,被告知.*** ■ 复制操作： 从等待复制的数据块中选出若干个数据块执行复制操作， 然后为这些* 数据块的复制操作选出source源节点以及target目标节点， 最后构造复制指令并在* 下次心跳时将复制指令带回给源节点以执行复制操作。** ■ 删除操作： 从等待删除的数据块副本中选出若干个副本， 然后构造删除指令， 并* 在下次心跳时将删除指令带到目标节点以执行副本的删除操作。*** 对于数据块的复制操作，* 每次复制的数据块数量为集群中Datanode数量的blocksReplWorkMultiplier倍* （由配置项 dfs.namenode.replication.work.multiplier.per.iteration配置， 默认为2） 。** 例如集群中有100个 节点，* ReplicationMonitor在一个周期中只会从neededReplications集合中取出200 （2*100）* 个数据块进行复制操作。*** HDFS之所以这样设计， 是考虑到如果一次冗余复制过多的数据块，* 则会造成HDFS集群的网络拥塞， 所以需要根据Datanode的数量来决定进行复制操作的数据块的数量。*** 而对于数据块的删除操作， 每次进行删除操作的Datanode数量占集群中 Datanode数量的百分比为* blocksInvalidateWorkPct* （由配置项dfs.namenode.invalidate.work.pct.per.iteration配置， 默认为32%）** 而每个进行删除操作的Datanode最多可以删除blockInvalidateLimit个副本* （由配置项dfs.block.invalidate.limit配置， 默认为1000） 。** 例如集群中有100个节点， ReplicationMonitor在一个周期中只会从32个（100*0.32）* Datanode上删除数据块，* 而每个Datanode上最多可删除1000个数据块，* 也就是总共可以删除32000个数据块。*** Compute block replication and block invalidation work that can be scheduled* on data-nodes. The datanode will be informed of this work at the next* heartbeat.* * @return number of blocks scheduled for replication or removal.*/int computeDatanodeWork() {// Blocks should not be replicated or removed if in safe mode.// It's OK to check safe mode here w/o holding lock, in the worst// case extra replications will be scheduled, and these will get// fixed up later.// 在安全模式下, Block 不允许复制或者移除.//if (namesystem.isInSafeMode()) {return 0;}// 存活的 datanode 的数量final int numlive = heartbeatManager.getLiveDatanodeCount();// 可以进行复制的 blocks 的复制因子 , 默认: numlive * 2 ,// 即 最多复制datanode节点数2倍的block. 为了防止网络阻塞.final int blocksToProcess = numlive * this.blocksReplWorkMultiplier;// 进行删除时的阈值 numlive * 32% 即, 只有三分之一的datanode 会进行删除操作final int nodesToProcess = (int) Math.ceil(numlive * this.blocksInvalidateWorkPct);//调用computeReplicationWork()计算出需要进行备份的副本int workFound = this.computeBlockReconstructionWork(blocksToProcess);// Update countersnamesystem.writeLock();try {this.updateState();this.scheduledReplicationBlocksCount = workFound;} finally {namesystem.writeUnlock();}//调用computeInvalidateWork()计算出需要进行删除的副本workFound += this.computeInvalidateWork(nodesToProcess);return workFound;}
3.4.LowRedundancyBlocks
保存所有等待复制的数据块副本集合.它维护了一个优先级队列priorityQueues。 priorityQueues是一个列表， 它有5个子队列， 每一个队列对应一个优先级列表， 其中0为最高优先级， 5为最低优先级
private final List<LightWeightLinkedSet<BlockInfo>> priorityQueues = new ArrayList<>(LEVEL);| 序号 | 名称 | 描述 |
| 1 | QUEUE_HIGHEST_PRIORITY : 0 | 保存需要立刻备份的数据块。 这个数据块只有一个副本， 或者这个数据块没有活着的副本并且有一个拷贝所在的Datanode正处于离线中。 这种类型的数据块很有可能丢失 |
| 2 | QUEUE_VERY_LOW_REDUNDANCY : 1 | 保存副本数极低的数据块， 当实际副本数与期望副本数的比例小于1:3时， 加入这个队列。 |
| 3 | QUEUE_LOW_REDUNDANCY : 2 | 保存正处于备份中的数据块， 但该数据块的副本数并未达到优先级1队列中的比例 |
| 4 | QUEUE_REPLICAS_BADLY_DISTRIBUTED : 3 | 数据块的副本数量已经足够， 但是数据块副本的分布不是很好， 如果一个机架或者交换机宕机很有可能造成数据块完全丢失。 |
| 5 | QUEUE_WITH_CORRUPT_BLOCKS : 4 | 保存已经损坏的数据块， 就是该数据块对应的所有副本都损坏了。 这里的策略是将损坏的数据块放入这个队列中， 对没有损坏的副本给予更高的优先级 |
获取优先级代码:
/** Return the priority of a block* @param curReplicas current number of replicas of the block* @param expectedReplicas expected number of replicas of the block* @return the priority for the blocks, between 0 and ({@link #LEVEL}-1)*/private int getPriority(BlockInfo block,int curReplicas,int readOnlyReplicas,int outOfServiceReplicas,int expectedReplicas) {assert curReplicas >= 0 : "Negative replicas!";if (curReplicas >= expectedReplicas) {//数据块的副本数量足够， 但是没有均匀地分布在不同的机架上， 返回优先级3// Block has enough copies, but not enough racksreturn QUEUE_REPLICAS_BADLY_DISTRIBUTED;}if (block.isStriped()) {BlockInfoStriped sblk = (BlockInfoStriped) block;return getPriorityStriped(curReplicas, outOfServiceReplicas,sblk.getRealDataBlockNum(), sblk.getParityBlockNum());} else {return getPriorityContiguous(curReplicas, readOnlyReplicas,outOfServiceReplicas, expectedReplicas);}}private int getPriorityContiguous(int curReplicas, int readOnlyReplicas,int outOfServiceReplicas, int expectedReplicas) {if (curReplicas == 0) {// //当前数据块没有有效的副本， 并且有些副本所在的Datanode正处于离线中， 优先级 0// If there are zero non-decommissioned replicas but there are// some out of service replicas, then assign them highest priorityif (outOfServiceReplicas > 0) {return QUEUE_HIGHEST_PRIORITY;}if (readOnlyReplicas > 0) {// only has read-only replicas, highest risk// since the read-only replicas may go down all together.return QUEUE_HIGHEST_PRIORITY;}//all we have are corrupt blocks//当前数据块的所有副本都是损坏的， 优先级4return QUEUE_WITH_CORRUPT_BLOCKS;} else if (curReplicas == 1) {// only one replica, highest risk of loss highest priority//只有一个有效副本， 数据块可能随时丢失， 优先级0return QUEUE_HIGHEST_PRIORITY;} else if ((curReplicas * 3) < expectedReplicas) {//can only afford one replica loss this is considered very insufficiently redundant blocks.//当前副本数小于期望副本数的三分之一， 优先级1return QUEUE_VERY_LOW_REDUNDANCY;} else {//add to the normal queue for insufficiently redundant blocks//正常备份状态， 优先级2return QUEUE_LOW_REDUNDANCY;}}
参考:
Hadoop 2.X HDFS源码剖析 -- 徐鹏