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<AsyncLogger, NewEpochResponseProto> createNewUniqueEpoch()
      throws IOException {
    Preconditions.checkState(!loggers.isEpochEstablished(),
        "epoch already created");

    // 步骤1:向所有JournalNode发送getJournalState请求,获取它们的epoch值
    Map<AsyncLogger, GetJournalStateResponseProto> 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<AsyncLogger, NewEpochResponseProto> 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<AsyncLogger,PrepareRecoveryResponseProto> prepare =
        loggers.prepareRecovery(segmentTxId);
    Map<AsyncLogger, PrepareRecoveryResponseProto> prepareResponses=
        loggers.waitForWriteQuorum(prepare, prepareRecoveryTimeoutMs,
            "prepareRecovery(" + segmentTxId + ")");
    LOG.info("Recovery prepare phase complete. Responses:\n" +
        QuorumCall.mapToString(prepareResponses));

    // 根据返回结果,选择其中最优的JournalNode上的数据为数据源,里面会涉及到各种情况的比较,
    // 具体比较逻辑在SegmentRecoveryComparator比较器中
    Entry<AsyncLogger, PrepareRecoveryResponseProto> 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<AsyncLogger, PrepareRecoveryResponseProto> 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<AsyncLogger,Void> accept = loggers.acceptRecovery(logToSync, syncFromUrl);
    loggers.waitForWriteQuorum(accept, acceptRecoveryTimeoutMs,
        "acceptRecovery(" + TextFormat.shortDebugString(logToSync) + ")");

    // 步骤5.确认数据的恢复
    QuorumCall<AsyncLogger, Void> 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

展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客
应支付0元
点击重新获取
扫码支付

支付成功即可阅读