大局限集群下的Hadoop NameNode
|
副问题[/!--empirenews.page--]
本文我们来看看，假如大量客户端对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的序号。 好的，那么题目来了，各人看看下面的图。 假如每次都是在一个加锁的代码块里，天生txid，然后写磁盘文件edits log，收集哀求写入journalnodes一条edits log，会咋样?
不消说，这个绝对垮台了! NameNode自己用多线程吸取多个客户端发送过来的并发的哀求，功效多个线程居然修改完内存中的元数据之后，排着队写edits log! 并且你要知道，写当地磁盘 + 收集传输给journalnodes，都是很耗时的啊!机能两大杀手：磁盘写 + 收集写! 假如HDFS的架构真要是这么计划的话，根基上NameNode能承载的每秒的并发数目就很少了，也许就每秒处理赏罚几十个并发哀求处理赏罚撑死了! 二、HDFS优雅的办理方案 以是说，针对这个题目，人家HDFS是做了不少的优化的! 起首各人想一下，既然咱们不但愿每个线程写edits log的时辰，串行化列队天生txid + 写磁盘 + 写JournalNode，那么是不是可以搞一个内存缓冲? 也就是说，多个线程可以快速的获取锁，天生txid，然后快速的将edits log写入内存缓冲。 接着就快速的开释锁，让下一个线程继承获取锁后，天生id + 写edits log进入内存缓冲。 然后接下来有一个线程可以将内存中的edits log刷入磁盘，可是在这个进程中，照旧继承应承其他线程将edits log写入内存缓冲中。 可是这里又有一个题目了，假如针对统一块内存缓冲，同时有人写入，还同时有人读取后写磁盘，那也有题目，由于不能并发读写一块共享内存数据! 以是HDFS在这里采纳了double-buffer双缓冲机制来处理赏罚!将一块内存缓冲分成两个部门： 个中一个部门可以写入 其它一个部门用于读取后写入磁盘和JournalNodes。 各人也许感受笔墨论述不太直观，老端正，咱们来一张图，按次序给各人叙述一下。
(1)分段加锁机制 + 内存双缓冲机制 起首各个线程依次第一次获取锁，天生次序递增的txid，然后将edits log写入内存双缓冲的地区1，接着就立马第一次开释锁了。 趁着这个旷地，后头的线程就可以再次立马第一次获取锁，然后当即写本身的edits log到内存缓冲。 写内存那么快，也许才耗时几十玄妙，接着就立马第一次开释锁了。以是这个并发优化绝对是有结果的，各人有没有感觉到? 接着各个线程竞争第二次获取锁，有线程获取到锁之后，就看看，有没有谁在写磁盘和收集? 假如没有，好，那么这个线程是个荣幸儿!直接互换双缓冲的地区1和地区2，接着第二次开释锁。这个进程相等快速，内存里判定几个前提，耗时不了几微秒。 好，到这一步为止，内存缓冲已经被互换了，后头的线程可以立马快速的依次获取锁，然后将edits log写入内存缓冲的地区2，地区1中的数据被锁定了，不能写。 怎么样，是不是又感觉到了一点点多线程并发的优化? (2)多线程并发吞吐量的百倍优化 接着，之前谁人荣幸儿线程，将内存缓冲的地区1中的数据读取出来(此时没人写地区1了，都在写地区2)，将内里的edtis log都写入磁盘文件，以及通过收集写入JournalNodes集群。 这个进程然则很耗时的!可是不要紧啊，人家做过优化了，在写磁盘和收集的进程中，是不持有锁的! 因从此面的线程可以噼里啪啦的快速的第一次获取锁后，立马写入内存缓冲的地区2，然后开释锁。 这个时辰大量的线程都可以快速的写入内存，没有阻塞和卡顿! 怎么样?并发优化的感受感觉到了没有! (3)缓冲数据批量刷磁盘 + 收集的优化 那么在荣幸儿线程吭哧吭哧把数据写磁盘和收集的进程中，排在后头的大量线程，快速的第一次获取锁，写内存缓冲地区2，开释锁，之后，这些线程第二次获取到锁后会干嘛? 他们会发明有人在写磁盘啊，兄弟们!以是会当即休眠1秒，开释锁。 此时大量的线程并发过来的话，城市在这里快速的第二次获取锁，然后发明有人在写磁盘和收集，快速的开释锁，休眠。 怎么样，这个进程没有人长时刻的阻塞其他人吧!由于城市快速的开释锁，所往后头的线程照旧可以敏捷的第一次获取锁后写内存缓冲! again!并发优化的感受感觉到了没有? 并且这时，必然会有许多线程发明，仿佛之前谁人荣幸儿线程的txid是排在本身之后的，那么必定就把本身的edits log从缓冲里写入磁盘和收集了。 这些线程乃至都不会休眠守候，直接就会返回后去干此外工作了，压根儿不会卡在这里。这里又感觉到并发的优化没有? 然后谁人荣幸儿线程写完磁盘和收集之后，就会叫醒之前休眠的那些线程。 那些线程会依次列队再第二次获取锁后进入判定，咦!发明没有人在写磁盘和收集了! 然后就会再判定，有没有排在本身之后的线程已经将本身的edtis log写入磁盘和收集了。 假若有的话，就直接返回了。 没有的话，那么就成为第二个荣幸儿线程，互换两块缓冲区，地区1和地区2互换一下。 然后开释锁，本身开始吭哧吭哧的将地区2的数据写入磁盘和收集。 可是这个时辰没有相关啊，后头的线程假如要写edits log的，照旧可以第一次获取锁后立马写内存缓冲再开释锁。以此类推。 三、总结 其拭魅这套机制照旧挺伟大的，涉及到了分段加锁以及内存双缓冲两个机制。 通过这套机制，NameNode担保了多个线程在高并发的修改元数据之后写edits log的时辰，不会说一个线程一个线程的写磁盘和收集，那样机能其实太差，并发手段太弱了! 以是通过上述那套伟大的机制，尽最大的全力担保，一个线程可以批量的将一个缓冲中的多条edits log刷入磁盘和收集。 在这个漫长的吭哧吭哧的进程中，其他的线程可以快速的高并发写入edits log到内存缓冲里，不会阻塞其他的线程写edits log。 以是，正是依赖以上机制，最大限度优化了NameNode处理赏罚高并发会见修改元数据的手段! （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
