hadoop源码分析系列（七）——org.apache.hadoop.hdfs包完结篇—...

gtdfe

摘要: 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、良好的接口扩展，很多方法并没有实现，开发人员可以很容易加入自己的实现，加入自己的思想，甚至可以很容易的修改源码来满足自己特有的需求。