namenode和datanode工作机制_Namenode、DataNode工作机制

前言：

我们上一节看到了如何搭建和验证我们hadoop平台，在验证时我们使用jps命令查看进程，如下：DataNode、NameNode、SecondaryNameNode

那么这些进程都具有哪些功能，这些功能是怎么服务于hadoop平台的，进程之间是怎么进行合作的，这些问题就是我们这一节要解决的问题。(yarn暂时不考虑)

概括来讲，以银行打一个比方，namenode是一个前台记账客服，secondarynamenode是后台维护账本和更新的工作人员，即对前台的业务进行整合处理，而DataNode是存钱的地方，金库。

现在我们要明白我们所处的机器环境，我的这台hmaster，现在担任了上述的三个角色，但正常的集群中，这三个是不在同一台机器上的，在这里放在一起是为了方便演示。

0 元数据

简单来说就是文件的存储信息

NameNode(FileName, replicas, block-ids,id2host...)

ex: /test/a.log, 3 ,{blk_1,blk_2}, [{blk_1:[h0,h1,h3]},{blk_2:[h0,h2,h4]}]/test/a.log, 3 ,{blk_1,blk_2}, [{blk_1:[h0,h1,h3]},{blk_2:[h0,h2,h4]}]

1 NameNode

我们先来考虑hadoop关于文件上传的功能。

nameNode是文件存储信息的重要部分。我们都知道hadoop是处理海量数据的，那么namenode中所要存储的文件信息也就特别多，为了能提高与用户的交互速度，这些元数据会被加载到内存中进行操作，当然namenode的硬盘上也有备份。

在集群工作中，断电、宕机是很经常的事，那么如何保证namenode中硬盘上的数据和内存的数据是同步的，还有即使不宕机，要不断的同步两者之间的数据，这也是很耗费cpu资源的，影响与用户的交互速度，那么这些问题要如何处理呢？

实现方案有很多，但是，没有绝对的同步。

hadoop最初认为这种情况的处理是hadoop的能力方位之外，所以之后hadoop就交给企业自己处理了，随着企业处理方案的增多和逐渐成熟，hadoop就集百家之长，也给出了自己的处理方案：

实际上namenode硬盘中的元数据并不是来自于自己的内存，而是从secondaryNamenode中下载的，且听我慢慢道来。

用户在客户端上传一个文件，最先与客户交互的是namenode，namenode先将该用户的上传动作用一个存放在硬盘上的日志文件(edits.log)记录下来，然后在DataNode上写入该文件，接着再从namenode内存中更新这条元数据。用日志文件的方法就解决了namenode断电数据丢失的问题。

接下来就是完成namenode中硬盘数据更新的动作了。当edits.log文件中新增条数达到一定数目，或者经过一段时间后，namenode(nn)会通知secondaryNamenode(sn)要进行数据更新了。首先sn会向nn索取日志文件，并让nn在新建一个edits.new文件，暂时替代edits.log文件，sn拿到日志文件后，再从nn中下载其硬盘中的元数据。加载到内存，对照着日志文件，进行合并更新，完成之后，再上传到nn中，替换原来的元数据文件，还有那edits.new也重命名为edits.log。这样一来就减轻了nn的cpu工作压力。

至此，namenode的工作就介绍的差不多了。其中在nn中存储元数据的地方叫fsimage，在sn中存储元数据的地方叫fsimage.chkpoint。

2 DataNode

关于DataNode我们说的就比较简单了，它只要起一个存储作用，值得注意的是，为防止机器硬盘坏了，DataNode对每一个文件都是会存放副本的，默认是3个，DataNode在存放的时候，会将其中一个放在不同的机架上(若果有的话)，防止机架断电，最后一个就随机存放了。