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的序号。
好的，那么问题来了，大家看看下面的图。
