基于RPC Call延时返回的HDFS异步editlog原理

前言

---

前面文章笔者介绍过Hadoop社区为了增加内部RPC的throughput，通过延时返回response的调整来提早释放Server端的Handler资源，以此尽可能的把Handler的处理能力用在真正的RPC请求上。HDFS目前所使用的异步editlog机制正是使用了这个优化改进。这里所说的HDFS异步editlog写出并不是大家所简单的认为NameNode完全异步化写出editlog到其JournalNode服务中，然后直接返回结果给client。那么但异步写出editlog失败的时候，client怎么能知道后面发生的结果呢？它只能接受之前收到的“预期”结果进行后续的操作了。因此我们说延时返回在这个场景就能发挥其强大的作用了。本文笔者来详细聊聊这个延时返回机制如何在HDFS的异步editlog中发挥作用的。

现有HDFS的RPC正常请求处理

---

在讲述HDFS异步editlog机制之前，我们先来看看正常HDFS RPC请求处理的过程：

• 1）Client端发起请求操作。
• 2）NameNode收到请求，然后执行对应RPC call请求方法的处理，以及操作处理成功情况下，需要额外写出对应操作的editlog信息。
• 3）NameNode请求执行结束，在方法末尾操作执行logSync操作，写出此操作对应的editlog到JournalNode中,至此一个完整的RPC调用操作结束。
• 4）NameNode返回结果回复给Client。

简单图示过程如下：

以下是一个NameNode里面的样例RPC call请求处理方法：

  boolean setReplication(final String src, final short replication)
      throws IOException {
   
    final String operationName = "setReplication";
    boolean success = false;
    checkOperation(OperationCategory.WRITE);
    final FSPermissionChecker pc = getPermissionChecker();
    FSPermissionChecker.setOperationType(operationName);</