前言
前面文章笔者介绍过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);</