hadoop源码分析系列（七）——org.apache.hadoop.hdfs包完结篇——dataNode详解及总结

摘要: hdfs分析的最后一篇首先进行一下dataNode（以下简称dn）的源码分析，然后总结下对hdfs包的设计模式的一点看法：DataNode既可以看做是一个类，也可以认为是一个进程，还可以认为是一台服务器，总之他的主要作用就是 ...

hdfs分析的最后一篇首先进行一下dataNode（以下简称dn）的源码分析，然后总结下对hdfs包的设计模式的一点看法：

DataNode既可以看做是一个类，也可以认为是一个进程，还可以认为是一台服务器，总之他的主要作用就是进行hdfs的数据块的存储服务。

DataNode既要负责和NN通信也要负责和其他的DN进行通信，与NN的通信的主要作用是回应NN的创建和查询块的请求，和其他DN通信主要是块的拷贝和删除。

DN主要维护了块到流的映射，当然流中要包含一些块的信息，这些信息被存储在本地硬盘，DN以一定频率把这些信息发送给NN

DN的启动一个server，它的整个生命周期就是响应NN的命令

主要的方法：

startDataNode：通过dfs.datanode.*的配置参数来初始化dataNode server

register()：向nameNode发出注册请求，并申请全局的存储标示

processCommand(DatanodeCommand[] cmds) ：执行命令集，主要的命名有以下几种：

DNA_TRANSFER：传输数据块命令

DNA_INVALIDATE：使数据块失效

DNA_SHUTDOWN：关闭节点

DNA_REGISTER：重新注册

DNA_FINALIZE：升级

DNA_RECOVERBLOCK：块恢复

syncBlock:同步块

剩下的一些方法基本就是上面提到的那几个命令的实现

下面是对客户端和dataNode通信读数据块的报文分析：

请求报文：

+----------------------------------------------+

| Common Header | 1 byte OP == OP_READ_BLOCK |

+----------------------------------------------+

返回报文：

+-------------------------------------------------------------------------+

| 8 byte Block ID | 8 byte genstamp | 8 byte start offset | 8 byte length |

+-------------------------------------------------------------------------+

| vInt length | <DFSClient id> |

+-----------------------------------+

在读数据块的时候DN发出的报文：

+---------------------------+

| 2 byte OP_STATUS_ERROR | 读取出错

+---------------------------+

+---------------------------+

| 2 byte OP_STATUS_SUCCESS | 成功读取

+---------------------------+

发送的数据：

+--------------------------------------------------+

| 1 byte CHECKSUM_TYPE | 4 byte BYTES_PER_CHECKSUM | checksum头

+--------------------------------------------------+

+------------------------------------+

| Sequence of data PACKETs .... | 真实数据

+------------------------------------+

PACKET包括以下结构：

+-----------------------------------------------------+

| 4 byte packet length (excluding packet header) |

+-----------------------------------------------------+

| 8 byte offset in the block | 8 byte sequence number |

+-----------------------------------------------------+

| 1 byte isLastPacketInBlock |

+-----------------------------------------------------+

| 4 byte Length of actual data |

+-----------------------------------------------------+

| x byte checksum data. x is defined below |

+-----------------------------------------------------+

| actual data ...... |

+-----------------------------------------------------+

x = (length of data + BYTE_PER_CHECKSUM - 1)/BYTES_PER_CHECKSUM *

CHECKSUM_SIZE

客户端读取完所有数据后告诉DN：

+------------------------------+

| 2 byte OP_STATUS_CHECKSUM_OK | ok

+------------------------------+

BlockReceiver类主要负责接收数据块，写到本地磁盘，同时负责把块复制到别的节点

BlockSender类把磁盘上的块读取出来发送给接收的节点

BlockTransferThrottler类负责限制dn的通信，这个类多多线程共享的，可以限制通信的带宽，线程数等等

DataBlockScanner类启动线程负责跟踪块的修改信息，但是不会改变元数据信息

DataStorage类是文件对象的抽象

DatanodeBlockInfo：dn上的块对象的抽象

DataXceiverServer：用ServerSocket方式问不是ipc方式接受从其他节点过来的块的信息

UpgradeManagerDatanode：处理upgrade命令

其他的就是包含些对namenode的度量信息，在这里就不详细介绍了。

最后总结下几篇文章下来对hdfs部分源码的分析的体会：

1、大量的抽象：这也可以说是面对对象的核心之一，如源码中的接口，抽象类定义，对协议，服务、数据块、节点的抽象。

2、合理的继承和实现：光是block，这个对象在nn和dn中就用不同的对象标示，进行通信的接口更是实现了很多协议，不同的通信，协议的实现都是不一样的

3、对java的设计模式理解更加深刻，这部分主要用了工厂方法，桥接模式，组合模式和命令模式，进行了层次明确，职责合理的设计，很有条理，多而不杂。

4、对java的io尤其是ipc的部分进行了深层次的运用，没用使用iiop或是rpc这样的重量级通信实现，而是简单了封装了基本的io操作，转而利用ipc，很大程度的提高了代码的可维护性和io的吞吐。

5、巧妙的数据结构设计，这个可以从协议的报文和节点维护的链表可以看出来，实现并不复杂，重要的是设计的很巧妙。

6、良好的接口扩展，很多方法并没有实现，开发人员可以很容易加入自己的实现，加入自己的思想，甚至可以很容易的修改源码来满足自己特有的需求。