HDFS源码-5 FairCallQueue

本文探讨了加权轮询调度机制,详细解释了如何通过分配不同权重来平衡多个队列间的读取频率,防止队列饥饿现象。以[9,4,1]为例,阐述了在满足最低读取次数的基础上,如何灵活应对竞争条件带来的额外读取需求。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.加权轮询调度
WeightedRoundRobinMultiplexer

/**
 * Determines which queue to start reading from, occasionally drawing from
 * low-priority queues in order to prevent starvation. Given the pull pattern
 * [9, 4, 1] for 3 queues:
 *
 * The cycle is (a minimum of) 9+4+1=14 reads.
 * Queue 0 is read (at least) 9 times
 * Queue 1 is read (at least) 4 times
 * Queue 2 is read (at least) 1 time
 * Repeat
 *
 * There may be more reads than the minimum due to race conditions. This is
 * allowed by design for performance reasons.
 */
 /**
  *确定从哪个队列开始读取,偶尔从中抽取
  *低优先级队列,以防止饥饿。 鉴于拉动模式
  * [9,4,1]为3个队列:
 *
  *周期是(最少)9 + 4 + 1 = 14次读数。
  *队列0被读取(至少)9次
  *队列1被读取(至少)4次
  *队列2被读取(至少)1次
  *重复
 *
  *由于竞争条件,可能会有比最小值更多的读数。 这是
  *出于性能原因,设计允许。
 */
第1章 HDFS 1 1.1 HDFS概述 1 1.1.1 HDFS体系结构 1 1.1.2 HDFS基本概念 2 1.2 HDFS通信协议 4 1.2.1 Hadoop RPC接口 4 1.2.2 流式接口 20 1.3 HDFS主要流程 22 1.3.1 HDFS客户端读流程 22 1.3.2 HDFS客户端写流程 24 1.3.3 HDFS客户端追加写流程 25 1.3.4 Datanode启动、心跳以及执行名字节点指令流程 26 1.3.5 HA切换流程 27 第2章 Hadoop RPC 29 2.1 概述 29 2.1.1 RPC框架概述 29 2.1.2 Hadoop RPC框架概述 30 2.2 Hadoop RPC的使用 36 2.2.1 Hadoop RPC使用概述 36 2.2.2 定义RPC协议 40 2.2.3 客户端获取Proxy对象 45 2.2.4 服务器获取Server对象 54 2.3 Hadoop RPC实现 63 2.3.1 RPC类实现 63 2.3.2 Client类实现 64 2.3.3 Server类实现 76 第3章 Namenode(名字节点) 88 3.1 文件系统树 88 3.1.1 INode相关类 89 3.1.2 Feature相关类 102 3.1.3 FSEditLog类 117 3.1.4 FSImage类 138 3.1.5 FSDirectory类 158 3.2 数据块管理 162 3.2.1 Block、Replica、BlocksMap 162 3.2.2 数据块副本状态 167 3.2.3 BlockManager类(done) 177 3.3 数据节点管理 211 3.3.1 DatanodeDescriptor 212 3.3.2 DatanodeStorageInfo 214 3.3.3 DatanodeManager 217 3.4 租约管理 233 3.4.1 LeaseManager.Lease 233 3.4.2 LeaseManager 234 3.5 缓存管理 246 3.5.1 缓存概念 247 3.5.2 缓存管理命令 247 3.5.3 HDFS集中式缓存架构 247 3.5.4 CacheManager类实现 248 3.55 CacheReplicationMonitor 250 3.6 ClientProtocol实现 251 3.6.1 创建文件 251 3.6.2 追加写文件 254 3.6.3 创建新的数据块 257 3.6.4 放弃数据块 265 3.6.5 关闭文件 266 3.7 Namenode的启动和停止 268 3.7.1 安全模式 268 3.7.2 HDFS High Availability 276 3.7.3 名字节点的启动 301 3.7.4 名字节点的停止 306 第4章 Datanode(数据节点) 307 4.1 Datanode逻辑结构 307 4.1.1 HDFS 1.X架构 307 4.1.2 HDFS Federation 308 4.1.3 Datanode逻辑结构 310 4.2 Datanode存储 312 4.2.1 Datanode升级机制 312 4.2.2 Datanode磁盘存储结构 315 4.2.3 DataStorage实现 317 4.3 文件系统数据集 334 4.3.1 Datanode上数据块副本的状态 335 4.3.2 BlockPoolSlice实现 335 4.3.3 FsVolumeImpl实现 342 4.3.4 FsVolumeList实现 345 4.3.5 FsDatasetImpl实现 348 4.4 BlockPoolManager 375 4.4.1 BPServiceActor实现 376 4.4.2 BPOfferService实现 389 4.4.3 BlockPoolManager实现 396 4.5 流式接口 398 4.5.1 DataTransferProtocol定义 398 4.5.2 Sender和Receiver 399 4.5.3 DataXceiverServer 403 4.5.4 DataXceiver 406 4.55 读数据 408 4.5.6 写数据(done) 423 4.5.7 数据块替换、数据块拷贝和读数据块校验 437 4.5.8 短路读操作 437 4.6 数据块扫描器 437 4.6.1 DataBlockScanner实现 438 4.6.2 BlockPoolSliceScanner实现 439 4.7 DirectoryScanner 442 4.8 DataNode类的实现 443 4.8.1 DataNode的启动 444 4.8.2 DataNode的关闭 446 第5HDFS客户端 447 5.1 DFSClient实现 447 5.1.1 构造方法 448 5.1.2 关闭方法 449 5.1.3 文件系统管理与配置方法 450 5.1.4 HDFS文件与操作方法 451 5.1.5 HDFS文件读写方法 452 5.2 文件读操作与输入流 452 5.2.1 打开文件 452 5.2.2 读操作――DFSInputStream实现 461 5.3 文件短路读操作 481 5.3.1 短路读共享内存 482 5.3.2 DataTransferProtocol 484 5.3.3 DFSClient短路读操作流程 488 5.3.4 Datanode短路读操作流程 509 5.4 文件写操作与输出流 512 5.4.1 创建文件 512 5.4.2 写操作――DFSOutputStream实现 516 5.4.3 追加写操作 543 5.4.4 租约相关 546 5.4.5 关闭输出流 548 55 HDFS常用工具 549 55.1 FsShell实现 550 55.2 DFSAdmin实现 552
<think>嗯,用户这次问的是HDFS HA中两个管理命令的区别,具体是hdfs haadmin -transitionToActive和hdfs haadmin -failover。从用户提供的引用材料来看,ta应该正在操作HA集群时遇到了状态切换问题,特别是看到引用[1]和[2]里forcemanual参数的警告信息后产生了困惑。 用户可能是个中级Hadoop运维人员,因为ta能准确指出命令差异这种技术细节。不过从ta引用多个操作失败记录来看,可能正在实际运维中遇到了NameNode切换障碍。需要特别注意引用[1]展示的split-brain(脑裂)风险警告,这是HA集群最危险的场景之一。 关于这两个命令的本质区别: - transitionToActive是直接修改NameNode状态的原子操作,类似硬切换。引用[4]提到启用自动故障转移时(dfs.ha.automatic-failover.enabled=true),必须用forcemanual覆盖保护机制,但正如引用[1]的红色警告所说,这可能引发命名空间损坏。 - 而failover则是通过ZKFC代理的标准流程,引用[5]提到的zkfc进程会协调这个操作。它模拟真实故障场景:先杀死active NN,再提升standby,整个过程符合Fencing机制。 用户可能没意识到,在启用ZKFC的集群里(引用[4]配置为true时),应该优先使用hdfs haadmin -failover。只有ZKFC完全失效时才考虑forcemanual,且必须确保另一NN已离线(如引用[3]的成功案例)。 需要强调风险层级:引用[2]的拒绝提示其实是保护机制,而引用[1]执行forcemanual后出现的nn2 is already active错误,就是典型脑裂前兆。这时候应该立即停止切换,检查ZKFC日志和网络分区问题。 最后生成的对比表里,特意把"适用场景"放在首列,因为用户最需要的是决策依据。补充的运维建议中,第一条检查ZKFC状态直接来自引用[5]的单独启动zkfc进程的操作经验。</think>在HDFS HA(高可用)架构中,`hdfs haadmin -transitionToActive --forcemanual` 和 `hdfs haadmin -failover` 是两种不同的NameNode状态切换机制,核心区别如下: | **特性** | `hdfs haadmin -transitionToActive --forcemanual` | `hdfs haadmin -failover` | |-------------------------|--------------------------------------------------------|--------------------------------------------------| | **工作机制** | 强制手动切换,绕过ZKFC和自动故障转移机制 | 通过ZKFC协调的标准故障转移流程 | | **安全性** | 高风险(可能引发脑裂)[^1][^2] | 安全(内置防护机制)[^3][^5] | | **适用场景** | ZKFC完全失效时的紧急恢复 | 日常维护或计划内切换 | | **依赖组件** | 不依赖ZooKeeper | 依赖ZooKeeper和ZKFC[^4][^5] | | **命令格式** | `hdfs haadmin -transitionToActive <serviceId> --forcemanual` | `hdfs haadmin -failover <active> <standby>` | | **是否验证目标状态** | 否(直接强制切换) | 是(先检查目标节点健康状态)[^5] | --- ### 详细说明: #### 1. **`hdfs haadmin -transitionToActive --forcemanual`** - **本质**:强制将指定NameNode标记为Active,**忽略所有防护机制** - **风险**: - 可能触发**脑裂(Split-Brain)**:若原Active NN未完全停止,两个NN同时处于Active状态会导致数据损坏[^1][^2] - 系统会明确警告:`WARN ha.HAAdmin: Proceeding with manual HA state management...`[^1] - **使用条件**: - 仅当自动故障转移(`dfs.ha.automatic-failover.enabled=true`)完全失效时 - **必须**确保另一个NameNode已停止(如通过`kill -9`) #### 2. **`hdfs haadmin -failover`** - **本质**:通过ZKFC(ZooKeeper Failover Controller)协调的安全切换 - **工作流程**: ```mermaid graph LR A[发起failover命令] --> B[ZKFC隔离原Active NN] B --> C[检查目标NN健康状态] C --> D[在ZooKeeper注册新Active] D --> E[切换完成] ``` - **安全保障**: - 通过ZooKeeper分布式锁(`/hadoop-ha/<nameservice>/ActiveStandbyElectorLock`)[^5]防止脑裂 - 自动执行Fencing机制(如SSH隔离原Active节点) --- ### 运维建议: 1. **优先使用安全故障转移** ```bash hdfs haadmin -failover nn1 nn2 # 从nn1安全切换到nn2 ``` 2. **强制切换仅作备用方案** ```bash # 先停止原Active NN进程 hdfs --daemon stop namenode # 再强制切换 hdfs haadmin -transitionToActive nn2 --forcemanual ``` 3. **切换后必做验证** ```bash hdfs haadmin -getAllServiceState # 检查双NN状态[^1][^3] hdfs dfsadmin -report # 确认DataNode连接正常[^5] ``` > ⚠️ **关键警告**: > 生产环境禁止直接使用`--forcemanual`,除非已**物理隔离**原Active节点(如断电或进程强杀)[^1][^2]。否则可能引发**元数据永久损坏**。 --- ### 相关问题 1. **如何避免HDFS HA场景中的脑裂问题?** 2. **ZKFC故障时如何诊断和恢复HDFS高可用?** 3. **HDFS手动故障转移的标准操作流程是什么?** 4. **为什么ZooKeeper在HDFS HA中至关重要?** 5. **强制切换NameNode后如何验证集群一致性?** [^1]: 强制切换的脑裂风险警告 [^2]: 自动故障转移启用时拒绝手动切换 [^3]: 安全切换的成功状态验证 [^4]: 自动故障转移配置项说明 [^5]: ZKFC与ZooKeeper的交互机制
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值