HDFS QJM原理分析

前言

---

最近在重新研读HDFS QJM的细节实现，所谓“温故而知新”，感觉还是收获不少。之前笔者曾简单地翻译过HDFS QJM的设计文档，感兴趣的同学可以点此链接：HDFS QJM的架构设计。本文笔者打算挑选其中的一些细节要点，进程阐述。

背景

---

在HDFS QJM出现之前，editlog的一种推荐存储方式是基于NAS网络存储设备。这种方式会带来一些局限性：

• 对于特定硬件的要求。
• 部署操作的复杂性。

这么做的一个理由是它可以做到一定的高可用性。但是它的劣势是大于它所带来的好处的，于是社区提出了在软件层面来做这样的事，提出了以下3点基本要求：

• 没有特定硬件的要求。
• 软件层Fencing机理的实现。（Fencing的操作在这里是为了防止早些的writer对象进行写操作）。
• 无单点问题，所有editlog都是完全高可用的。

基于Quorum的管理方法

---

QJM的全称是Quorum Journal Manager，管理的节点为JournalNode，NameNode往这些JournalNode上读/写editlog信息。在每次的写操作过程中，这些信息会发送到所有的JournalNode节点中，关键的一点是，它并不需要要求所有节点成功的回复信息，只需要多数以上（这里指半数以上）的成功信息即可。这就是Quorum原理的核心所在。

Quorum Journal管理的主执行流程

---

QuorumJournalManager内部控制editlog的写入步骤如下：

1.停止之前的writer对象。当前写editlog的writer对象在写的时候，必须保证之前的writer对象没有在写editlog信息。
2.恢复上一次未写入完全的editlog信息内容。因为存在一种可能性，早期的writer对象存在写失败的可能性，造成各个JournalNode上写入的editlog的内容长度不同，这里需要做一个数据同步恢复。这点会在下文中具体分析到。
3.开始写入一个新的editlog数据片段。
4.写入editlog信息片段。
5.Finalize（确认）editlog信息成功写入。只要步骤4中的执行结果在多数JournalNode中为成功即可。

下面我们来看其中的2个关键步骤的细节实现。

Fencing Writers

---

这个步骤的目的，笔者已经阐述过，是为了防止早期的writer对象继续写入editlog信息，造成脏数据的写入。那么问题来了，QJM内部是如何实现这点的呢？答案如下。

每个writer对象变为活跃的时候，QJM为每个writer对象分配一个唯一的epoch数字，这个数字是单调递增的，在QJM的写入过程中，不允许epoch数字小于当前epoch数字的writer对象写入数据。

所以，从上面的内容来看，这里提到了一个重要的变量：epoch数字。我们可以简单理解为“迭代轮次”的概念，比如说第一轮，第二轮，第三轮。。
但是在每次epoch数字的迭代增加中，是有一番讲究的，里面会涉及到协商选择的，细节步骤如下：

a.首先QJM会发送一条请求消息（getJournalState()请求），去获取每个JournalNode上当前的epoch数字值。这个值在JournalNode上被保存在名为lastPromisedEpoch的变量里。
b.QJM收到所有JournalNode返回来的epoch数字后，取出其中的最大值，然后在此值上加1，以此作为新的epoch值。
c.QJM以新的epoch值为内容，向各JournalNode发送newEpoch请求，每个JournalNode收到此请求时，比较自身保存的epoch值（即本地lastPromisedEpoch变量），如果比此值大，则更新本地值。

本地epoch值更新后，会在每次的写操作中被用作其中的一个检测条件，代码如下：

private synchronized void checkRequest(RequestInfo reqInfo) throws IOException {
    // 判断当前请求信息的epoch值是否小于当前的epoch值，如果是则抛出异常
    if (reqInfo.getEpoch() < lastPromisedEpoch.get()) {
      throw new IOException("IPC's epoch " + reqInfo.getEpoch() +
          " is less than the last promised epoch " +
          lastPromisedEpoch.get());
    } else if (reqInfo.getEpoch() > lastPromisedEpoch.get()) {
      // 否则用新的epoch值更新当前epoch值
      updateLastPromisedEpoch(reqInfo.getEpoch());
    }
    ...
}

在这里，我们对照代码再来看看QJM（QuorumJournalManager类）内部新的epoch值的生成过程：

Map createNewUniqueEpoch()
      throws IOException {
    Preconditions.checkState(!loggers.isEpochEstablished(),
        "epoch already created");

    // 步骤1：向所有JournalNode发送getJournalState请求，获取它们的epoch值
    Map lastPromises =
      loggers.waitForWriteQuorum(loggers.getJournalState(),
          getJournalStateTimeoutMs, "getJournalState()");

    long maxPromised = Long.MIN_VALUE;
    // 步骤2：从这些epoch值中选出最大的值
    for (GetJournalStateResponseProto resp : lastPromises.values()) {
      maxPromised = Math.max(maxPromised, resp.getLastPromisedEpoch());
    }
    assert maxPromised >= 0;

    // 新的epoch值在最大的值基础上递增1
    long myEpoch = maxPromised + 1;
    // 步骤3：向JournalNode节点发送新的epoch值
    Map resps =
        loggers.waitForWriteQuorum(loggers.newEpoch(nsInfo, myEpoch),
            newEpochTimeoutMs, "newEpoch(" + myEpoch + ")");

    loggers.setEpoch(myEpoch);
    return resps;
}

异常/失败数据恢复

---

这部分小节内容即上面的步骤2。社区在这块可是做了相当详细的设计，毕竟数据失败，延时这类的情况在普通硬件中是极有可能发生的，所以我们要在软件层做这样的容错处理。

在QJM中，引入了lastWriterEpoch来保存最近一次writer写入对象的epoch值，定义如下：

/**
 * The epoch number of the last writer to actually write a transaction.
 * This is used to differentiate log segments after a crash at the very
 * beginning of a segment. See the the 'testNewerVersionOfSegmentWins'
 * test case.
 */
private PersistentLongFile lastWriterEpoch;

此变量在每次开始写入新的数据片段时会被更新，

public synchronized void startLogSegment(RequestInfo reqInfo, long txid,
      int layoutVersion) throws IOException {
    assert fjm != null;
    checkFormatted();
    checkRequest(reqInfo);

    ...

    long curLastWriterEpoch = lastWriterEpoch.get();
    // 更新当前最新writer值epoch值
    if (curLastWriterEpoch == reqInfo.getEpoch()) {
      LOG.info("Updating lastWriterEpoch from " + curLastWriterEpoch +
          " to " + reqInfo.getEpoch() + " for client " +
          Server.getRemoteIp());
      lastWriterEpoch.set(reqInfo.getEpoch());
    }

    ...
}

然后在每次的写操作中，会进行epoch值的检查，

private synchronized void checkWriteRequest(RequestInfo reqInfo) throws IOException {
    checkRequest(reqInfo);

    if (reqInfo.getEpoch() != lastWriterEpoch.get()) {
      throw new IOException("IPC's epoch " + reqInfo.getEpoch() +
          " is not the current writer epoch  " +
          lastWriterEpoch.get());
    }
}

重新回到本小节前面提到的失败情况，举个例子，比如一个JournalNode节点突然crash了，其上的editlog就会出现落后的情况，当它重新启动的时候，就会从其它正常节点上同步好数据。下面我们来看QJM内部是如何执行的，主要分为以下几步：

步骤1.决定哪个数据片段需要去恢复。这个步骤是紧接着newEpoch请求的，在向每个JournalNode节点发送newEpoch请求收到回复后，比较得出其中最大的数据片段id（事务ID），可意为写入的最新的数据段。
步骤2.向JournalNode发送PrepareRecovery RPC请求。PrepareRecovery请求是为了告诉JournalNode准备针对指定事务id，进行数据恢复。PrepareRecovery请求的返回信息为当前各个JournalNode上的给定事务id内容的信息。因为每个JournalNode上对于指定待恢复的数据片段，可能会存在数据内容不一致的情况。
步骤3.在获取针对给定事务id的数据片段信息后，QJM会针对各种情况对此选择一个理想的数据恢复源。
步骤4.QJM将需要同步的数据和数据源地址封装到AcceptRecovery RPC请求中，发送给各个JournalNode用于数据恢复。
步骤5.确认数据段恢复成功。

下面我们针对代码，对照上面的步骤实现：

public void recoverUnfinalizedSegments() throws IOException {
    Preconditions.checkState(!isActiveWriter, "already active writer");

    LOG.info("Starting recovery process for unclosed journal segments...");
    // 步骤1-1.发送newEpoch请求
    Map<AsyncLogger, NewEpochResponseProto> resps = createNewUniqueEpoch();
    LOG.info("Successfully started new epoch " + loggers.getEpoch());

    if (LOG.isDebugEnabled()) {
      LOG.debug("newEpoch(" + loggers.getEpoch() + ") responses:\n" +
        QuorumCall.mapToString(resps));
    }

    // 步骤1-2.从NewEpoch请求回复内容获取最大的txId，以此作为待恢复的数据片段
    long mostRecentSegmentTxId = Long.MIN_VALUE;
    for (NewEpochResponseProto r : resps.values()) {
      if (r.hasLastSegmentTxId()) {
        mostRecentSegmentTxId = Math.max(mostRecentSegmentTxId,
            r.getLastSegmentTxId());
      }
    }

    // On a completely fresh system, none of the journals have any
    // segments, so there's nothing to recover.
    if (mostRecentSegmentTxId != Long.MIN_VALUE) {
      // 开始进行数据片段的恢复
      recoverUnclosedSegment(mostRecentSegmentTxId);
    }
    isActiveWriter = true;
}

进入recoverUnclosedSegment方法，继续阅读接下来步骤的相关代码：

private void recoverUnclosedSegment(long segmentTxId) throws IOException {
    Preconditions.checkArgument(segmentTxId > 0);
    LOG.info("Beginning recovery of unclosed segment starting at txid " +
        segmentTxId);

    // 步骤2.发送PrepareRecovery请求
    QuorumCall prepare =
        loggers.prepareRecovery(segmentTxId);
    Map prepareResponses=
        loggers.waitForWriteQuorum(prepare, prepareRecoveryTimeoutMs,
            "prepareRecovery(" + segmentTxId + ")");
    LOG.info("Recovery prepare phase complete. Responses:\n" +
        QuorumCall.mapToString(prepareResponses));

    // 根据返回结果，选择其中最优的JournalNode上的数据为数据源，里面会涉及到各种情况的比较，
    // 具体比较逻辑在SegmentRecoveryComparator比较器中
    Entry bestEntry = Collections.max(
        prepareResponses.entrySet(), SegmentRecoveryComparator.INSTANCE); 
    AsyncLogger bestLogger = bestEntry.getKey();
    PrepareRecoveryResponseProto bestResponse = bestEntry.getValue();

    ...

    SegmentStateProto logToSync = bestResponse.getSegmentState();
    assert segmentTxId == logToSync.getStartTxId();

    // Sanity check: none of the loggers should be aware of a higher
    // txid than the txid we intend to truncate to
    for (Map.Entry e :
         prepareResponses.entrySet()) {
      AsyncLogger logger = e.getKey();
      PrepareRecoveryResponseProto resp = e.getValue();

      if (resp.hasLastCommittedTxId() &&
          resp.getLastCommittedTxId() > logToSync.getEndTxId()) {
        throw new AssertionError("Decided to synchronize log to " + logToSync +
            " but logger " + logger + " had seen txid " +
            resp.getLastCommittedTxId() + " committed");
      }
    }

    URL syncFromUrl = bestLogger.buildURLToFetchLogs(segmentTxId);

    // 步骤4.给定同步的地址，执行恢复操作
    QuorumCall accept = loggers.acceptRecovery(logToSync, syncFromUrl);
    loggers.waitForWriteQuorum(accept, acceptRecoveryTimeoutMs,
        "acceptRecovery(" + TextFormat.shortDebugString(logToSync) + ")");

    // 步骤5.确认数据的恢复
    QuorumCall finalize =
        loggers.finalizeLogSegment(logToSync.getStartTxId(), logToSync.getEndTxId()); 
    loggers.waitForWriteQuorum(finalize, finalizeSegmentTimeoutMs,
        String.format("finalizeLogSegment(%s-%s)",
            logToSync.getStartTxId(),
            logToSync.getEndTxId()));
}

以上就是对于HDFS QJM的简单分析，笔者只是选取了个人认为比较重要的部分，细节内容读者朋友可阅读QJM的设计文档。

参考资料

---

[1].https://issues.apache.org/jira/browse/HDFS-3077. Quorum-based protocol for reading and writing edit logs