HDFS namenode 写edit log原理以及源码分析
这篇分析一下namenode 写edit log的过程。
关于namenode日志,集群做了如下配置
<property>
<name>dfs.nameservices</name>
<value>sync</value>
<description>Logical name for this new nameservice</description>
</property>
<property>
<name>dfs.namenode.name.dir</name>
<value>file://home/wudi/hadoop/nn</value>
</property>
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://host1:port1;host2:port2;host3:port3/sync</value>
</property>
这个配置是说namenode写edit log需要往两个地方写，第一个是/home/wudi/hadoop/nn,namenode本地文件系统,另外一个qjournal,这是一个共享的edit log directory,namenode往多个JournalNode写edit log，namenode作为Paxos中的Proposer，JournalNode作为Acceptor，保证多点写时也能对edit log达成一致。实际上，我的集群上起了3个JournalNode进程。
总体来说，namenode多线程写edit log，edit log维护双buffer，一个用于填充数据，另外一个用于flush。往buffer中写edit log需要事先加锁，写完后检查如果buffer中数据大小达到阈值，则进行sync,将buffer真正写出. 或者，线程主动调用sync，主动将buffer写出去.sync时，也要加锁，和往buffer中写edit log是同一把锁，拿住锁后，切buffer，然后解锁，在锁外面将buffer写出去。在我的配置中，需要写两个地方，一个是namenode本地的存edit log的目录file://home/wudi/hadoop/nn，另外一个是qjournal，往三个JournalNode进程并行写.
下面看看代码：
FSEditLog的初始化
FSEditLog(Configuration conf, NNStorage storage, List<URI> editsDirs) {
isSyncRunning = false;
this.conf = conf;
this.storage = storage;
metrics = NameNode.getNameNodeMetrics();
lastPrintTime = now();
// If this list is empty, an error will be thrown on first use
// of the editlog, as no journals will exist
this.editsDirs = Lists.newArrayList(editsDirs);
this.sharedEditsDirs = FSNamesystem.getSharedEditsDirs(conf);
}
this.editsDirs就是配置项dfs.namenode.name.dir和dfs.namenode.shared.edits.dir的
和.
this.sharedEditsDirs是配置项dfs.namenode.shared.edits.dir
private synchronized void initJournals(List<URI> dirs) {
int minimumRedundantJournals = conf.getInt(
DFSConfigKeys.DFS_NAMENODE_EDITS_DIR_MINIMUM_KEY,
DFSConfigKeys.DFS_NAMENODE_EDITS_DIR_MINIMUM_DEFAULT);
journalSet = new JournalSet(minimumRedundantJournals);
for (URI u : dirs) {
boolean required =FSNamesystem.getRequiredNamespaceEditsDirs(conf)
.contains(u);
if (u.getScheme().equals(NNStorage.LOCAL_URI_SCHEME)) {
StorageDirectory sd = storage.getStorageDirectory(u);
if (sd != null) {
journalSet.add(new FileJournalManager(conf, sd, storage),
required, sharedEditsDirs.contains(u));
}
} else {
journalSet.add(createJournal(u), required,
sharedEditsDirs.contains(u));
}
}
if (journalSet.isEmpty()) {
LOG.error("No edits directories configured!");
}
}
传进来的是this.editsDirs,一个是本地edit log目录，另外一个是qjournal,JournalSet用来管理多个edit log directory，包括本地的和共享的,那么在我的集群配置下,journalSet里面有两个JournalAndStream对象。JournalAndStream对象包装了具体的edit log输出流和具体的管理流的manager。对于qjournal来说，manager是QuorumJournalManager，对于本地目录来说，manager是FileJournalManager.不同的manager 使用不同的edit log输出流，每一种具体的输出流都继承自EditLogOutputStream这个基类.每次切换edit log segment时，会调用manager的startLogSegment方法来生成一个新的输出流。对于QuorumJournalManager来说，输出流是QuorumOutputStream，对于FileJournalManager来说，输出流是EditLogFileOutputStream.用户可以实现自己的manager，通过配置参数dfs.namenode.edits.journal-plugin.qjournal。上层FSEditLog调用startLogSegment切换一个edit log segment时，调用的是JournalSet的startLogSegment，它会调用它所包含的manager的startLogSegment，这样就产生出了两个输出流。
下面看看写edit log
一般来说，namenode写edit log的函数调用顺序是先调void logEdit(final FSEditLogOp op)然后调用public void logSync(),这种方式主要是为了做batch，提高吞吐.logEdit往buffer里写，logSync在真正flush.
先看FSEditLog的logEdit:
void logEdit(final FSEditLogOp op) {
synchronized (this) {
assert isOpenForWrite() :
"bad state: " + state;
// wait if an automatic sync is scheduled
waitIfAutoSyncScheduled();
long start = beginTransaction();
op.setTransactionId(txid);
try {
editLogStream.write(op);
} catch (IOException ex) {
// All journals failed, it is handled in logSync.
}
endTransaction(start);
// check if it is time to schedule an automatic sync
if (!shouldForceSync()) {
return;
}
isAutoSyncScheduled = true;
}
// sync buffered edit log entries to persistent store
logSync();
}
首先，会检查是否sync操作已经被别人调度了(检查isAutoSyncScheduled变量)，如果是，说明别的线程即将进行sync操作，则该线程wait，别的线程将buffer切换好后，调用doneWithAutoSyncScheduling将isAutoSyncScheduled置为false，然后将其他等待的线程唤醒. 接着，为edit log分配一个transaction id，id从全局分配器txid分配，以1递增，获得的transaction id保存在线程私有变量中，然后将op写入QuorumOutputStream和EditLogFileOutputStream的buffer中.接着调用shouldForceSync()这个方法会检查每个流的shouldForceSync()，只要有一个返回true,就返回true，意思是buffer够大了，攒的差不多了，该sync一次了，接着就调度一次sync将isAutoSyncScheduled置为true.然后调logSync().QuorumOutputStream这个流永远返回false,EditLogFileOutputStream发现buffer中数据超过512KB(不可配置)，则返回true.如果buffer不满512KB，logEdit()会直接返回，不进行logSync,可以看到这里对log进行了batch。
下面看logSync()
public void logSync() {
long syncStart = 0;
// Fetch the transactionId of this thread.
long mytxid = myTransactionId.get().txid;
boolean sync = false;
try {
EditLogOutputStream logStream = null;
synchronized (this) {
try {
printStatistics(false);
// if somebody is already syncing, then wait
while (mytxid > synctxid && isSyncRunning) {
try {
wait(1000);
} catch (InterruptedException ie) {
}
}
//
// If this transaction was already flushed, then nothing to do
//
if (mytxid <= synctxid) {
numTransactionsBatchedInSync++;
if (metrics != null) {
// Metrics is non-null only when used inside name node
metrics.incrTransactionsBatchedInSync();
}
return;
}
// now, this thread will do the sync
syncStart = txid;
isSyncRunning = true;
sync = true;
// swap buffers
try {
if (journalSet.isEmpty()) {
throw new IOException("No journals available to flush");
}
editLogStream.setReadyToFlush();
} catch (IOException e) {
final String msg =
"Could not sync enough journals to persistent storage " +
"due to " + e.getMessage() + ". " +
"Unsynced transactions: " + (txid - synctxid);
LOG.fatal(msg, new Exception());
IOUtils.cleanup(LOG, journalSet);
terminate(1, msg);
}
} finally {
// Prevent RuntimeException from blocking other log edit write
doneWithAutoSyncScheduling();
}
//editLogStream may become null,
//so store a local variable for flush.
logStream = editLogStream;
}
// do the sync
long start = now();
try {
if (logStream != null) {
logStream.flush();
}
} catch (IOException ex) {
synchronized (this) {
final String msg =
"Could not sync enough journals to persistent storage. "
+ "Unsynced transactions: " + (txid - synctxid);
LOG.fatal(msg, new Exception());
IOUtils.cleanup(LOG, journalSet);
terminate(1, msg);
}
}
long elapsed = now() - start;
if (metrics != null) { // Metrics non-null only when used inside name node
metrics.addSync(elapsed);
}
} finally {
// Prevent RuntimeException from blocking other log edit sync
synchronized (this) {
if (sync) {
synctxid = syncStart;
isSyncRunning = false;
}
this.notifyAll();
}
}
}
首先，检查是不是别的线程正在做sync(isSyncRunning)，如果别的线程正在做并且当前edit log的mytxid大于到目前位置已经sync的最大的synctxid，那么等待。别的线程sync完成后会更新synctxid，并且isSyncRunning置为false，然后唤醒这个线程。线程醒来后，检查是否自己的mytxid对应的edit log已经被sync了，如果是，返回。否则，开始做sync，将isSyncRunning置为true告诉别的线程。然后调用setReadyToFlush切换buffer，调用doneWithAutoSyncScheduling允许别的线程往buffer中写数据。然后进行实际的flush。最后更新synctxid并置isSyncRunning置为false，然后唤醒其他线程.
结束.
参考资料
hadoop-hdfs-2.4.1.jar
