hdfs-zkfc原理分析

本文介绍了Hadoop中通过ZK实现FC功能的工具ZooKeeperFailoverController(zkfc)。阐述了其基本原理,包括功能、ZK特性及可提供的功能,还介绍了内部模块。同时说明了运行机制,如组件功能、选举过程,以及ZKFC在系统中的作用和线程模型。

目录:

1.基本原理

2.运行机制


一.基本原理:

1.1 简单介绍

ZooKeeperFailoverController :hadoop中通过ZK实现FC功能的一个实用工具。 
功能:作为一个ZK集群的客户端,用来监控NN的状态信息,每个运行NN的节点必须要运行一个zkfc 进程;

zk的基本特性: 
(1) 可靠存储小量数据且提供强一致性 
(2) ephemeral node(创建的锁节点), 在创建它的客户端关闭后,可以自动删除 
(3) 对于node状态的变化,可以提供异步的通知(watcher)

zk在zkfc中可以提供的功能: 
(1) Failure detector(通过watcher监听机制实现): 及时发现出故障的NN,并通知zkfc 
(2) Active node locator: 帮助客户端定位哪个是Active的NN 
(3) Mutual exclusion of active state(通过加锁): 保证某一时刻只有一个Active的NN

zkfc原理图:

1.2 内部模块(如图):

(1) ZKFailoverController(DFSZKFailoverController): 驱动整个ZKFC的运转,通过向HealthMonitor和ActiveStandbyElector注册回调函数的方式,subscribe HealthMonitor和ActiveStandbyElector的事件,并做相应的处理
(2) HealthMonitor: 定期check NN的健康状况,在NN健康状况发生变化时,通过回调函数把变化通知给ZKFailoverController
(3) ActiveStandbyElector: 管理NN在zookeeper上的状态,zookeeper上对应node的结点发生变化时,通过回调函数把变化通知给ZKFailoverController
(4) FailoverController: 提供做graceful failover的相关功能(dfs admin可以通过命令行工具手工发起failover)

 

二.运行机制

2.1 组件功能:

1.Health monitoring 
zkfc定期对本地的NN发起health-check的命令,如果NN正确返回,那么这个NN被认为是OK的。否则被认为是失效节点。

2.ZooKeeper Session Management 
当本地NN是健康的时候,zkfc将会在zk中持有一个session。如果本地NN又正好是active的,那么zkfc还有持有一个”ephemeral”的节点作为锁,一旦本地NN失效了,那么这个节点将会被自动删除。

3.ZooKeeper-based election 
如果本地NN是健康的,并且zkfc发现没有其他的NN持有那个独占锁。那么他将试图去获取该锁,一旦成功,那么它就需要执行Failover,然后成为active的NN节点。Failover的过程是:第一步,对之前的NN执行fence,如果需要的话。第二步,将本地NN转换到active状态。

另外: 
如果一个Active因HealthMonitor监控到状态异常,这里会作出判断,先通过Fencing功能关闭它(确保关闭或者不能提供服务),然后在ZK上删除它对应ZNode。

发送上述事件后,在另外一台机器上的ZKFC中的ActiveStandbyElector 会收到事件,并重新进行选举(尝试创建特定ZNode),它将获得成功并更改NN中状态,从而实现Active节点的变更。

 

2.2 运行机制

通常情况下Namenode和ZKFC布署在同一台物理机器上, HealthMonitor, FailoverController, ActiveStandbyElector在同一个JVM进程中(即ZKFC), Namenode是一个单独的JVM进程。ZKFC在整个系统中有几个重要的作用:
(1) Monitor and try to take active lock: 向zookeeper抢锁,抢锁成功的zkfc,指导对应的NN成为active的NN; watch锁对应的znode,当前active NN的状态发生变化导致失锁时,及时抢锁,努力成为active NN
(2) Monitor NN liveness and health: 定期检查对应NN的状态, 当NN状态发生变化时,及时通过ZKFC做相应的处理
(3) Fences other NN when needed: 当前NN要成为active NN时,需要fence其它的NN,不能同时有多个active NN

 

ZKFC的线程模型总体上来讲比较简单的,它主要包括三类线程,一是主线程;一是HealthMonitor线程; 一是zookeeper客户端的线程。它们的主要工作方式是:
(1) 主线程在启动所有的服务后就开始循环等待
(2) HealthMonitor是一个单独的线程,它定期向NN发包,检查NN的健康状况
(3) 当NN的状态发生变化时,HealthMonitor线程会回调ZKFailoverController注册进来的回调函数,通知ZKFailoverController NN的状态发生了变化
(4) ZKFailoverController收到通知后,会调用ActiveStandbyElector的API,来管理在zookeeper上的结点的状态
(5) ActiveStandbyElector会调用zookeeper客户端API监控zookeeper上结点的状态,发生变化时,回调ZKFailoverController的回调函数,通知ZKFailoverController,做出相应的变化

 

参考资料https://issues.apache.org/jira/secure/attachment/12521279/zkfc-design.pdf

<think>嗯,用户想要了解HDFS的源码分析。首先,我需要确定用户的具体需求。HDFS是Hadoop分布式文件系统的核心组件,源码分析可能涉及到架构、关键模块、读写流程等方面。用户可能是开发者或者系统管理员,希望深入理解HDFS的内部机制,以便优化或解决问题。 用户可能已经有一定的HDFS使用经验,但缺乏对源码的了解。他们可能想了解如何入手分析源码,或者重点模块在哪里。需要确保回答结构清晰,分步骤引导,同时遵循系统级指令中的格式要求,比如正确使用LaTeX。 首先,我应该介绍HDFS的基本架构,帮助用户建立整体认识。然后分模块讲解,比如NameNode、DataNode、客户端通信等。每个部分需要说明源码的位置和关键类,例如NameNode的启动流程涉及的类。 接下来,可能需要详细说明读写流程,包括源码中的关键方法,如create()和read()。这部分要结合具体的包和类,帮助用户定位代码位置。另外,元数据管理和持久化也是重点,比如FsImage和EditLog的处理。 通信机制部分,RPC和流式接口是HDFS的核心,需要提到相关的接口和实现类,如ClientProtocol和DataTransferProtocol。故障恢复与高可用部分,可以介绍主从切换和日志恢复机制,比如ZKFC和EditLogTailer。 最后,提供一些源码分析的建议,比如调试环境搭建和关键断点设置。还要注意提醒用户参考官方文档和社区资源,确保信息的准确性。 需要检查LaTeX格式是否正确,所有行内公式用$...$,独立公式用$$...$$,但根据内容来看,可能数学公式较少,但如果有示例的话需要正确应用。同时保持语言口语化,避免使用Markdown格式,分步骤和模块时用序号和标题清晰标明。</think>以下是对HDFS源码分析的层次化解析,结合架构设计与关键模块实现原理: #### 一、HDFS架构核心 1. **模块划分** - `NameNode`:元数据管理(`FSDirectory`类记录目录树,`INode`描述文件/目录元数据) - `DataNode`:数据块存储(`BlockScanner`实现周期性校验) - `JournalNode`:高可用日志同步(基于Paxos算法) - 通信协议:RPC接口(`ClientProtocol`)与流式接口(`DataTransferProtocol`) 2. **源码目录结构** - 主入口:`hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs` - 关键子包: - `server/namenode`:NameNode核心逻辑 - `server/datanode`:DataNode实现 - `protocol`:RPC协议定义 - `client`:HDFS客户端 #### 二、关键流程源码分析 1. **写文件流程**(`DFSOutputStream`类) ```java // 创建数据流管道 List<DatanodeInfo> targets = namenode.addBlock(...); // 数据分包传输 packet.writeTo(streamer); // 应答确认 waitForAckedSeqno(seqno); ``` 2. **读文件流程**(`DFSInputStream`类) - 通过`getBlockLocations()`获取块位置 - 采用短路读优化(`ShortCircuitLocalRead`) 3. **元数据持久化** - `FsImage`序列化格式:使用Protobuf(`NSection$NameSystemSection`) - EditLog合并:`Checkpointer`线程定期执行 #### 三、高可用实现 1. **主从切换机制** - `ZKFC`通过ZooKeeper监控健康状态 - 脑裂防护:`QJM`基于quorum journal实现 2. **日志同步流程** ```java // JournalNode处理日志写入 public void journal(RequestInfo reqInfo, long segmentTxId...) throws IOException { validateRequest(reqInfo); log.write(op); } ``` #### 四、性能优化点 1. **内存管理** - NameNode堆外内存:`OffHeapINodeMap`减少GC压力 - 块报告合并:`BPServiceActor`实现增量报告 2. **网络优化** - 零拷贝传输:`transferTo()`实现DMA直接内存访问 - 管道化写入:`Packet`队列异步发送 #### 五、调试建议 1. 搭建源码环境: ```shell mvn install -DskipTests -Pdist,native ``` 2. 关键断点设置: - NameNode启动:`NameNode.loadNamesystem()` - 块分配:`BlockManager.addBlock()` 建议配合官方JIRA(HDFS-XXX编号问题)和《Hadoop技术内幕》系列书籍进行扩展研究,重点关注HDFS-3.x版本引入的EC纠删码和Router-Based Federation实现。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值