HDFS的碎碎念.

  HDFS说简单也简单,说复杂,其实也不复杂.

  它解决的主要是在集群规模大了之后,distribution的问题.
  更重要的是把disk的failure视为常态.

  因为毕竟,只是单纯的distribution的话,如NFS的也可以达到目的.
  但概念是Google提出的,它面对的问题显然不是一般人会常态遇见的.

  所以HDFS/GFS的概念主要在replication.
  
  理论上的模型也很符合直觉.
  寻找一个可用的节点,然后分发之.
  
  所不同的就是这种分发的具体实现了.

  HDFS的replication其实很简单.

  比如你upload一个local的文件到HDFS的时候,DFSClient会向namenode发起一个RPC的create请求.

  顺便说下,Hadoop的RPC其实有两套.
  一套是给各种node的用的,基于interface的reflection.
  另一个套是给DFSClient之类的,基于Invocaionhandler.
  但本质都是把方法名和参数以及连接信息什么的写到流里,然后在method.invoke()

  也许可以理解为前者是给server用的.毕竟有了local的instance.
  而诸如DFSClient的是没有instance的实现的,所以要InovcationHandler去hook.

  回到create.
  
  namenode会向FSNamesystem添加一个inode信息,同时记录一个lease.
  此时的inode为INodeFileUnderConstruction,表明是未完成的.
  而lease的作用是用来保证不重复create/以及一些超时处理.
  
  然后namenode将这个RPC的请求返回给DFSClient.
  
  DFSClient会开启一个DataStreamer去做copy and write的工作.

  首先是到RPC到namenode去申请block.
  此时的namenode会去查看FSNamesystem里的inode信息.
  
  namenode会检查inode的类型是否是INodeFileUnderConstruction,即未完成.
  然后会check下lease的信息,看时候有意外的已经replication的情况.(这个估计是以前有类似bug吧.)

  当然,在此时,一般这些check都会pass掉的.
  但,这是distribution的,所以,按照状态机来变换是最简单的事情.
   
  datanode会根据block size去选择一些datanode.
  在用DFSClient.copyfromlocal的情况下,block size是由参数fs.local.block.size决定的.
  其他情况下,是由dfs.block.size决定的.

  replicator在choose datanode的时候会根据replication的数目而略有说不同.
  当数目是<2的时候,当local也是datanode的是会被选上.
  其他情况则感觉datanode上的block数目和load做一个权衡.

  然后把选择好的naenode把block和datanode的分配信息返还给DFSClient.
  DFSClient则选择第一个datanode建立连接,把读到的数据写到这个选中的datanode上.

  在DataStreamer里还有一个ResponseProcessor的东西,在处理这个datanode返回来的ack.

  但是,这里只写往了一个datanode,那么replication怎么实现的呢?

  这个在datanode的实现了.
  datanode在经历过一些列初始化之后,会有一个DataXceiverServer去处理进来的连接.
  尤其的,没一个连接会dispatch到DataXceiver去处理.
  
  DataXceiver就是HDFS的IO操作的核心吧.
  
  当地一个datanode收到DFSClient发来的OP_WRITE_BLOCK请求时候,会调用writeBlock把读到的block写到datanode的local filesystem里.
  同时会取DFSClient传过来的datanode array信息,取第一个,然后与之建立连接,然后把把block信息和剩下的datanode写到对方的stream里.
  
  即,HDFS的replication就是通过这种级联的,pipeline方式的write扩散出去的.
  同样,ack也是一级一级地往前传递.

  至于写到datanode上的block大小限制是在DFSOutputStream里限定的.
  当写到这个数的时候会表明这是最后一个package.

  至于读则差不多.
  namenode会在返回datanode的时候稍微排序下.
  将local和local rack的往前排.
  因为client在取datanode的时候总是先取前面.

  至于local rack怎么决定的.
  这个在NetworkTopology里,没仔细看.