我们知道,HDFS全称是Hadoop Distribute FileSystem,即Hadoop分布式文件系统。既然它是一个分布式文件系统,那么肯定存在很多物理节点,而这其中,就会有主从节点之分。在HDFS中,主节点是名字节点NameNode,它负责存储整个HDFS中文件元数据信息,保存了名字节点第一关系和名字节点第二关系。名字节点第一关系是文件与数据块的对应关系,在HDFS正常运行期间,保存在NameNode内存和FSImage文件中,并且在NameNode启动时就由FSImage加载,之后的修改则保持在内容和FSEdit日志文件中,而第二关系则是数据块与数据节点的对应关系,它并非由名字节点的FSImage加载而来,而是在从节点DataNode接入集群后,由其发送心跳信息汇报给主节点NameNode。
那么,何为心跳呢?心跳就是HDFS中从节点DataNode周期性的向名字节点DataNode做汇报,汇报自己的健康情况、负载状况等,并从NameNode处领取命令在本节点执行,保证NameNode这一HDFS指挥官熟悉HDFS的全部运行情况,并对从节点DataNode发号施令,以完成来自外部的数据读写请求或内部的负载均衡等任务。
我们知道,Hadoop2.x版本中,做了两个比较大的改动:一是引入了联邦的概念,允许一个HDFS集群提供多个命名空间服务,第二个是利用HA解决了NameNode单点故障问题,引入了Active NN和Standby NN的概念。
本篇文章,结合Hadoop2.6.0的源码,我们先来看下心跳汇报的整体结构。
众所周知,心跳汇报是从节点DataNode主动发起的周期性向主节点NameNode汇报的一个动作,所以这个问题的突破口自然而然就落在了数据节点DataNode上了。在DataNode内部,有这么一个成员变量blockPoolManager,定义如下:
// 每个DataNode上都有一个BlockPoolManager实例
private BlockPoolManager blockPoolManager;
它是每个DataNode上都会存在的BlockPoolManager实例。那么这个BlockPoolManager是什么呢?看下它的定义及成员变量就知道了,代码如下:
/**
* Manages the BPOfferService objects for the data node.
* Creation, removal, starting, stopping, shutdown on BPOfferService
* objects must be done via APIs in this class.
*
* 为DataNode节点管理BPOfferService对象。
* 对于BPOfferService对象的创建、移除、启动、停止等操作必须通过该类的api来完成。
*/
@InterfaceAudience.Private
class BlockPoolManager {
private static final Log LOG = DataNode.LOG;
// NameserviceId与BPOfferService的对应关系
private final Map<String, BPOfferService> bpByNameserviceId =
Maps.newHashMap();
// BlockPoolId与BPOfferService的对应关系
private final Map<String, BPOfferService> bpByBlockPoolId =
Maps.newHashMap();
// 所有的BPOfferService
private final List<BPOfferService> offerServices =
Lists.newArrayList();
// DataNode实例dn
private final DataNode dn;
//This lock is used only to ensure exclusion of refreshNamenodes
// 这个refreshNamenodesLock仅仅在refreshNamenodes()方法中被用作互斥锁
private final Object refreshNamenodesLock = new Object();
// 构造函数
BlockPoolManager(DataNode dn) {
this.dn = dn;
}
}
由类的注释我们可以知道,BlockPoolManager为DataNode节点管理BPOfferService对象。对于BPOfferService对象的创建、移除、启动、停止等操作必须通过类BlockPoolManager的API来完成。而且,BlockPoolManager中主要包含如下几个数据结构:
1、保存nameserviceId与BPOfferService的对应关系的HashMap:bpByNameserviceId;
2、保存blockPoolId与BPOfferService的对应关系的HashMap:bpByBlockPoolId;
3、保存所有BPOfferService的ArrayList:offerServices;
4、DataNode实例dn;
5、refreshNamenodes()方法中用于线程间同步或互斥锁的Object:refreshNamenodesLock。
由前三个成员变量,我们可以清楚的知道,BlockPoolManager主要维护的就是该DataNode上的BPOfferService对象,及其所属nameserviceId、blockPoolId。nameserviceId我们可以理解为HDFS集群中某一特定命名服务空间的唯一标识,blockPoolId则对应为该命名服务空间中的一个块池,或者说一组数据块的唯一标识,那么,什么是BPOfferService呢?我们继续往下看BPOfferService的源码,看下它类的定义及其成员变量,代码如下:
/**
* One instance per block-pool/namespace on the DN, which handles the
* heartbeats to the active and standby NNs for that namespace.
* This class manages an instance of {@link BPServiceActor} for each NN,
* and delegates calls to both NNs.
* It also maintains the state about which of the NNs is considered active.
*
* DataNode上每个块池或命名空间对应的一个实例,它处理该命名空间到对应活跃或备份状态NameNode的心跳。
* 这个类管理每个NameNode的一个BPServiceActor实例,在两个NanmeNode之间调用。
* 它也保存了哪个NameNode是active状态。
*/
@InterfaceAudience.Private
class BPOfferService {
static final Log LOG = DataNode.LOG;
/**
* Information about the namespace that this service
* is registering with. This is assigned after
* the first phase of the handshake.
*
* 该服务登记的命名空间信息。第一阶段握手即被分配。
* NamespaceInfo中有个blockPoolID变量,显示了NameSpace与blockPool是一对一的关系
*/
NamespaceInfo bpNSInfo;
/**
* The registration information for this block pool.
* This is assigned after the second phase of the
* handshake.
*
* 块池的注册信息,在第二阶段握手被分配
*/
volatile DatanodeRegistration bpRegistration;
/**
* 服务所在DataNode节点
*/
private final DataNode dn;
/**
* A reference to the BPServiceActor associated with the currently
* ACTIVE NN. In the case that all NameNodes are in STANDBY mode,
* this can be null. If non-null, this must always refer to a member
* of the {@link #bpServices} list.
*
* 与当前活跃NameNode相关的BPServiceActor引用
*/
private BPServiceActor bpServiceToActive = null;
/**
* The list of all actors for namenodes in this nameservice, regardless
* of their active or standby states.
* 该命名服务对应的所有NameNode的BPServiceActor实例列表,不管NameNode是活跃的还是备份的
*/
private final List<BPServiceActor> bpServices =
new CopyOnWriteArrayList<BPServiceActor>();
/**
* Each time we receive a heartbeat from a NN claiming to be ACTIVE,
* we record that NN's most recent transaction ID here, so long as it
* is more recent than the previous value. This allows us to detect
* split-brain scenarios in which a prior NN is still asserting its
* ACTIVE state but with a too-low transaction ID. See HDFS-2627
* for details.
*
* 每次我们接收到一个NameNode要求成为活跃的心跳,都会在这里记录那个NameNode最近的事务ID,只要它
* 比之前的那个值大。这要求我们去检测裂脑的情景,比如一个之前的NameNode主张保持着活跃状态,但还是使用了较低的事务ID。
*/
private long lastActiveClaimTxId = -1;
// 读写锁mReadWriteLock
private final ReentrantReadWriteLock mReadWriteLock =
new ReentrantReadWriteLock();
// mReadWriteLock上的读锁mReadLock
private final Lock mReadLock = mReadWriteLock.readLock();
// mReadWriteLock上的写锁mWriteLock
private final Lock mWriteLock = mReadWriteLock.writeLock();
// utility methods to acquire and release read lock and write lock
void readLock() {
mReadLock.lock();
}
void readUnlock() {
mReadLock.unlock();
}
void writeLock() {
mWriteLock.lock();
}
void writeUnlock() {
mWriteLock.unlock();
}
BPOfferService(List<InetSocketAddress> nnAddrs, DataNode dn) {
Preconditions.checkArgument(!nnAddrs.isEmpty(),
"Must pass at least one NN.");
this.dn = dn;
// 每个namenode一个BPServiceActor
for (InetSocketAddress addr : nnAddrs) {
this.bpServices.add(new BPServiceActor(addr, this));
}
}
}
由上述代码我们可以得知,BPOfferService为DataNode上每个块池或命名空间对应的一个实例,它处理该命名空间到对应活跃或备份状态NameNode的心跳。这个类管理每个NameNode的一个BPServiceActor实例,同时它也保存了哪个NameNode是active状态。撇开其他成员变量先不说,该类有两个十分重要的成员变量,分别是:
1、bpServiceToActive:BPServiceActor类型的,表示与当前活跃NameNode相关的BPServiceActor引用;
2、bpServices:CopyOnWriteArrayList<BPServiceActor>类型的列表,表示该命名服务对应的所有NameNode的BPServiceActor实例列表,不管NameNode是活跃的还是备份的。
由此可以看出,BPOfferService实际上是每个命名服务空间所对应的一组BPServiceActor的管理者,这些BPServiceActor全部存储在bpServices列表中,并且由bpServices表示当前与active NN连接的BPServiceActor对象的引用,而bpServices对应的则是连接到所有NN的BPServiceActor,无论这个NN是active状态还是standby状态。那么,问题又来了?BPServiceActor是什么呢?继续吧!
/**
* A thread per active or standby namenode to perform:
* <ul>
* <li> Pre-registration handshake with namenode</li>
* <li> Registration with namenode</li>
* <li> Send periodic heartbeats to the namenode</li>
* <li> Handle commands received from the namenode</li>
* </ul>
*
* 每个活跃active或备份standby状态NameNode对应的线程,它负责完成以下操作:
* 1、与NameNode进行预登记握手;
* 2、在NameNode上注册;
* 3、发送周期性的心跳给NameNode;
* 4、处理从NameNode接收到的请求。
*/
@InterfaceAudience.Private
// 实现Runnable接口意味着BPServiceActor是一个线程
class BPServiceActor implements Runnable {
static final Log LOG = DataNode.LOG;
// NameNode地址
final InetSocketAddress nnAddr;
// HA服务状态
HAServiceState state;
// BPServiceActor线程所属BPOfferService
final BPOfferService bpos;
// lastBlockReport, lastDeletedReport and lastHeartbeat may be assigned/read
// by testing threads (through BPServiceActor#triggerXXX), while also
// assigned/read by the actor thread. Thus they should be declared as volatile
// to make sure the "happens-before" consistency.
volatile long lastBlockReport = 0;
volatile long lastDeletedReport = 0;
boolean resetBlockReportTime = true;
volatile long lastCacheReport = 0;
Thread bpThread;
DatanodeProtocolClientSideTranslatorPB bpNamenode;
private volatile long lastHeartbeat = 0;
/**
* 枚举类,运行状态,包括
* CONNECTING 正在连接
* INIT_FAILED 初始化失败
* RUNNING 正在运行
* EXITED 已退出
* FAILED 已失败
*/
static enum RunningState {
CONNECTING, INIT_FAILED, RUNNING, EXITED, FAILED;
}
// 运行状态runningState默认为枚举类RunningState的CONNECTING,表示正在连接
private volatile RunningState runningState = RunningState.CONNECTING;
/**
* Between block reports (which happen on the order of once an hour) the
* DN reports smaller incremental changes to its block list. This map,
* keyed by block ID, contains the pending changes which have yet to be
* reported to the NN. Access should be synchronized on this object.
*
*
*/
private final Map<DatanodeStorage, PerStoragePendingIncrementalBR>
pendingIncrementalBRperStorage = Maps.newHashMap();
// IBR = Incremental Block Report. If this flag is set then an IBR will be
// sent immediately by the actor thread without waiting for the IBR timer
// to elapse.
private volatile boolean sendImmediateIBR = false;
private volatile boolean shouldServiceRun = true;
private final DataNode dn;
private final DNConf dnConf;
private DatanodeRegistration bpRegistration;
// 构造方法,BPServiceActor被创建时就已明确知道NameNode地址InetSocketAddress类型的nnAddr,和BPOfferService类型的bpos
BPServiceActor(InetSocketAddress nnAddr, BPOfferService bpos) {
this.bpos = bpos;
this.dn = bpos.getDataNode();
this.nnAddr = nnAddr;
this.dnConf = dn.getDnConf();
}
}
聪明的您,是不是一眼就能看出,BPServiceActor就是实际与某个特定NameNode通信的工作线程呢?它是每个活跃active或备份standby状态NameNode对应的线程,它负责完成以下操作:
1、与NameNode进行预登记握手;
2、在NameNode上注册;
3、发送周期性的心跳给NameNode;
4、处理从NameNode接收到的请求。
关于BPServiceActor的具体实现,我们放到以后再讲,下面我们再折回去,稍微总结下HDFS心跳的整体架构,忽略掉部分细节后,大体架构如图所示:
首先,每个DataNode上都有一个BlockPoolManager实例;
其次,每个BlockPoolManager实例管理着所有命名服务空间对应的BPOfferService实例:命名服务空间你可以理解为HDFS中逻辑意义上的某个单独的文件系统;
然后,每个BPOfferService实例则管理者它所对应命名服务空间内到所有NameNode的BPServiceActor工作线程:包含一个Active与若干Standby状态的NN;
最后,BPServiceActor对应的是针对特定的NameNode进行通讯和完成心跳与接收响应命令的工作线程。
上述就是HDFS中心跳汇报的整体结构,由DataNode上BlockPoolManager、BPOfferService和BPServiceActor等三层架构实现,由上到下体现了HDFS中存在多个命名服务空间NameService,每个命名服务空间NameService对应着一个BPOfferService,它负责管理多个BPServiceActor工作线程,每个BPServiceActor则是DataNode上具体与每个NameNode通信完成心跳的工作线程,而这些对应关系,特别是HDFS上有多少命名服务NS,每个命名服务涉及哪些名字节点NN,则是从HDFS的配置文件中获取的。
关于HDFS中心跳涉及的数据结构如何初始化,我们下节再讲!