每秒上千次高并发访问，HDFS优雅的抗住了

V-xin：ruyuanhadeng获得600+页原创精品文章汇总PDF

目录

一、写在前面

二、问题源起

三、HDFS优雅的解决方案：

​ （1）分段加锁机制+内存双缓冲机制

​ （2）多线程并发吞吐量的百倍优化

​ （3）缓冲数据批量刷磁盘+网络优化

一、写在前面

上篇文章我们已经初步给大家解释了Hadoop HDFS的整体架构原理，相信大家都有了一定的认识和了解。

如果没看过上篇文章的同学可以看一下：《干掉几百行的大SQL，我用Hadoop》这篇文章。

本文我们来看看，如果大量客户端对NameNode发起高并发（比如每秒上千次）访问来修改元数据，此时NameNode该如何抗住？

二、问题源起

我们先来分析一下，高并发请求NameNode会遇到什么样的问题。

大家现在都知道了，每次请求NameNode修改一条元数据（比如说申请上传一个文件，那么就需要在内存目录树中加入一个文件），都要写一条edits log，包括两个步骤：

• 写入本地磁盘。

• 通过网络传输给JournalNodes集群。

但是如果对Java有一定了解的同学都该知道多线程并发安全问题吧？

NameNode在写edits log时的第一条原则：

必须保证每条edits log都有一个全局顺序递增的transactionId（简称为txid），这样才可以标识出来一条一条的edits log的先后顺序。

---

那么如果要保证每条edits log的txid都是递增的，就必须得加锁。

每个线程修改了元数据，要写一条edits log的时候，都必须按顺序排队获取锁后，才能生成一个递增的txid，代表这次要写的edits log的序号。

好的，那么问题来了，大家看看下面的图。

如果每次都是在一个加锁的代