摘要：既要负责和通信也要负责和其他的进行通信，与的通信的主要作用是回应的创建和查询块的请求，和其他通信主要是块的拷贝和删除。
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 |
|
+-----------------------------------+
在读数据块的时候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、良好的接口扩展，很多方法并没有实现，开发人员可以很容易加入自己的实现，加入自己的思想，甚至可以很容易的修改源码来满足自己特有的需求。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/3806.html
