在《HDFS源码分析之DataXceiverServer》一文中，我们了解到在DataNode中，有一个后台工作的线程DataXceiverServer。它被用于接收来自客户端或其他数据节点的数据读写请求，为每个数据读写请求创建一个单独的线程去处理。而处理每次读写请求时所创建的线程，就是本文要讲的DataXceiver。本文，我们来看下DataXceiver的具体实现，着重讲解下它得到数据读写请求后的整体处理流程。
首先，我们先看下DataXceiver的成员变量，具体如下：
// 封装了Socket、输入流、输出流的Peer，是DataXceiver线程工作的主要依托者 private Peer peer; // 通讯两端地址：远端地址remoteAddress、本地端地址localAddress，均是从peer（即socket）中获得的 private final String remoteAddress; // address of remote side private final String localAddress; // local address of this daemon // DataNode节点进程实例datanode private final DataNode datanode; // DataNode节点配置信息dnConf private final DNConf dnConf; // DataXceiverServer线程实例dataXceiverServer private final DataXceiverServer dataXceiverServer; // 连接DataNode是否使用主机名，取参数dfs.datanode.use.datanode.hostname，参数未配置的话默认为false，不使用 private final boolean connectToDnViaHostname; // 接收到一个操作op的开始时间 private long opStartTime; //the start time of receiving an Op // InputStream输入流socketIn private final InputStream socketIn; // OutputStream输出流socketOut private OutputStream socketOut; // 数据块接收器BlockReceiver对象blockReceiver private BlockReceiver blockReceiver = null; /** * Client Name used in previous operation. Not available on first request * on the socket. * previousOpClientName为之前操作的客户端名字，它对于socket上的第一个请求不可用 */ private String previousOpClientName;既然DataXceiver是为处理数据读写请求而创建的线程，那么Socket、输入流、输出流就是必不可少的成员。而首当其冲的Peer，便封装了Socket、输入流、输出流的Peer，是DataXceiver线程工作的主要依托者，而接下来的输入流socketIn、输出流socketOut都是来自peer的socket。另外，DataXceiver还提供了通讯两端地址：远端地址remoteAddress、本地端地址localAddress，均是从peer（即socket）中获得的。
既然是由DataNode上的DataXceiverServer线程创建的，那么自然少不了datanode、dataXceiverServer、dnConf等变量，并且，它是专门用来处理数据读写请求的，自然也需要像数据块接收器BlockReceiver对象blockReceiver这种成员变量。dnConf是DNConf类型的数据节点DataNode上的配置信息。
剩下的几个，便是在处理具体的数据读写请求时用到的connectToDnViaHostname、opStartTime、previousOpClientName等变量。其中，connectToDnViaHostname标识连接DataNode是否使用主机名，取参数dfs.datanode.use.datanode.hostname，参数未配置的话默认为false，不使用，opStartTime为接收到一个操作op的开始时间，最后的previousOpClientName为之前操作的客户端名字，它对于socket上的第一个请求不可用。
下面我们再看下它的构造方法，只有一个private的，如下：
/**
* 私有构造函数，需要Peer、DataNode、DataXceiverServer三个参数
*/
private DataXceiver(Peer peer, DataNode datanode,
DataXceiverServer dataXceiverServer) throws IOException {
// peer、datanode、dataXceiverServer等成员变量直接赋值
this.peer = peer;
this.dnConf = datanode.getDnConf();
// 输入流socketIn、输出流socketOut来自peer的socket
this.socketIn = peer.getInputStream();
this.socketOut = peer.getOutputStream();
this.datanode = datanode;
this.dataXceiverServer = dataXceiverServer;
// connectToDnViaHostname取自数据节点配置信息dnConf
this.connectToDnViaHostname = datanode.getDnConf().connectToDnViaHostname;
// 远端remoteAddress和本地localAddress地址取自Peer
remoteAddress = peer.getRemoteAddressString();
localAddress = peer.getLocalAddressString();
if (LOG.isDebugEnabled()) {
LOG.debug("Number of active connections is: "
+ datanode.getXceiverCount());
}
} 但是，它提供了一个类的静态create()方法，用于DataXceiver对象的构造，代码如下：
/**
* 提供了一个静态方法create()，调用私有构造函数构造DataXceiver对象
*/
public static DataXceiver create(Peer peer, DataNode dn,
DataXceiverServer dataXceiverServer) throws IOException {
return new DataXceiver(peer, dn, dataXceiverServer);
} 上述构造方法及静态create()方法都很简单，不再赘述。
接下来，我们再着重分析下，DataXceiver线程在启动后，是如何处理来自客户端或者其他数据节点发送的数据读写请求的。既然是线程，那么就不得不看看它的run()方法，代码如下：
/**
* Read/write data from/to the DataXceiverServer.
* 从DataXceiverServer中读取或者往DataXceiverServer中写入数据
*/
@Override
public void run() {
int opsProcessed = 0;
Op op = null;
try {
// 在dataXceiverServer中增加peer与该DataXceiver实例所在线程和DataXceiver实例的映射关系
dataXceiverServer.addPeer(peer, Thread.currentThread(), this);
// peer中设置socket写入超时时间
peer.setWriteTimeout(datanode.getDnConf().socketWriteTimeout);
InputStream input = socketIn;
try {
// IOStreamPair为一个输入输出流对，既包含输入流，也包含输出流
IOStreamPair saslStreams = datanode.saslServer.receive(peer, socketOut,
socketIn, datanode.getXferAddress().getPort(),
datanode.getDatanodeId());
// 包装saslStreams的输入流in为BufferedInputStream，得到输入流input，其缓冲区大小取参数io.file.buffer.size的一半，
// 参数未配置的话默认为512，且最大也不能超过512
input = new BufferedInputStream(saslStreams.in,
HdfsConstants.SMALL_BUFFER_SIZE);
// 从saslStreams中获取输出流socketOut
socketOut = saslStreams.out;
} catch (InvalidMagicNumberException imne) {
LOG.info("Failed to read expected encryption handshake from client " +
"at " + peer.getRemoteAddressString() + ". Perhaps the client " +
"is running an older version of Hadoop which does not support " +
"encryption");
return;
}
// 调用父类initialize()方法，完成初始化，实际上就是设置父类的输入流in
super.initialize(new DataInputStream(input));
// We process requests in a loop, and stay around for a short timeout.
// This optimistic behaviour allows the other end to reuse connections.
// Setting keepalive timeout to 0 disable this behavior.
// 在一个do...while循环内完成请求的处理。
do {
// 更新当前线程名称，通过线程名标识进度的一种手段，不错
updateCurrentThreadName("Waiting for operation #" + (opsProcessed + 1));
try {
// 由于第一次是创建一个新的socket使用，连接的时间可能会很长，所以连接超时时间设置的比较大，
// 而后续使用的话，是复用socket，连接的超时时间限制就没必要设置那么大了
if (opsProcessed != 0) {
// 如果不是第一次出来请求，确保dnConf的socketKeepaliveTimeout大于0，
// 将其设置为设置peer（即socket）的读超时时间，
// 取参数dfs.datanode.socket.reuse.keepalive，参数为配置的话，默认为4s
assert dnConf.socketKeepaliveTimeout > 0;
peer.setReadTimeout(dnConf.socketKeepaliveTimeout);
} else {
// 最开始第一次处理请求时，设置peer（即socket）读超时时间为dnConf的socketTimeout
// 即取参数dfs.client.socket-timeout，参数未配置的话默认为60s
peer.setReadTimeout(dnConf.socketTimeout);
}
// 通过readOp()方法读取操作符op
op = readOp();
} catch (InterruptedIOException ignored) {
// Time out while we wait for client rpc
// 如果是InterruptedIOException异常，跳出循环
break;
} catch (IOException err) {
// Since we optimistically expect the next op, it's quite normal to get EOF here.
if (opsProcessed > 0 &&
(err instanceof EOFException || err instanceof ClosedChannelException)) {
if (LOG.isDebugEnabled()) {
LOG.debug("Cached " + peer + " closing after " + opsProcessed + " ops");
}
} else {
throw err;
}
break;
}
// restore normal timeout
// 重新存储正常的超时时间，即dnConf的socketTimeout
if (opsProcessed != 0) {
peer.setReadTimeout(dnConf.socketTimeout);
}
// 设置操作的起始时间opStartTime
opStartTime = now();
// 通过processOp()方法根据操作符op调用相应的方法处理操作符op
processOp(op);
// 累加操作数
++opsProcessed;
} while ((peer != null) &&
(!peer.isClosed() && dnConf.socketKeepaliveTimeout > 0));
// 循环的条件便是：peer未关闭且复用超时时间socketKeepaliveTimeout大于0
} catch (Throwable t) {
String s = datanode.getDisplayName() + ":DataXceiver error processing "
+ ((op == null) ? "unknown" : op.name()) + " operation "
+ " src: " + remoteAddress + " dst: " + localAddress;
if (op == Op.WRITE_BLOCK && t instanceof ReplicaAlreadyExistsException) {
// For WRITE_BLOCK, it is okay if the replica already exists since
// client and replication may write the same block to the same datanode
// at the same time.
if (LOG.isTraceEnabled()) {
LOG.trace(s, t);
} else {
LOG.info(s + "; " + t);
}
} else {
LOG.error(s, t);
}
} finally {
if (LOG.isDebugEnabled()) {
LOG.debug(datanode.getDisplayName() + ":Number of active connections is: "
+ datanode.getXceiverCount());
}
// 更新当前线程名称
updateCurrentThreadName("Cleaning up");
// 关闭peer（socket）、输入流等资源
if (peer != null) {
dataXceiverServer.closePeer(peer);
IOUtils.closeStream(in);
}
}
}
run()方法的处理流程逻辑十分清晰，概括如下：
1、在dataXceiverServer中增加peer与该DataXceiver实例所在线程和DataXceiver实例的映射关系；
2、peer中设置socket写入超时时间，取参数dfs.datanode.socket.write.timeout，参数未配置的话默认为8分钟；
3、获取IOStreamPair类型的saslStreams，其为一个输入输出流对，既包含输入流，也包含输出流；
4、包装saslStreams的输入流in为BufferedInputStream，得到输入流input，其缓冲区大小取参数io.file.buffer.size的一半，参数未配置的话默认为512，且最大也不能超过512；
5、从saslStreams中获取输出流socketOut；
6、调用父类initialize()方法，完成初始化，实际上就是设置父类的输入流in；
7、在一个do...while循环内完成请求的处理，循环的条件便是--peer未关闭且复用超时时间socketKeepaliveTimeout大于0：
7.1、更新当前线程名称，通过线程名标识进度的一种手段，不错，线程名此时为Waiting for operation #100（100为操作处理次数累加器的下一个值）；
7.2、处理读超时时间设置：由于第一次是创建一个新的socket使用，连接的时间可能会很长，所以连接超时时间设置的比较大，而后续使用的话，是复用socket，连接的超时时间限制就没必要设置那么大了。所以，最开始第一次处理请求时，设置peer（即socket）读超时时间为dnConf的socketTimeout，即取参数dfs.client.socket-timeout，参数未配置的话默认为60s；如果不是第一次出来请求，确保dnConf的socketKeepaliveTimeout大于0，将其设置为设置peer（即socket）的读超时时间，取参数dfs.datanode.socket.reuse.keepalive，参数为配置的话，默认为4s；
7.3、通过readOp()方法读取操作符op；
7.4、重新存储正常的超时时间，即dnConf的socketTimeout；
7.5、设置操作的起始时间opStartTime，为当前时间；
7.6、通过processOp()方法根据操作符op调用相应的方法处理操作符op；
7.7、累加操作数opsProcessed；
8、更新当前线程名称：Cleaning up；
9、关闭peer（socket）、输入流等资源。
实际上，对于读写请求的处理的一个主线，便是在socket未关闭的情况下，不停的读取操作符，然后调用相应的方法处理，也就是do...while循环内的op = readOp()-----processOp(op)这一处理主线。
下面，我们来看下读取操作符的readOp()方法，它位于DataXceiver的父类Receiver中。代码如下：
/** Read an Op. It also checks protocol version. */
protected final Op readOp() throws IOException {
// 首先从输入流in中读入版本号version，short类型，占2个字节
final short version = in.readShort();
// 校验版本号version是否与DataTransferProtocol中的DATA_TRANSFER_VERSION相等，该版本中为28
if (version != DataTransferProtocol.DATA_TRANSFER_VERSION) {
throw new IOException( "Version Mismatch (Expected: " +
DataTransferProtocol.DATA_TRANSFER_VERSION +
", Received: " + version + " )");
}
// 调用Op的read()方法，从输入流in中获取操作符op
return Op.read(in);
} 代码中有详细注释，不再解释。继续追踪Op的read()方法，代码如下：
private static final int FIRST_CODE = values()[0].code;
/** Return the object represented by the code. */
private static Op valueOf(byte code) {
final int i = (code & 0xff) - FIRST_CODE;
return i < 0 || i >= values().length? null: values()[i];
}
/** Read from in */
public static Op read(DataInput in) throws IOException {
return valueOf(in.readByte());
} 很简单，通过read()方法从输入流读取byte，并通过valueOf()方法，首先将byte转化为int，然后减去Op操作符枚举类型的第一个值：WRITE_BLOCK，即80，得到i。如果i小于0或者大于枚举中操作符的个数，说明输入流中传入的操作符不在枚举范围内，否则利用i作为索引取出相应的操作符。枚举类型如下：
WRITE_BLOCK((byte)80), READ_BLOCK((byte)81), READ_METADATA((byte)82), REPLACE_BLOCK((byte)83), COPY_BLOCK((byte)84), BLOCK_CHECKSUM((byte)85), TRANSFER_BLOCK((byte)86), REQUEST_SHORT_CIRCUIT_FDS((byte)87), RELEASE_SHORT_CIRCUIT_FDS((byte)88), REQUEST_SHORT_CIRCUIT_SHM((byte)89);比较简单，写数据块为80，读数据块为81等，不再一一介绍。操作符为int类型，也就意味着它占4个字节。
接下来，我们再看下处理操作符的processOp()方法，同样在DataXceiver的父类Receiver中。代码如下：
/** Process op by the corresponding method. */
protected final void processOp(Op op) throws IOException {
// 通过调用相应的方法处理操作符
switch(op) {
case READ_BLOCK:// 读数据块调用opReadBlock()方法
opReadBlock();
break;
case WRITE_BLOCK:// 写数据块调用opWriteBlock()方法
opWriteBlock(in);
break;
case REPLACE_BLOCK:// 替换数据块调用opReplaceBlock()方法
opReplaceBlock(in);
break;
case COPY_BLOCK:// 复制数据块调用REPLACE()方法
opCopyBlock(in);
break;
case BLOCK_CHECKSUM:// 数据块检验调用opBlockChecksum()方法
opBlockChecksum(in);
break;
case TRANSFER_BLOCK:// 移动数据块调用opTransferBlock()方法
opTransferBlock(in);
break;
case REQUEST_SHORT_CIRCUIT_FDS:
opRequestShortCircuitFds(in);
break;
case RELEASE_SHORT_CIRCUIT_FDS:
opReleaseShortCircuitFds(in);
break;
case REQUEST_SHORT_CIRCUIT_SHM:
opRequestShortCircuitShm(in);
break;
default:
throw new IOException("Unknown op " + op + " in data stream");
}
} 一目了然，根据操作符的不同，调用不同的方法去处理。比如读数据块调用opReadBlock()方法，写数据块调用opWriteBlock()方法，替换数据块调用opReplaceBlock()方法等等，读者可自行阅读。
至此，HDFS源码分析DataXceiver之整体流程全部叙述完毕。后续文章会陆续推出对于写数据块、读数数据块、替换数据块、移动数据块等的详细操作，以及DataXceiver线程中用到的数据块发送器BlockSender、数据块接收器BlockReceiver的详细分析，敬请期待！
