#
screen 进入screen模式
C-a c 在当前screen下建立新的窗口
exit 退出当前窗口，如果它是此screen的唯一窗口时，此screen也将完全退出。
C-a d 暂时断开screen会话
screen -ls 查看有哪些screen。
screen -r id 打开编号为id的screen窗口。
C-a w 显示所有窗口列表
C-a n 切换到下一个窗口
C-a p 切换到前一个窗口(与C-a n相对)
最无敌命令 screen --help
原文：http://hadoop.apache.org/core/docs/current/hdfs_design.html
一、前提和设计目标1
、硬件错误是常态，而非异常情况，HDFS
可能是有成百上千的server
组成，任何一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是HDFS
的核心架构目标。2
、跑在HDFS
上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。3
、HDFS
以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至T
字节，一个单一HDFS
实例应该能支撑数以千万计的文件。4
、 HDFS
应用对文件要求的是write-one-read-many
访问模型。一个文件经过创建、写，关闭之后就不需要改变。这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。典型的如MapReduce
框架，或者一个web crawler
应用都很适合这个模型。5
、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好，HDFS
提供给应用这样的接口。6
、在异构的软硬件平台间的可移植性。二、Namenode
和Datanode
HDFS
采用master/slave
架构。一个HDFS
集群是有一个Namenode
和一定数目的Datanode
组成。Namenode
是一个中心服务器，负责管理文件系统的namespace
和客户端对文件的访问。Datanode
在集群中一般是一个节点一个，负责管理节点上它们附带的存储。在内部，一个文件其实分成一个或多个block
，这些block
存储在Datanode
集合里。Namenode
执行文件系统的namespace
操作，例如打开、关闭、重命名文件和目录，同时决定block
到具体Datanode
节点的映射。Datanode
在Namenode
的指挥下进行block
的创建、删除和复制。Namenode
和Datanode
都是设计成可以跑在普通的廉价的运行linux
的机器上。HDFS
采用java
语言开发，因此可以部署在很大范围的机器上。一个典型的部署场景是一台机器跑一个单独的Namenode
节点，集群中的其他机器各跑一个Datanode
实例。这个架构并不排除一台机器上跑多个Datanode
，不过这比较少见。
单一节点的Namenode
大大简化了系统的架构。Namenode
负责保管和管理所有的HDFS
元数据，因而用户数据就不需要通过Namenode
（也就是说文件数据的读写是直接在Datanode
上）。三、文件系统的namespace
HDFS
支持传统的层次型文件组织，与大多数其他文件系统类似，用户可以创建目录，并在其间创建、删除、移动和重命名文件。HDFS
不支持user quotas
和访问权限，也不支持链接（link)
，不过当前的架构并不排除实现这些特性。Namenode
维护文件系统的namespace
，任何对文件系统namespace
和文件属性的修改都将被Namenode
记录下来。应用可以设置HDFS
保存的文件的副本数目，文件副本的数目称为文件的 replication
因子，这个信息也是由Namenode
保存。四、数据复制 HDFS
被设计成在一个大集群中可以跨机器地可靠地存储海量的文件。它将每个文件存储成block
序列，除了最后一个block
，所有的block
都是同样的大小。文件的所有block
为了容错都会被复制。每个文件的block
大小和replication
因子都是可配置的。Replication
因子可以在文件创建的时候配置，以后也可以改变。HDFS
中的文件是write-one
，并且严格要求在任何时候只有一个writer
。Namenode
全权管理block
的复制，它周期性地从集群中的每个Datanode
接收心跳包和一个Blockreport
。心跳包的接收表示该Datanode
节点正常工作，而Blockreport
包括了该Datanode
上所有的block
组成的列表。
1、副本的存放，副本的存放是HDFS可靠性和性能的关键。HDFS采用一种称为rack-aware的策略来改进数据的可靠性、有效性和网络带宽的利用。这个策略实现的短期目标是验证在生产环境下的表现，观察它的行为，构建测试和研究的基础，以便实现更先进的策略。庞大的HDFS实例一般运行在多个机架的计算机形成的集群上，不同机架间的两台机器的通讯需要通过交换机，显然通常情况下，同一个机架内的两个节点间的带宽会比不同机架间的两台机器的带宽大。
通过一个称为Rack Awareness的过程，Namenode决定了每个Datanode所属的rack id。一个简单但没有优化的策略就是将副本存放在单独的机架上。这样可以防止整个机架（非副本存放）失效的情况，并且允许读数据的时候可以从多个机架读取。这个简单策略设置可以将副本分布在集群中，有利于组件失败情况下的负载均衡。但是，这个简单策略加大了写的代价，因为一个写操作需要传输block到多个机架。
在大多数情况下，replication因子是3，HDFS的存放策略是将一个副本存放在本地机架上的节点，一个副本放在同一机架上的另一个节点，最后一个副本放在不同机架上的一个节点。机架的错误远远比节点的错误少，这个策略不会影响到数据的可靠性和有效性。三分之一的副本在一个节点上，三分之二在一个机架上，其他保存在剩下的机架中，这一策略改进了写的性能。
2、副本的选择，为了降低整体的带宽消耗和读延时，HDFS会尽量让reader读最近的副本。如果在reader的同一个机架上有一个副本，那么就读该副本。如果一个HDFS集群跨越多个数据中心，那么reader也将首先尝试读本地数据中心的副本。
3、SafeMode
Namenode启动后会进入一个称为SafeMode的特殊状态，处在这个状态的Namenode是不会进行数据块的复制的。Namenode从所有的 Datanode接收心跳包和Blockreport。Blockreport包括了某个Datanode所有的数据块列表。每个block都有指定的最小数目的副本。当Namenode检测确认某个Datanode的数据块副本的最小数目，那么该Datanode就会被认为是安全的；如果一定百分比（这个参数可配置）的数据块检测确认是安全的，那么Namenode将退出SafeMode状态，接下来它会确定还有哪些数据块的副本没有达到指定数目，并将这些block复制到其他Datanode。
五、文件系统元数据的持久化
Namenode存储HDFS的元数据。对于任何对文件元数据产生修改的操作，Namenode都使用一个称为Editlog的事务日志记录下来。例如，在HDFS中创建一个文件，Namenode就会在Editlog中插入一条记录来表示；同样，修改文件的replication因子也将往 Editlog插入一条记录。Namenode在本地OS的文件系统中存储这个Editlog。整个文件系统的namespace，包括block到文件的映射、文件的属性，都存储在称为FsImage的文件中，这个文件也是放在Namenode所在系统的文件系统上。
Namenode在内存中保存着整个文件系统namespace和文件Blockmap的映像。这个关键的元数据设计得很紧凑，因而一个带有4G内存的 Namenode足够支撑海量的文件和目录。当Namenode启动时，它从硬盘中读取Editlog和FsImage，将所有Editlog中的事务作用（apply)在内存中的FsImage ，并将这个新版本的FsImage从内存中flush到硬盘上,然后再truncate这个旧的Editlog，因为这个旧的Editlog的事务都已经作用在FsImage上了。这个过程称为checkpoint。在当前实现中，checkpoint只发生在Namenode启动时，在不久的将来我们将实现支持周期性的checkpoint。
Datanode并不知道关于文件的任何东西，除了将文件中的数据保存在本地的文件系统上。它把每个HDFS数据块存储在本地文件系统上隔离的文件中。 Datanode并不在同一个目录创建所有的文件，相反，它用启发式地方法来确定每个目录的最佳文件数目，并且在适当的时候创建子目录。在同一个目录创建所有的文件不是最优的选择，因为本地文件系统可能无法高效地在单一目录中支持大量的文件。当一个Datanode启动时，它扫描本地文件系统，对这些本地文件产生相应的一个所有HDFS数据块的列表，然后发送报告到Namenode，这个报告就是Blockreport。
六、通讯协议
所有的HDFS通讯协议都是构建在TCP/IP协议上。客户端通过一个可配置的端口连接到Namenode，通过ClientProtocol与 Namenode交互。而Datanode是使用DatanodeProtocol与Namenode交互。从ClientProtocol和 Datanodeprotocol抽象出一个远程调用(RPC），在设计上，Namenode不会主动发起RPC，而是是响应来自客户端和 Datanode 的RPC请求。
七、健壮性
HDFS的主要目标就是实现在失败情况下的数据存储可靠性。常见的三种失败：Namenode failures, Datanode failures和网络分割（network partitions)。
1、硬盘数据错误、心跳检测和重新复制
每个Datanode节点都向Namenode周期性地发送心跳包。网络切割可能导致一部分Datanode跟Namenode失去联系。 Namenode通过心跳包的缺失检测到这一情况，并将这些Datanode标记为dead，不会将新的IO请求发给它们。寄存在dead Datanode上的任何数据将不再有效。Datanode的死亡可能引起一些block的副本数目低于指定值，Namenode不断地跟踪需要复制的 block，在任何需要的情况下启动复制。在下列情况可能需要重新复制：某个Datanode节点失效，某个副本遭到损坏，Datanode上的硬盘错误，或者文件的replication因子增大。
2、集群均衡
HDFS支持数据的均衡计划，如果某个Datanode节点上的空闲空间低于特定的临界点，那么就会启动一个计划自动地将数据从一个Datanode搬移到空闲的Datanode。当对某个文件的请求突然增加，那么也可能启动一个计划创建该文件新的副本，并分布到集群中以满足应用的要求。这些均衡计划目前还没有实现。
3、数据完整性
从某个Datanode获取的数据块有可能是损坏的，这个损坏可能是由于Datanode的存储设备错误、网络错误或者软件bug造成的。HDFS客户端软件实现了HDFS文件内容的校验和。当某个客户端创建一个新的HDFS文件，会计算这个文件每个block的校验和，并作为一个单独的隐藏文件保存这些校验和在同一个HDFS namespace下。当客户端检索文件内容，它会确认从Datanode获取的数据跟相应的校验和文件中的校验和是否匹配，如果不匹配，客户端可以选择从其他Datanode获取该block的副本。
4、元数据磁盘错误
FsImage和Editlog是HDFS的核心数据结构。这些文件如果损坏了，整个HDFS实例都将失效。因而，Namenode可以配置成支持维护多个FsImage和Editlog的拷贝。任何对FsImage或者Editlog的修改，都将同步到它们的副本上。这个同步操作可能会降低 Namenode每秒能支持处理的namespace事务。这个代价是可以接受的，因为HDFS是数据密集的，而非元数据密集。当Namenode重启的时候，它总是选取最近的一致的FsImage和Editlog使用。
Namenode在HDFS是单点存在，如果Namenode所在的机器错误，手工的干预是必须的。目前，在另一台机器上重启因故障而停止服务的Namenode这个功能还没实现。
5、快照
快照支持某个时间的数据拷贝，当HDFS数据损坏的时候，可以恢复到过去一个已知正确的时间点。HDFS目前还不支持快照功能。
八、数据组织
1、数据块
兼容HDFS的应用都是处理大数据集合的。这些应用都是写数据一次，读却是一次到多次，并且读的速度要满足流式读。HDFS支持文件的write- once-read-many语义。一个典型的block大小是64MB，因而，文件总是按照64M切分成chunk，每个chunk存储于不同的 Datanode
2、步骤
某个客户端创建文件的请求其实并没有立即发给Namenode，事实上，HDFS客户端会将文件数据缓存到本地的一个临时文件。应用的写被透明地重定向到这个临时文件。当这个临时文件累积的数据超过一个block的大小（默认64M)，客户端才会联系Namenode。Namenode将文件名插入文件系统的层次结构中，并且分配一个数据块给它，然后返回Datanode的标识符和目标数据块给客户端。客户端将本地临时文件flush到指定的 Datanode上。当文件关闭时，在临时文件中剩余的没有flush的数据也会传输到指定的Datanode，然后客户端告诉Namenode文件已经关闭。此时Namenode才将文件创建操作提交到持久存储。如果Namenode在文件关闭前挂了，该文件将丢失。
上述方法是对通过对HDFS上运行的目标应用认真考虑的结果。如果不采用客户端缓存，由于网络速度和网络堵塞会对吞估量造成比较大的影响。
3、流水线复制
当某个客户端向HDFS文件写数据的时候，一开始是写入本地临时文件，假设该文件的replication因子设置为3，那么客户端会从Namenode 获取一张Datanode列表来存放副本。然后客户端开始向第一个Datanode传输数据，第一个Datanode一小部分一小部分（4kb)地接收数据，将每个部分写入本地仓库，并且同时传输该部分到第二个Datanode节点。第二个Datanode也是这样，边收边传，一小部分一小部分地收，存储在本地仓库，同时传给第三个Datanode，第三个Datanode就仅仅是接收并存储了。这就是流水线式的复制。
九、可访问性
HDFS给应用提供了多种访问方式，可以通过DFSShell通过命令行与HDFS数据进行交互，可以通过java API调用，也可以通过C语言的封装API访问，并且提供了浏览器访问的方式。正在开发通过WebDav协议访问的方式。具体使用参考文档。
十、空间的回收
1、文件的删除和恢复
用户或者应用删除某个文件，这个文件并没有立刻从HDFS中删除。相反，HDFS将这个文件重命名，并转移到/trash目录。当文件还在/trash目录时，该文件可以被迅速地恢复。文件在/trash中保存的时间是可配置的，当超过这个时间，Namenode就会将该文件从namespace中删除。文件的删除，也将释放关联该文件的数据块。注意到，在文件被用户删除和HDFS空闲空间的增加之间会有一个等待时间延迟。
当被删除的文件还保留在/trash目录中的时候，如果用户想恢复这个文件，可以检索浏览/trash目录并检索该文件。/trash目录仅仅保存被删除文件的最近一次拷贝。/trash目录与其他文件目录没有什么不同，除了一点：HDFS在该目录上应用了一个特殊的策略来自动删除文件，目前的默认策略是删除保留超过6小时的文件，这个策略以后会定义成可配置的接口。
2、Replication因子的减小
当某个文件的replication因子减小，Namenode会选择要删除的过剩的副本。下次心跳检测就将该信息传递给Datanode， Datanode就会移除相应的block并释放空间，同样，在调用setReplication方法和集群中的空闲空间增加之间会有一个时间延迟。
参考资料：
HDFS Java API: http://hadoop.apache.org/core/docs/current/api/
HDFS source code: http://hadoop.apache.org/core/version_control.html
二. 分布式计算（Map/Reduce）
分布式式计算，同样是一个宽泛的概念，在这里，它狭义的指代，按Google Map/Reduce框架所设计的分布式框架。在Hadoop中，分布式文件系统，很大程度上，是为各种分布式计算需求所服务的。我们说分布式文件系统就是加了分布式的文件系统，类似的定义推广到分布式计算上，我们可以将其视为增加了分布式支持的计算函数。从计算的角度上看，Map/Reduce框架接受各种格式的键值对文件作为输入，读取计算后，最终生成自定义格式的输出文件。而从分布式的角度上看，分布式计算的输入文件往往规模巨大，且分布在多个机器上，单机计算完全不可支撑且效率低下，因此Map/Reduce框架需要提供一套机制，将此计算扩展到无限规模的机器集群上进行。依照这样的定义，我们对整个Map/Reduce的理解，也可以分别沿着这两个流程去看。。。
在Map/Reduce框架中，每一次计算请求，被称为作业。在分布式计算Map/Reduce框架中，为了完成这个作业，它进行两步走的战略，首先是将其拆分成若干个Map任务，分配到不同的机器上去执行，每一个Map任务拿输入文件的一部分作为自己的输入，经过一些计算，生成某种格式的中间文件，这种格式，与最终所需的文件格式完全一致，但是仅仅包含一部分数据。因此，等到所有Map任务完成后，它会进入下一个步骤，用以合并这些中间文件获得最后的输出文件。此时，系统会生成若干个Reduce任务，同样也是分配到不同的机器去执行，它的目标，就是将若干个Map任务生成的中间文件为汇总到最后的输出文件中去。当然，这个汇总不总会像1 + 1 = 2那么直接了当，这也就是Reduce任务的价值所在。经过如上步骤，最终，作业完成，所需的目标文件生成。整个算法的关键，就在于增加了一个中间文件生成的流程，大大提高了灵活性，使其分布式扩展性得到了保证。。。
I. 术语对照
和分布式文件系统一样，Google、Hadoop和....我，各执一种方式表述统一概念，为了保证其统一性，特有下表。。。
| 文中翻译 |
Hadoop术语 |
Google术语 |
相关解释 |
| 作业 |
Job |
Job |
用户的每一个计算请求，就称为一个作业。 |
| 作业服务器 |
JobTracker |
Master |
用户提交作业的服务器，同时，它还负责各个作业任务的分配，管理所有的任务服务器。 |
| 任务服务器 |
TaskTracker |
Worker |
任劳任怨的工蜂，负责执行具体的任务。 |
| 任务 |
Task |
Task |
每一个作业，都需要拆分开了，交由多个服务器来完成，拆分出来的执行单位，就称为任务。 |
| 备份任务 |
Speculative Task |
Buckup Task |
每一个任务，都有可能执行失败或者缓慢，为了降低为此付出的代价，系统会未雨绸缪的实现在另外的任务服务器上执行同样一个任务，这就是备份任务。 |
II. 基本架构
与分布式文件系统类似，Map/Reduce的集群，也由三类服务器构成。其中作业服务器，在Hadoop中称为Job Tracker，在Google论文中称为Master。前者告诉我们，作业服务器是负责管理运行在此框架下所有作业的，后者告诉我们，它也是为各个作业分配任务的核心。与HDFS的主控服务器类似，它也是作为单点存在的，简化了负责的同步流程。具体的负责执行用户定义操作的，是任务服务器，每一个作业被拆分成很多的任务，包括Map任务和Reduce任务等，任务是具体执行的基本单元，它们都需要分配到合适任务服务器上去执行，任务服务器一边执行一边向作业服务器汇报各个任务的状态，以此来帮助作业服务器了解作业执行的整体情况，分配新的任务等等。。。
除了作业的管理者执行者，还需要有一个任务的提交者，这就是客户端。与分布式文件系统一样，客户端也不是一个单独的进程，而是一组API，用户需要自定义好自己需要的内容，经由客户端相关的代码，将作业及其相关内容和配置，提交到作业服务器去，并时刻监控执行的状况。。。
同作为Hadoop的实现，与HDFS的通信机制相同，Hadoop Map/Reduce也是用了协议接口来进行服务器间的交流。实现者作为RPC服务器，调用者经由RPC的代理进行调用，如此，完成大部分的通信，具体服务器的架构，和其中运行的各个协议状况，参见下图。从图中可以看到，与HDFS相比，相关的协议少了几个，客户端与任务服务器，任务服务器之间，都不再有直接通信关系。这并不意味着客户端就不需要了解具体任务的执行状况，也不意味着，任务服务器之间不需要了解别家任务执行的情形，只不过，由于整个集群各机器的联系比HDFS复杂的多，直接通信过于的难以维系，所以，都统一由作业服务器整理转发。另外，从这幅图可以看到，任务服务器不是一个人在战斗，它会像孙悟空一样招出一群宝宝帮助其具体执行任务。这样做的好处，个人觉得，应该有安全性方面的考虑，毕竟，任务的代码是用户提交的，数据也是用户指定的，这质量自然良莠不齐，万一碰上个搞破坏的，把整个任务服务器进程搞死了，就因小失大了。因此，放在单独的地盘进行，爱咋咋地，也算是权责明确了。。。
与分布式文件系统相比，Map/Reduce框架的还有一个特点，就是可定制性强。文件系统中很多的算法，都是很固定和直观的，不会由于所存储的内容不同而有太多的变化。而作为通用的计算框架，需要面对的问题则要复杂很多，在各种不同的问题、不同的输入、不同的需求之间，很难有一种包治百病的药能够一招鲜吃遍天。作为Map/Reduce框架而言，一方面要尽可能的抽取出公共的一些需求，实现出来。更重要的，是需要提供良好的可扩展机制，满足用户自定义各种算法的需求。Hadoop是由Java来实现的，因此通过反射来实现自定义的扩展，显得比较小菜一碟了。在JobConf类中，定义了大量的接口，这基本上是Hadoop Map/Reduce框架所有可定制内容的一次集中展示。在JobConf中，有大量set接口接受一个Class<? extends xxx>的参数，通常它都有一个默认实现的类，用户如果不满意，则可自定义实现。。。
III. 计算流程
如果一切都按部就班的进行，那么整个作业的计算流程，应该是作业的提交 -> Map任务的分配和执行 -> Reduce任务的分配和执行 -> 作业的完成。而在每个任务的执行中，又包含输入的准备 -> 算法的执行 -> 输出的生成，三个子步骤。沿着这个流程，我们可以很快的整理清晰整个Map/Reduce框架下作业的执行。。。
1、作业的提交
一个作业，在提交之前，需要把所有应该配置的东西都配置好，因为一旦提交到了作业服务器上，就陷入了完全自动化的流程，用户除了观望，最多也就能起一个监督作用，惩治一些不好好工作的任务。。。
基本上，用户在提交代码阶段，需要做的工作主要是这样的：
首先，书写好所有自定的代码，最起码，需要有Map和Reduce的执行代码。在Hadoop中，Map需要派生自Mapper<K1, V1, K2, V2>接口，Reduce需要派生自Reducer<K2, V2, K3, V3>接口。这里都是用的泛型，用以支持不同的键值类型。这两个接口都仅有一个方法，一个是map，一个是reduce，这两个方法都直接受四个参数，前两个是输入的键和值相关的数据结构，第三个是作为输出相关的数据结构，最后一个，是一个Reporter类的实例，实现的时候可以利用它来统计一些计数。除了这两个接口，还有大量可以派生的接口，比如分割的Partitioner<K2, V2>接口。。。
然后，需要书写好主函数的代码，其中最主要的内容就是实例化一个JobConf类的对象，然后调用其丰富的setXXX接口，设定好所需的内容，包括输入输出的文件路径，Map和Reduce的类，甚至包括读取写入文件所需的格式支持类，等等。。。
最后，调用JobClient的runJob方法，提交此JobConf对象。runJob方法会先行调用到JobSubmissionProtocol接口所定义的submitJob方法，将此作业，提交给作业服务器。接着，runJob开始循环，不停的调用JobSubmissionProtocol的getTaskCompletionEvents方法，获得TaskCompletionEvent类的对象实例，了解此作业各任务的执行状况。。。
2、Map任务的分配
当一个作业提交到了作业服务器上，作业服务器会生成若干个Map任务，每一个Map任务，负责将一部分的输入转换成格式与最终格式相同的中间文件。通常一个作业的输入都是基于分布式文件系统的文件（当然在单机环境下，文件系统单机的也可以...），因为，它可以很天然的和分布式的计算产生联系。而对于一个Map任务而言，它的输入往往是输入文件的一个数据块，或者是数据块的一部分，但通常，不跨数据块。因为，一旦跨了数据块，就可能涉及到多个服务器，带来了不必要的复杂性。。。
当一个作业，从客户端提交到了作业服务器上，作业服务器会生成一个JobInProgress对象，作为与之对应的标识，用于管理。作业被拆分成若干个Map任务后，会预先挂在作业服务器上的任务服务器拓扑树。这是依照分布式文件数据块的位置来划分的，比如一个Map任务需要用某个数据块，这个数据块有三份备份，那么，在这三台服务器上都会挂上此任务，可以视为是一个预分配。。。
关于任务管理和分配的大部分的真实功能和逻辑的实现，JobInProgress则依托JobInProgressListener和TaskScheduler的子类。TaskScheduler，顾名思义是用于任务分配的策略类（为了简化描述，用它代指所有TaskScheduler的子类...）。它会掌握好所有作业的任务信息，其assignTasks函数，接受一个TaskTrackerStatus作为参数，依照此任务服务器的状态和现有的任务状况，为其分配新的任务。而为了掌握所有作业相关任务的状况，TaskScheduler会将若干个JobInProgressListener注册到JobTracker中去，当有新的作业到达、移除或更新的时候，JobTracker会告知给所有的JobInProgressListener，以便它们做出相应的处理。。。
任务分配是一个重要的环节，所谓任务分配，就是将合适作业的合适任务分配到合适的服务器上。不难看出，里面蕴含了两个步骤，先是选择作业，然后是在此作业中选择任务。和所有分配工作一样，任务分配也是一个复杂的活。不良好的任务分配，可能会导致网络流量增加、某些任务服务器负载过重效率下降，等等。不仅如此，任务分配还是一个无一致模式的问题，不同的业务背景，可能需要不同的算法才能满足需求。因此，在Hadoop中，有很多TaskScheduler的子类，像Facebook，Yahoo，都为其贡献出了自家用的算法。在Hadoop中，默认的任务分配器，是JobQueueTaskScheduler类。它选择作业的基本次序是：Map Clean Up Task（Map任务服务器的清理任务，用于清理相关的过期的文件和环境...） -> Map Setup Task（Map任务服务器的安装任务，负责配置好相关的环境...） -> Map Tasks -> Reduce Clean Up Task -> Reduce Setup Task -> Reduce Tasks。在这个前提下，具体到Map任务的分配上来。当一个任务服务器工作的游刃有余，期待获得新的任务的时候，JobQueueTaskScheduler会按照各个作业的优先级，从最高优先级的作业开始分配。每分配一个，还会为其留出余量，已被不时之需。举一个例子：系统目前有优先级3、2、1的三个作业，每个作业都有一个可分配的Map任务，一个任务服务器来申请新的任务，它还有能力承载3个任务的执行，JobQueueTaskScheduler会先从优先级3的作业上取一个任务分配给它，然后再留出一个1任务的余量。此时，系统只能在将优先级2作业的任务分配给此服务器，而不能分配优先级1的任务。这样的策略，基本思路就是一切为高优先级的作业服务，优先分配不说，分配了好保留有余力以备不时之需，如此优待，足以让高优先级的作业喜极而泣，让低优先级的作业感慨既生瑜何生亮，甚至是活活饿死。。。
确定了从哪个作业提取任务后，具体的分配算法，经过一系列的调用，最后实际是由JobInProgress的findNewMapTask函数完成的。它的算法很简单，就是尽全力为此服务器非配且尽可能好的分配任务，也就是说，只要还有可分配的任务，就一定会分给它，而不考虑后来者。作业服务器会从离它最近的服务器开始，看上面是否还挂着未分配的任务（预分配上的），从近到远，如果所有的任务都分配了，那么看有没有开启多次执行，如果开启，考虑把未完成的任务再分配一次（后面有地方详述...）。。。
对于作业服务器来说，把一个任务分配出去了，并不意味着它就彻底解放，可以对此任务可以不管不顾了。因为任务可以在任务服务器上执行失败，可能执行缓慢，这都需要作业服务器帮助它们再来一次。因此在Task中，记录有一个TaskAttemptID，对于任务服务器而言，它们每次跑的，其实都只是一个Attempt而已，Reduce任务只需要采信一个的输出，其他都算白忙乎了。。。
3、Map任务的执行
与HDFS类似，任务服务器是通过心跳消息，向作业服务器汇报此时此刻其上各个任务执行的状况，并向作业服务器申请新的任务的。具体实现，是TaskTracker调用InterTrackerProtocol协议的heartbeat方法来做的。这个方法接受一个TaskTrackerStatus对象作为参数，它描述了此时此任务服务器的状态。当其有余力接受新的任务的时候，它还会传入acceptNewTasks为true的参数，表示希望作业服务器委以重任。JobTracker接收到相关的参数后，经过处理，会返回一个HeartbeatResponse对象。这个对象中，定义了一组TaskTrackerAction，用于指导任务服务器进行下一步的工作。系统中已定义的了一堆其TaskTrackerAction的子类，有的对携带的参数进行了扩充，有的只是标明了下ID，具体不详写了，一看便知。。。
当TaskTracker收到的TaskTrackerAction中，包含了LaunchTaskAction，它会开始执行所分配的新的任务。在TaskTracker中，有一个TaskTracker.TaskLauncher线程（确切的说是两个，一个等Map任务，一个等Reduce任务），它们在痴痴的守候着新任务的来到。一旦等到了，会最终调用到Task的createRunner方法，构造出一个TaskRunner对象，新建一个线程来执行。对于一个Map任务，它对应的Runner是TaskRunner的子类MapTaskRunner，不过，核心部分都在TaskRunner的实现内。TaskRunner会先将所需的文件全部下载并拆包好，并记录到一个全局缓存中，这是一个全局的目录，可以供所有此作业的所有任务使用。它会用一些软链接，将一些文件名链接到这个缓存中来。然后，根据不同的参数，配置出一个JVM执行的环境，这个环境与JvmEnv类的对象对应。
接着，TaskRunner会调用JvmManager的launchJvm方法，提交给JvmManager处理。JvmManager用于管理该TaskTracker上所有运行的Task子进程。在目前的实现中，尝试的是池化的方式。有若干个固定的槽，如果槽没有满，那么就启动新的子进程，否则，就寻找idle的进程，如果是同Job的直接放进去，否则杀死这个进程，用一个新的进程代替。每一个进程都是由JvmRunner来管理的，它也是位于单独线程中的。但是从实现上看，这个机制好像没有部署开，子进程是死循环等待，而不会阻塞在父进程的相关线程上，父线程的变量一直都没有个调整，一旦分配，始终都处在繁忙的状况了。
真实的执行载体，是Child，它包含一个main函数，进程执行，会将相关参数传进来，它会拆解这些参数，并且构造出相关的Task实例，调用其run函数进行执行。每一个子进程，可以执行指定个数量的Task，这就是上面所说的池化的配置。但是，这套机制在我看来，并没有运行起来，每个进程其实都没有机会不死而执行新的任务，只是傻傻的等待进程池满，而被一刀毙命。也许是我老眼昏花，没看出其中实现的端倪。。。
4、Reduce任务的分配与执行
比之Map任务，Reduce的分配及其简单，基本上是所有Map任务完成了，有空闲的任务服务器，来了就给分配一个Job任务。因为Map任务的结果星罗棋布，且变化多端，真要搞一个全局优化的算法，绝对是得不偿失。而Reduce任务的执行进程的构造和分配流程，与Map基本完全的一致，没有啥可说的了。。。
但其实，Reduce任务与Map任务的最大不同，是Map任务的文件都在本地隔着，而Reduce任务需要到处采集。这个流程是作业服务器经由此Reduce任务所处的任务服务器，告诉Reduce任务正在执行的进程，它需要的Map任务执行过的服务器地址，此Reduce任务服务器会于原Map任务服务器联系（当然本地就免了...），通过FTP服务，下载过来。这个隐含的直接数据联系，就是执行Reduce任务与执行Map任务最大的不同了。。。
5、作业的完成
当所有Reduce任务都完成了，所需数据都写到了分布式文件系统上，整个作业才正式完成了。此中，涉及到很多的类，很多的文件，很多的服务器，所以说起来很费劲，话说，一图解千语，说了那么多，我还是画两幅图，彻底表达一下吧。。。
首先，是一个时序图。它模拟了一个由3个Map任务和1个Reduce任务构成的作业执行流程。我们可以看到，在执行的过程中，只要有人太慢，或者失败，就会增加一次尝试，以此换取最快的执行总时间。一旦所有Map任务完成，Reduce开始运作（其实，不一定要这样的...），对于每一个Map任务来说，只有执行到Reduce任务把它上面的数据下载完成，才算成功，否则，都是失败，需要重新进行尝试。。。
而第二副图，不是我画的，就不转载了，参见
这里，它描述了整个Map/Reduce的服务器状况图，包括整体流程、所处服务器进程、输入输出等，看清楚这幅图，对Map/Reduce的基本流程应该能完全跑通了。有这几点，可能图中描述的不够清晰需要提及一下，一个是在HDFS中，其实还有日志文件，图中没有标明；另一个是步骤5，其实是由TaskTracker主动去拉取而不是JobTracker推送过来的；还有步骤8和步骤11，创建出来的MapTask和ReduceTask，在Hadoop中都是运行在独立的进程上的。。。
IV. Map任务详请
从上面，可以了解到整个Map和Reduce任务的整体流程，而后面要啰嗦的，是具体执行中的细节。Map任务的输入，是分布式文件系统上的，包含键值对信息的文件。为了给每一个Map任务指定输入，我们需要掌握文件格式把它分切成块，并从每一块中分离出键值信息。在HDFS中，输入的文件格式，是由InputFormat<K, V>类来表示的，在JobConf中，它的默认值是TextInputFormat类（见getInputFormat），此类是特化的FileInputFormat<LongWritable, Text>子类，而FileInputFormat<K, V>正是InputFormat<K, V>的子类。通过这样的关系我们可以很容易的理解，默认的文件格式是文本文件，且键是LongWritable类型（整形数），值是Text类型（字符串）。仅仅知道文件类型是不够的，我们还需要将文件中的每一条数据，分离成键值对，这个工作，是RecordReader<K, V>来做的。在TextInputFormat的getRecordReader方法中我们可以看到，与TextInputFormat默认配套使用的，是LineRecordReader类，是特化的RecordReader<LongWritable, Text>的子类，它将每一行作为一个记录，起始的位置作为键，整行的字符串作为值。有了格式，分出了键值，还需要切开分给每一个Map任务。每一个Map任务的输入用InputSplit接口表示，对于一个文件输入而言，其实现是FileSplit，它包含着文件名、起始位置、长度和存储它的一组服务器地址。。。
当Map任务拿到所属的InputSplit后，就开始一条条读取记录，并调用用于定义的Mapper，进行计算（参见MapRunner<K1, V1, K2, V2>和MapTask的run方法），然后，输出。MapTask会传递给Mapper一个OutputCollector<K, V>对象，作为输出的数据结构。它定义了一个collect的函数，接受一个键值对。在MapTask中，定义了两个OutputCollector的子类，一个是MapTask.DirectMapOutputCollector<K, V>，人如其名，它的实现确实很Direct，直截了当。它会利用一个RecordWriter<K, V>对象，collect一调用，就直接调用RecordWriter<K, V>的write方法，写入本地的文件中去。如果觉着RecordWriter<K, V>出现的很突兀，那么看看上一段提到的RecordReader<K, V>，基本上，数据结构都是对应着的，一个是输入一个是输出。输出很对称也是由RecordWriter<K, V>和OutputFormat<K, V>来协同完成的，其默认实现是LineRecordWriter<K, V>和TextOutputFormat<K, V>，多么的眼熟啊。。。
除了这个非常直接的实现之外，MapTask中还有一个复杂的多的实现，是MapTask.MapOutputBuffer<K extends Object, V extends Object>。有道是简单压倒一切，那为什么有很简单的实现，要琢磨一个复杂的呢。原因在于，看上去很美的往往带着刺，简单的输出实现，每调用一次collect就写一次文件，频繁的硬盘操作很有可能导致此方案的低效。为了解决这个问题，这就有了这个复杂版本，它先开好一段内存做缓存，然后制定一个比例做阈值，开一个线程监控此缓存。collect来的内容，先写到缓存中，当监控线程发现缓存的内容比例超过阈值，挂起所有写入操作，建一个新的文件，把缓存的内容批量刷到此文件中去，清空缓存，重新开放，接受继续collect。。。
为什么说是刷到文件中去呢。因为这不是一个简单的照本宣科简单复制的过程，在写入之前，会先将缓存中的内存，经过排序、合并器（Combiner）统计之后，才会写入。如果你觉得Combiner这个名词听着太陌生，那么考虑一下Reducer，Combiner也就是一个Reducer类，通过JobConf的setCombinerClass进行设置，在常用的配置中，Combiner往往就是用用户为Reduce任务定义的那个Reducer子类。只不过，Combiner只是服务的范围更小一些而已，它在Map任务执行的服务器本地，依照Map处理过的那一小部分数据，先做一次Reduce操作，这样，可以压缩需要传输内容的大小，提高速度。每一次刷缓存，都会开一个新的文件，等此任务所有的输入都处理完成后，就有了若干个有序的、经过合并的输出文件。系统会将这些文件搞在一起，再做一个多路的归并外排，同时使用合并器进行合并，最终，得到了唯一的、有序的、经过合并的中间文件（注：文件数量等同于分类数量，在不考虑分类的时候，简单的视为一个...）。它，就是Reduce任务梦寐以求的输入文件。。。
除了做合并，复杂版本的OutputCollector，还具有分类的功能。分类，是通过Partitioner<K2, V2>来定义的，默认实现是HashPartitioner<K2, V2>，作业提交者可以通过JobConf的setPartitionerClass来自定义。分类的含义是什么呢，简单的说，就是将Map任务的输出，划分到若干个文件中（通常与Reduce任务数目相等），使得每一个Reduce任务，可以处理某一类文件。这样的好处是大大的，举一个例子说明一下。比如有一个作业是进行单词统计的，其Map任务的中间结果应该是以单词为键，以单词数量为值的文件。如果这时候只有一个Reduce任务，那还好说，从全部的Map任务那里收集文件过来，分别统计得到最后的输出文件就好。但是，如果单Reduce任务无法承载此负载或效率太低，就需要多个Reduce任务并行执行。此时，再沿用之前的模式就有了问题。每个Reduce任务从一部分Map任务那里获得输入文件，但最终的输出结果并不正确，因为同一个单词可能在不同的Reduce任务那里都有统计，需要想方法把它们统计在一起才能获得最后结果，这样就没有将Map/Reduce的作用完全发挥出来。这时候，就需要用到分类。如果此时有两个Reduce任务，那么将输出分成两类，一类存放字母表排序较高的单词，一类存放字母表排序低的单词，每一个Reduce任务从所有的Map任务那里获取一类的中间文件，得到自己的输出结果。最终的结果，只需要把各个Reduce任务输出的，拼接在一起就可以了。本质上，这就是将Reduce任务的输入，由垂直分割，变成了水平分割。Partitioner的作用，正是接受一个键值，返回一个分类的序号。它会在从缓存刷到文件之前做这个工作，其实只是多了一个文件名的选择而已，别的逻辑都不需要变化。。。
除了缓存、合并、分类等附加工作之外，复杂版本的OutputCollector还支持错误数据的跳过功能，在后面分布式将排错的时候，还会提及，标记一下，按下不表。。。
V. Reduce任务详情
理论上看，Reduce任务的整个执行流程要比Map任务更为的罗嗦一些，因为，它需要收集输入文件，然后才能进行处理。Reduce任务，主要有这么三个步骤：Copy、Sort、Reduce（参见ReduceTask的run方法）。所谓Copy，就是从执行各个Map任务的服务器那里，收罗到本地来。拷贝的任务，是由ReduceTask.ReduceCopier类来负责，它有一个内嵌类，叫MapOutputCopier，它会在一个单独的线程内，负责某个Map任务服务器上文件的拷贝工作。远程拷贝过来的内容（当然也可以是本地了...），作为MapOutput对象存在，它可以在内存中也可以序列化在磁盘上，这个根据内存使用状况来自动调节。整个拷贝过程是一个动态的过程，也就是说它不是一次给好所有输入信息就不再变化了。它会不停的调用TaskUmbilicalProtocol协议的getMapCompletionEvents方法，向其父TaskTracker询问此作业个Map任务的完成状况（TaskTracker要向JobTracker询问后再转告给它...）。当获取到相关Map任务执行服务器的信息后，都会有一个线程开启，做具体的拷贝工作。同时，还有一个内存Merger线程和一个文件Merger线程在同步工作，它们将新鲜下载过来的文件（可能在内存中，简单的统称为文件...），做着归并排序，以此，节约时间，降低输入文件的数量，为后续的排序工作减负。。。
Sort，排序工作，就相当于上述排序工作的一个延续。它会在所有的文件都拷贝完毕后进行，因为虽然同步有做着归并的工作，但可能留着尾巴，没做彻底。经过这一个流程，该彻底的都彻底了，一个崭新的、合并了所有所需Map任务输出文件的新文件，诞生了。而那些千行万苦从其他各个服务器网罗过来的Map任务输出文件，很快的结束了它们的历史使命，被扫地出门一扫而光，全部删除了。。。
所谓好戏在后头，Reduce任务的最后一个阶段，正是Reduce本身。它也会准备一个OutputCollector收集输出，与MapTask不同，这个OutputCollector更为简单，仅仅是打开一个RecordWriter，collect一次，write一次。最大的不同在于，这次传入RecordWriter的文件系统，基本都是分布式文件系统，或者说是HDFS。而在输入方面，ReduceTask会从JobConf那里调用一堆getMapOutputKeyClass、getMapOutputValueClass、getOutputKeyComparator等等之类的自定义类，构造出Reducer所需的键类型，和值的迭代类型Iterator（一个键到了这里一般是对应一组值）。具体实现颇为拐弯抹角，建议看一下Merger.MergeQueue，RawKeyValueIterator，ReduceTask.ReduceValuesIterator等等之类的实现。有了输入，有了输出，不断循环调用自定义的Reducer，最终，Reduce阶段完成。。。
VI. 分布式支持
1、服务器正确性保证
Hadoop Map/Reduce服务器状况和HDFS很类似，由此可知，救死扶伤的方法也是大同小异。废话不多说了，直接切正题。同作为客户端，Map/Reduce的客户端只是将作业提交，就开始搬个板凳看戏，没有占茅坑的行动。因此，一旦它挂了，也就挂了，不伤大雅。而任务服务器，也需要随时与作业服务器保持心跳联系，一旦有了问题，作业服务器可以将其上运行的任务，移交给它人完成。作业服务器，作为一个单点，非常类似的是利用还原点（等同于HDFS的镜像）和历史记录（等同于HDFS的日志），来进行恢复。其上，需要持久化用于恢复的内容，包含作业状况、任务状况、各个任务尝试的工作状况等。有了这些内容，再加上任务服务器的动态注册，就算挪了个窝，还是很容易恢复的。JobHistory是历史记录相关的一个静态类，本来，它也就是一个干写日志活的，只是在Hadoop的实现中，对日志的写入做了面向对象的封装，同时又大量用到观察者模式做了些嵌入，使得看起来不是那么直观。本质上，它就是打开若干个日志文件，利用各类接口来往里面写内容。只不过，这些日志，会放在分布式文件系统中，就不需要像HDFS那样，来一个SecondXXX随时候命，由此可见，有巨人在脚下踩着，真好。JobTracker.RecoveryManager类是作业服务器中用于进行恢复相关的事情，当作业服务器启动的时候，会调用其recover方法，恢复日志文件中的内容。其中步骤，注释中写的很清楚，请自行查看。。。
2、任务执行的正确和速度
整个作业流程的执行，秉承着木桶原理。执行的最慢的Map任务和Reduce任务，决定了系统整体执行时间（当然，如果执行时间在整个流程中占比例很小的话，也许就微不足道了...）。因此，尽量加快最慢的任务执行速度，成为提高整体速度关键。所使用的策略，简约而不简单，就是一个任务多次执行。当所有未执行的任务都分配出去了，并且先富起来的那部分任务已经完成了，并还有任务服务器孜孜不倦的索取任务的时候，作业服务器会开始炒剩饭，把那些正在吭哧吭哧在某个服务器上慢慢执行的任务，再把此任务分配到一个新的任务服务器上，同时执行。两个服务器各尽其力，成王败寇，先结束者的结果将被采纳。这样的策略，隐含着一个假设，就是我们相信，输入文件的分割算法是公平的，某个任务执行慢，并不是由于这个任务本身负担太重，而是由于服务器不争气负担太重能力有限或者是即将撒手西去，给它换个新环境，人挪死树挪活事半功倍。。。
当然，肯定有哽咽的任务，不论是在哪个服务器上，都无法顺利完成。这就说明，此问题不在于服务器上，而是任务本身天资有缺憾。缺憾在何处？每个作业，功能代码都是一样的，别的任务成功了，就是这个任务不成功，很显然，问题出在输入那里。输入中有非法的输入条目，导致程序无法辨识，只能挥泪惜别。说到这里，解决策略也浮出水面了，三十六计走位上，惹不起，还是躲得起的。在MapTask中的MapTask.SkippingRecordReader<K, V>和ReduceTask里的ReduceTask.SkippingReduceValuesIterator<KEY,VALUE>，都是用于干这个事情的。它们的原理很简单，就是在读一条记录前，把当前的位置信息，封装成SortedRanges.Range对象，经由Task的reportNextRecordRange方法提交到TaskTracker上去。TaskTracker会把这些内容，搁在TaskStatus对象中，随着心跳消息，汇报到JobTracker上面。这样，作业服务器就可以随时随刻了解清楚，每个任务正读取在那个位置，一旦出错，再次执行的时候，就在分配的任务信息里面添加一组SortedRanges信息。MapTask或ReduceTask读取的时候，会看一下这些区域，如果当前区域正好处于上述雷区，跳过不读。如此反复，正可谓，道路曲折，前途光明啊。。。
VII. 总结
对于Map/Reduce而言，真正的困难，在于提高其适应能力，打造一款能够包治百病的执行框架。Hadoop已经做得很好了，但只有真正搞清楚了整个流程，你才能帮助它做的更好。。。
所谓分布式，在这里，很狭义的指代以Google的三驾马车，
GFS、
Map/Reduce、
BigTable为框架核心的分布式存储和计算系统。通常如我一样初学的人，会以Google这几份经典的论文作为开端的。它们勾勒出了分布式存储和计算的一个基本蓝图，已可窥见其几分风韵，但终究还是由于缺少一些实现的代码和示例，色彩有些斑驳，缺少了点感性。幸好我们还有Open Source，还有Hadoop。
Hadoop是一个基于Java实现的，开源的，分布式存储和计算的项目。作为这个领域最富盛名的开源项目之一，它的使用者也是大牌如云，包括了Yahoo，Amazon，Facebook等等（好吧，还可能有校内，不过这真的没啥分量...）。Hadoop本身，实现的是分布式的文件系统HDFS，和分布式的计算（Map/Reduce）框架，此外，它还不是一个人在战斗，Hadoop包含一系列扩展项目，包括了分布式文件数据库
HBase（对应Google的BigTable），分布式协同服务
ZooKeeper（对应Google的
Chubby），等等。。。
如此，一个看上去不错的黄金搭档浮出水面，Google的论文 + Hadoop的实现，顺着论文的框架看具体的实现，用实现来进一步理解论文的逻辑，看上去至少很美。网上有很多前辈们，做过Hadoop相关的源码剖析工作，我关注最多的是
这里，目前博主已经完成了HDFS的剖析工作，Map/Reduce的剖析正火热进行中，更新频率之高，剖析之详尽，都是难得一见的，所以，走过路过一定不要错过了。此外，还有很多Hadoop的关注者和使用者贴过相关的文章，比如：
这里，
这里。也可以去
Hadoop的中文站点（不知是民间还是官方...），搜罗一些学习资料。。。
我个人从上述资料中受益匪浅，而我自己要做的整理，与原始的源码剖析有些不同，不是依照实现的模块，而是基于论文的脉络和实现这样系统的基本脉络来进行的，也算，从另一个角度给出一些东西吧。鉴于个人对于分布式系统的理解非常的浅薄，缺少足够的实践经验，深入的问题就不班门弄斧了，仅做梳理和解析，大牛至此，可绕路而行了。。。
一. 分布式文件系统
分布式文件系统，在整个分布式系统体系中处于最低层最基础的地位，存储嘛，没了数据，再好的计算平台，再完善的数据库系统，都成了无水之舟了。那么，什么是分布式文件系统，顾名思义，就是分布式+文件系统。它包含这两个方面的内涵，从文件系统的客户使用的角度来看，它就是一个标准的文件系统，提供了一系列API，由此进行文件或目录的创建、移动、删除，以及对文件的读写等操作。从内部实现来看，分布式的系统则不再和普通文件系统一样负责管理本地磁盘，它的文件内容和目录结构都不是存储在本地磁盘上，而是通过网络传输到远端系统上。并且，同一个文件存储不只是在一台机器上，而是在一簇机器上分布式存储，协同提供服务，正所谓分布式。。。
因此，考量一个分布式文件系统的实现，其实不妨可以从这两方面来分别剖析，而后合二为一。首先，看它如何去实现文件系统所需的基本增删改查的功能。然后，看它如何考虑分布式系统的特点，提供更好的容错性，负载平衡，等等之类的。这二者合二为一，就明白了一个分布式文件系统，整体的实现模式。。。
I. 术语对照
说任何东西，都需要统一一下语言先，不然明明说的一个意思，却容易被理解到另一个地方去。Hadoop的分布式文件系统HDFS，基本是按照Google论文中的GFS的架构来实现的。但是，HDFS为了彰显其不走寻常路的本性，其中的大量术语，都与GFS截然不同。明明都是一个枝上长的土豆，它偏偏就要叫山药蛋，弄得水火不容的，苦了我们看客。秉承老好人，谁也不得罪的方针，文中，既不采用GFS的叫法，也不采用Hadoop的称谓，而是另辟蹊径，自立门户，搞一套自己的中文翻译，为了避免不必要的痛楚，特此先来一帖术语对照表，要不懂查一查，包治百病。。。
| 文中所用翻译 |
HDFS中的术语 |
GFS中的术语 |
术语解释 |
| 主控服务器 |
NameNode |
Master |
整个文件系统的大脑，它提供整个文件系统的目录信息，并且管理各个数据服务器。 |
| 数据服务器 |
DataNode |
Chunk Server |
分布式文件系统中的每一个文件，都被切分成若干个数据块，每一个数据块都被存储在不同的服务器上，此服务器称之为数据服务器。 |
| 数据块 |
Block |
Chunk |
每个文件都会被切分成若干个块，每一块都有连续的一段文件内容，是存储的基恩单位，在这里统一称做数据块。 |
| 数据包 |
Packet |
无 |
客户端写文件的时候，不是一个字节一个字节写入文件系统的，而是累计到一定数量后，往文件系统中写入一次，每发送一次的数据，都称为一个数据包。 |
| 传输块 |
Chunk |
无 |
在每一个数据包中，都会将数据切成更小的块，每一个块配上一个奇偶校验码，这样的块，就是传输块。 |
| 备份主控服务器 |
SecondaryNameNode |
无 |
备用的主控服务器，在身后默默的拉取着主控服务器 的日志，等待主控服务器牺牲后被扶正。 |
*注：本文采用的Hadoop是0.19.0版本。
II. 基本架构
1. 服务器介绍
与单机的文件系统不同，分布式文件系统不是将这些数据放在一块磁盘上，由上层操作系统来管理。而是存放在一个服务器集群上，由集群中的服务器，各尽其责，通力合作，提供整个文件系统的服务。其中重要的服务器包括：主控服务器（Master/NameNode），数据服务器（ChunkServer/DataNode），和客户服务器。HDFS和GFS都是按照这个架构模式搭建的。个人觉得，其中设计的最核心内容是：文件的目录结构独立存储在一个主控服务器上，而具体文件数据，拆分成若干块，冗余的存放在不同的数据服务器上。
存储目录结构的主控服务器，在GFS中称为Master，在HDFS中称为NameNode。这两个名字，叫得都有各自的理由，是瞎子摸象各表一面。Master是之于数据服务器来叫的，它做为数据服务器的领导同志存在，管理各个数据服务器，收集它们的信息，了解所有数据服务器的生存现状，然后给它们分配任务，指挥它们齐心协力为系统服务；而NameNode是针对客户端来叫的，对于客户端而言，主控服务器上放着所有的文件目录信息，要找一个文件，必须问问它，由此而的此名。。。
主控服务器在整个集群中，同时提供服务的只存在一个，如果它不幸牺牲的话，会有后备军立刻前赴后继的跟上，但，同一时刻，需要保持一山不容二虎的态势。这种设计策略，避免了多台服务器间即时同步数据的代价，而同时，它也使得主控服务器很可能成为整个架构的瓶颈所在。因此，尽量为主控服务器减负，不然它做太多的事情，就自然而然的晋升成了一个分布式文件系统的设计要求。。。
每一个文件的具体数据，被切分成若干个数据块，冗余的存放在数据服务器。通常的配置，每一个数据块的大小为64M，在三个数据服务器上冗余存放（这个64M，不是随便得来的，而是经过反复实践得到的。因为如果太大，容易造成热点的堆叠，大量的操作集中在一台数据服务器上，而如果太小的话，附加的控制信息传输成本，又太高了。因此没有比较特定的业务需求，可以考虑维持此配置...）。数据服务器是典型的四肢发达头脑简单的苦力，其主要的工作模式就是定期向主控服务器汇报其状况，然后等待并处理命令，更快更安全的存放好数据。。。
此外，整个分布式文件系统还有一个重要角色是客户端。它不和主控服务和数据服务一样，在一个独立的进程中提供服务，它只是以一个类库（包）的模式存在，为用户提供了文件读写、目录操作等APIs。当用户需要使用分布式文件系统进行文件读写的时候，把客户端相关包给配置上，就可以通过它来享受分布式文件系统提供的服务了。。。
2. 数据分布
一个文件系统中，最重要的数据，其实就是整个文件系统的目录结构和具体每个文件的数据。具体的文件数据被切分成数据块，存放在数据服务器上。每一个文件数据块，在数据服务器上都表征为出双入队的一对文件（这是普通的Linux文件），一个是数据文件，一个是附加信息的元文件，在这里，不妨把这对文件简称为
数据块文件。数据块文件存放在
数据目录下，它有一个名为current的根目录，然后里面有若干个数据块文件和从dir0-dir63的最多64个的子目录，子目录内部结构等同于current目录，依次类推（更详细的描述，参见
这里）。个人觉得，这样的架构，有利于控制同一目录下文件的数量，加快检索速度。。。
这是磁盘上的物理结构，与之对应的，是内存中的数据结构，用以表征这样的磁盘结构，方便读写操作的进行。
Block类用于表示数据块，而FSDataset类是数据服务器管理文件块的数据结构，其中，FSDataset.FSDir对应着数据块文件和目录，FSDataset.FSVolume对应着一个数据目录，FSDataset.FSVolumeSet是FSVolume的集合，每一个FSDataset有一个FSVolumeSet。多个数据目录，可以放在不同的磁盘上，这样有利于加快磁盘操作的速度。相关的类图，可以参看这里 。。。此外，与FSVolume对应的，还有一个数据结构，就是
DataStorage，它是
Storage的子类，提供了升级、回滚等支持。但与FSVolume不一样，它不需要了解数据块文件的具体内容，它只知道有这么一堆文件放这里，会有不同版本的升级需求，它会处理怎么把它们升级回滚之类的业务（关于Storage，可以参见
这里）。而FSVolume提供的接口，都基本上是和Block相关的。。。
相比数据服务器，主控服务器的数据量不大，但逻辑更为复杂。主控服务器主要有三类数据：文件系统的目录结构数据，各个文件的分块信息，数据块的位置信息（就数据块放置在哪些数据服务器上...）。在GFS和HDFS的架构中，只有文件的目录结构和分块信息才会被持久化到本地磁盘上，而数据块的位置信息则是通过动态汇总过来的，仅仅存活在内存数据结构中，机器挂了，就灰飞烟灭了。每一个数据服务器启动后，都会向主控服务器发送注册消息，将其上数据块的状况都告知于主控服务器。俗话说，简单就是美，根据DRY原则，保存的冗余信息越少，出现不一致的可能性越低，付出一点点时间的代价，换取了一大把逻辑上的简单性，绝对应该是一个包赚不赔的买卖。。。
在HDFS中，FSNamespacesystem类就负责保管文件系统的目录结构以及每个文件的分块状况的，其中，前者是由FSDirectory类来负责，后者是各个INodeFile本身维护。在INodeFile里面，有一个BlockInfo的数组，保存着与该文件相关的所有数据块信息，BlockInfo中包含了从数据块到数据服务器的映射，INodeFile只需要知道一个偏移量，就可以提供相关的数据块，和数据块存放的数据服务器信息。。。
3、服务器间协议
在Hadoop的实现中，部署了一套RPC机制，以此来实现各服务间的通信协议。在Hadoop中，每一对服务器间的通信协议，都定义成为一个接口。服务端的类实现该接口，并且建立RPC服务，监听相关的接口，在独立的线程处理RPC请求。客户端则可以实例化一个该接口的代理对象，调用该接口的相应方法，执行一次同步的通信，传入相应参数，接收相应的返回值。基于此RPC的通信模式，是一个消息拉取的流程，RPC服务器等待RPC客户端的调用，而不会先发制人主动把相关信息推送到RPC客户端去。。。
其实RPC的模式和原理，实在是没啥好说的，之所以说，是因为可以通过把握好这个，彻底理顺Hadoop各服务器间的通信模式。Hadoop会定义一些列的RPC接口，只需要看谁实现，谁调用，就可以知道谁和谁通信，都做些啥事情，图中服务器的基本架构、各服务所使用的协议、调用方向、以及协议中的基本内容。。。
III. 基本的文件操作
基本的文件操作，可以分成两类，一个是对文件目录结构的操作，比如文件和目录的创建、删除、移动、更名等等；另一个是对文件数据流的操作，包括读取和写入文件数据。当然，文件读和写，是有本质区别的，尤其是在数据冗余的情况下，因此，当成两类操作也不足为过。此外，要具体到读写的类别，也是可以再继续分类下去的。在GFS的论文中，对于分布式文件系统的读写场景有一个重要的假定（其实是从实际业务角度得来的...）：就是文件的读取是由大数据量的连续读取和小数据量的随机读取组成，文件的写入则基本上都是批量的追加写，和偶尔的插入写（GFS中还有大量的假设，它们构成了分布式文件系统架构设计的基石。每一个系统架构都是搭建在一定假设上的，这些假设有些来自于实际业务的状况，有些是因为天生的条件约束，不基于假设理解设计，肯定会有失偏颇...）。在GFS中，对文件的写入分成追加写和插入写都有所支持，但是，在HDFS中仅仅支持追加写，这大大降低了复杂性。关于HDFS与GFS的一些不同，可以参看
这里。。。
1. 文件和目录的操作
文件目录的信息，全部囤积在主控服务器上，因此，所有对文件目录的操作，只会直接涉及到客户端和主控服务器。整个目录相关的操作流程基本都是这样的：客户端DFSClient调用ClientProtocol定义的相关函数，该操作通过RPC传送到其实现者主控服务器NameNode那里，NameNode做相关的处理后（很少...），调用FSNamesystem的相关函数。在FSNamesystem中，往往是做一些验证和租约操作，具体的目录结构操作交由FSDirectory的相应函数来操作。最后，依次返回，经由RPC传送回客户端。具体各操作涉及到的函数和具体步骤，参见下表：
| 相关操作 |
ClientProtocol / NameNode |
FSNamesystem |
FSDirectory |
关键步骤 |
| 创建文件 |
create |
startFile |
addFile |
1. 检查是否有写权限；
2. 检查是否已经存在此文件，如果是覆写，则先进行删除操作；
3. 在指定路径下添加INodeFileUnderConstruction的文件实例；
4. 写日志；
5. 签订租约。 |
| 创建目录 |
mkdirs |
mkdirs |
mkdirs |
1. 检查指定目录是否是目录；
2. 检查是否有相关权限；
3. 在指定路径的INode下，添加子节点；
4. 写日志。 |
| 改名操作 |
rename |
renameTo |
renameTo |
1. 检查相关路径的权限；
2. 从老路径下移除，在新路径下添加；
3. 修改相关父路径的修改时间；
4. 写日志；
5. 将租约从老路径移动到新路径下。 |
| 删除操作 |
delete |
delete |
delete |
1. 如果不是递归删除，确认指定路径是否是空目录；
2. 检查相关权限；
3. 在目录结构上移除相关INode；
4. 修改父路径的修改时间；
5. 将相关的数据块，放入到废弃队列中去，等待处理；
6. 写日志；
7. 废弃相关路径的租约。 |
| 设置权限 |
setPermission |
setPermission |
setPermission |
1. 检查owner判断是否有操作权限；
2. 修改指定路径下INode的权限；
3. 写日志。 |
| 设置用户 |
setOwner |
setOwner |
setOwner |
1. 检查是否有操作权限；
2. 修改指定路径下INode的权限；
3. 写日志。 |
| 设置时间 |
setTimes |
setTimes |
setTimes |
1. 检查是否有写权限；
2. 修改指定路径INode的时间信息；
3. 写日志。 |
从上表可以看到，其实有的操作本质上还是涉及到了数据服务器，比如文件创建和删除操作。但是，之前提到，主控服务器只于数据服务器是一个等待拉取的地位，它们不会主动联系数据服务器，将指令传输给它们，而是放到相应的数据结构中，等待数据服务器来取。这样的设计，可以减少通信的次数，加快操作的执行速度。。。
另，上述步骤中，有些日志和租约相关的操作，从概念上来说，和目录操作其实没有任何联系，但是，为了满足分布式系统的需求，这些操作是非常有必要的，在此，按下不表。。。
2、文件的读取
不论是文件读取，还是文件的写入，主控服务器扮演的都是中介的角色。客户端把自己的需求提交给主控服务器，主控服务器挑选合适的数据服务器，介绍给客户端，让客户端和数据服务器单聊，要读要写随你们便。这种策略类似于DMA，降低了主控服务器的负载，提高了效率。。。
因此，在文件读写操作中，最主要的通信，发生在客户端与数据服务器之间。它们之间跑的协议是
ClientDatanodeProtocol。从这个协议中间，你无法看到和读写相关的接口，因为，在Hadoop中，
读写操作是不走RPC机制的，而是另立门户，独立搭了一套通信框架。在数据服务器一端，
DataNode类中有一个
DataXceiverServer类的实例，它在一个单独的线程等待请求，一旦接到，就启动一个
DataXceiver的线程，处理此次请求。一个请求一个线程，对于数据服务器来说，逻辑上很简单。当下，DataXceiver支持的请求类型有六种，具体的请求包和回复包格式，请参见
这里，
这里，
这里。在Hadoop的实现中，并没有用类来封装这些请求，而是按流的次序写下来，这给代码阅读带来挺多的麻烦，也对代码的维护带来一定的困难，不知道是出于何种考虑。。。
相比于写，文件的读取实在是一个简单的过程。在客户端DFSClient中，有一个DFSClient.DFSInputStream类。当需要读取一个文件的时候，会生成一个DFSInputStream的实例。它会先调用ClientProtocol定义getBlockLocations接口，提供给NameNode文件路径、读取位置、读取长度信息，从中取得一个LocatedBlocks类的对象，这个对象包含一组LocatedBlock，那里面有所规定位置中包含的所有数据块信息，以及数据块对应的所有数据服务器的位置信息。当读取开始后，DFSInputStream会先尝试从某个数据块对应的一组数据服务器中选出一个，进行连接。这个选取算法，在当下的实现中，非常简单，就是选出第一个未挂的数据服务器，并没有加入客户端与数据服务器相对位置的考量。读取的请求，发送到数据服务器后，自然会有DataXceiver来处理，数据被一个包一个包发送回客户端，等到整个数据块的数据都被读取完了，就会断开此链接，尝试连接下一个数据块对应的数据服务器，整个流程，依次如此反复，直到所有想读的都读取完了为止。。。
3、文件的写入
文件读取是一个一对一的过程，一个客户端，只需要与一个数据服务器联系，就可以获得所需的内容。但是，写入操作，则是一个一对多的流程。一次写入，需要在所有存放相关数据块的数据服务器都保持同步的更新，有任何的差池，整个流程就告失败。。。
在分布式系统中，一旦涉及到写入操作，并发处理难免都会沦落成为一个变了相的串行操作。因为，如果不同的客户端如果是任意时序并发写入的话，整个写入的次序无法保证，可能你写半条记录我写半条记录，最后出来的结果乱七八糟不可估量。在HDFS中，并发写入的次序控制，是由主控服务器来把握的。当创建、续写一个文件的时候，该文件的节点类，由INodeFile升级成为INodeFileUnderConstruction，INodeFileUnderConstruction是INodeFile的子类，它起到一个锁的作用。如果当一个客户端想创建或续写的文件是INodeFileUnderConstruction，会引发异常，因为这说明这个此处有爷，请另寻高就，从而保持了并发写入的次序性。同时，INodeFileUnderConstruction有包含了此时正在操作它的客户端的信息以及最后一个数据块的数据服务器信息，当追加写的时候可以更快速的响应。。。
与读取类似，DFSClient也有一个DFSClient.DFSOutputStream类，写入开始，会创建此类的实例。DFSOutputStream会从NameNode上拿一个LocatedBlock，这里面有最后一个数据块的所有数据服务器的信息。这些数据服务器每一个都需要能够正常工作（对于读取，只要还有一个能工作的就可以实现...），它们会依照客户端的位置被排列成一个有着最近物理距离和最小的序列（物理距离，是根据机器的位置定下来的...），这个排序问题类似于著名旅行商问题，属于NP复杂度，但是由于服务器数量不多，所以用最粗暴的算法，也并不会看上去不美。。。
文件写入，就是在这一组数据服务器上构造成数据流的双向流水线。DFSOutputStream，会与序列的第一个数据服务器建立Socket连接，发送请求头，然后等待回应。DataNode同样是建立DataXceiver来处理写消息，DataXceiver会依照包中传过来的其他服务器的信息，建立与下一个服务器的连接，并生成类似的头，发送给它，并等待回包。此流程依次延续，直到最后一级，它发送回包，反向着逐级传递，再次回到客户端。如果一切顺利，那么此时，流水线建立成功，开始正式发送数据。数据是分成一个个数据包发送的，所有写入的内容，被缓存在客户端，当写满64K，会被封装成DFSOutputStream.Packet类实例，放入DFSOutputStream的dataQueue队列。DFSOutputStream.DataStreamer会时刻监听这个队列，一旦不为空，则开始发送，将位于dataQueue队首的包移动到ackQueue队列的队尾，表示已发送但尚未接受回复的包队列。同时启动ResponseProcessor线程监听回包，直到收到相应回包，才将发送包从ackQueue中移除，表示成功。每一个数据服务器的DataXceiver收到了数据包，一边写入到本地文件中去，一边转发给下一级的数据服务器，等待回包，同前面建立流水线的流程。。。
当一个数据块写满了之后，客户端需要向主控服务器申请追加新的数据块。这个会引起一次数据块的分配，成功后，会将新的数据服务器组返还给客户端。然后重新回到上述流程，继续前行。。。
关于写入的流程，还可以参见
这里。此外，写入涉及到租约问题，后续会仔细的来说。。。
IV. 分布式支持
如果单机的文件系统是田里勤恳的放牛娃，那么分布式文件系统就是刀尖上讨饭吃的马贼了。在分布式环境中，有太多的意外，数据随时传输错误，服务器时刻准备牺牲，很多平常称为异常的现象，在这里都需要按照平常事来对待。因此，对于分布式文件系统而言，仅仅是满足了正常状况下文件系统各项服务还不够，还需要保证分布式各种意外场景下健康持续的服务，否则，将一无是处。。。
1、服务器的错误恢复
在分布式环境中，哪台服务器牺牲都是常见的事情，牺牲不可怕，可怕的是你都没有时刻准备好它们会牺牲。作为一个合格的分布式系统，HDFS当然时刻准备好了前赴后继奋勇向前。HDFS有三类服务器，每一类服务器出错了，都有相应的应急策略。。。
a. 客户端
生命最轻如鸿毛的童鞋，应该就是客户端了。毕竟，做为一个文件系统的使用者，在整个文件系统中的地位，难免有些归于三流。而作为客户端，大部分时候，牺牲了就牺牲了，没人哀悼，无人同情，只有在在辛勤写入的时候，不幸辞世（机器挂了，或者网络断了，诸如此类...），才会引起些恐慌。因为，此时此刻，在主控服务器上对应的文件，正作为INodeFileUnderConstruction活着，仅仅为占有它的那个客户端服务者，做为一个专一的文件，它不允许别的客户端染指。这样的话，一旦占有它的客户端服务者牺牲了，此客户端会依然占着茅坑不拉屎，让如花似玉INodeFileUnderConstruction孤孤单单守寡终身。这种事情当然无法容忍，因此，必须有办法解决这个问题，办法就是：租约。。。
租约，顾名思义，就是当客户端需要占用某文件的时候，与主控服务器签订的一个短期合同。这个合同有一个期限，在这个期限内，客户端可以延长合同期限，一旦超过期限，主控服务器会强行终止此租约，将这个文件的享用权，分配给他人。。。
在打开或创建一个文件，准备追加写之前，会调用LeaseManager的addLease方法，在指定的路径下与此客户端签订一份租约。客户端会启动DFSClient.LeaseChecker线程，定时轮询调用ClientProtocol的renewLease方法，续签租约。在主控服务器一端，有一个LeaseManager.Monitor线程，始终在轮询检查所有租约，查看是否有到期未续的租约。如果一切正常，该客户端完成写操作，会关闭文件，停止租约，一旦有所意外，比如文件被删除了，客户端牺牲了，主控服务器都会剥夺此租约，如此，来避免由于客户端停机带来的资源被长期霸占的问题。。。
b. 数据服务器
当然，会挂的不只是客户端，海量的数据服务器是一个更不稳定的因素。一旦某数据服务器牺牲了，并且主控服务器被蒙在鼓中，主控服务器就会变相的欺骗客户端，给它们无法连接的读写服务器列表，导致它们处处碰壁无法工作。因此，为了整个系统的稳定，数据服务器必须时刻向主控服务器汇报，保持主控服务器对其的完全了解，这个机制，就是心跳消息。在HDFS中，主控服务器NameNode实现了DatanodeProtocol接口，数据服务器DataNode会在主循环中，不停的调用该协议中的sendHeartbeat方法，向NameNode汇报状况。在此调用中，DataNode会将其整体运行状况告知NameNode，比如：有多少可用空间、用了多大的空间，等等之类。NameNode会记住此DataNode的运行状况，作为新的数据块分配或是负载均衡的依据。当NameNode处理完成此消息后，会将相关的指令封装成一个DatanodeCommand对象，交还给DataNode，告诉数据服务器什么数据块要删除什么数据块要新增等等之类，数据服务器以此为自己的行动依据。。。
但是，sendHeartbeat并没有提供本地的数据块信息给NameNode，那么主控服务器就无法知道此数据服务器应该分配什么数据块应该删除什么数据块，那么它是如何决定的呢？答案就是DatanodeProtocol定义的另一个方法，blockReport。DataNode也是在主循环中定时调用此方法，只是，其周期通常比调用sendHeartbeat的更长。它会提交本地的所有数据块状况给NameNode，NameNode会和本地保存的数据块信息比较，决定什么该删除什么该新增，并将相关结果缓存在本地对应的数据结构中，等待此服务器再发送sendHeartbeat消息过来的时候，依照这些数据结构中的内容，做出相应的DatanodeCommand指令。blockReport方法同样也会返回一个DatanodeCommand给DataNode，但通常，只是为空（只有出错的时候不为空），我想，增加缓存，也许是为了确保每个指令都可以重复发送并确定被执行。。。
c. 主控服务器
当然，作为整个系统的核心和单点，含辛茹苦的主控服务器含泪西去，整个分布式文件服务集群将彻底瘫痪罢工。如何在主控服务器牺牲后，提拔新的主控服务器并迅速使其进入工作角色，就成了系统必须考虑的问题。解决策略就是：日志。。。
其实这并不是啥新鲜东西，一看就知道是从数据库那儿偷师而来的。在主控服务器上，所有对文件目录操作的关键步骤（具体文件内容所处的数据服务器，是不会被写入日志的，因为这些内容是动态建立的...），都会被写入日志。另外，主控服务器会在某些时刻，将当下的文件目录完整的序列化到本地，这称为镜像。一旦存有镜像，镜像前期所写的日志和其他镜像，都纯属冗余，其历史使命已经完成，可以报废删除了。在主控服务器不幸牺牲，或者是战略性的停机修整结束，并重新启动后，主控服务器会根据最近的镜像 + 镜像之后的所有日志，重建整个文件目录，迅速将服务能力恢复到牺牲前的水准。。。
对于数据服务器而言，它们会通过一些手段，迅速得知顶头上司的更迭消息。它们会立刻转投新东家的名下，在新东家旗下注册，并开始向其发送心跳消息，这个机制，可能用分布式协同服务来实现，这里不说也罢。。。
在HDFS的实现中，
FSEditLog类是整个日志体系的核心，提供了一大堆方便的日志写入API，以及日志的恢复存储等功能。目前，它支持若干种日志类型，都冠以OP_XXX，并提供相关API，具体可以参见
这里。为了保证日志的安全性，FSEditLog提供了
EditLogFileOutputStream类作为写入的承载类，它会同时开若干个本地文件，然后依次写入，防止日志的损坏导致不可估量的后果。在FSEditLog上面，有一个
FSImage类，存储文件镜像并调用FSEditLog对外提供相关的日志功能。FSImage是Storage类的子类，如果对数据块的讲述有所印象的话，你可以回忆起来，凡事从此类派生出来的东西，都具有版本性质，可以进行升级和回滚等等，以此，来实现产生镜像是对原有日志和镜像处理的复杂逻辑。。。
目前，在HDFS的日志系统中，有些地方与GFS的描述有所不同。在HDFS中，所有日志文件和镜像文件都是本地文件，这就相当于，把日志放在自家的保险箱中，一旦主控服务器挂了，别的后继而上的服务器也无法拿到这些日志和镜像，用于重振雄风。因此，在HDFS中，运行着一个SecondaryNameNode服务器，它做为主控服务器的替补，隐忍厚积薄发为篡位做好准备，其中，核心内容就是：定期下载并处理日志和镜像。SecondaryNameNode看上去像客户端一样，与NameNode之间，走着NamenodeProtocol协议。它会不停的查看主控服务器上面累计日志的大小，当达到阈值后，调用doCheckpoint函数，此函数的主要步骤包括：
- 首先是调用startCheckpoint做一些本地的初始化工作；
- 然后调用rollEditLog，将NameNode上此时操作的日志文件从edit切到edit.new上来，这个操作瞬间完成，上层写日志的函数完全感觉不到差别；
- 接着，调用downloadCheckpointFiles，将主控服务器上的镜像文件和日志文件都下载到此候补主控服务器上来；
- 并调用doMerge，打开镜像和日志，将日志生成新的镜像，保存覆盖；
- 下一步，调用putFSImage把新的镜像上传回NameNode；
- 再调用rollFsImage，将镜像换成新的，在日志从edit.new改名为edit；
- 最后，调用endCheckpoint做收尾工作。
整个算法涉及到NameNode和SecondaryNameNode两个服务器，最终结果是NameNode和SecondaryNameNode都依照算法进行前的日志生成了镜像。而两个服务器上日志文件的内容，前者是整个算法进行期间所写的日志，后者始终不会有任何日志。当主控服务器牺牲的时候，运行SecondaryNameNode的服务器立刻被扶正，在其上启动主控服务，利用其日志和镜像，恢复文件目录，并逐步接受各数据服务器的注册，最终向外提供稳定的文件服务。。。
同样的事情，GFS采用的可能是另外一个策略，就是在写日志的时候，并不局限在本地，而是同时书写网络日志，即在若干个远程服务器上生成同样的日志。然后，在某些时机，主控服务器自己，生成镜像，降低日志规模。当主控服务器牺牲，可以在拥有网络日志的服务器上启动主控服务，升级成为主控服务器。。。
GFS与HDFS的策略相比较，前者是化整为零，后者则是批量处理，通常我们认为，批量处理的平均效率更高一些，且相对而言，可能实现起来容易一些，但是，由于有间歇期，会导致日志的丢失，从而无法100%的将备份主控服务器的状态与主控服务器完全同步。。。
2、数据的正确性保证
在复杂纷繁的分布式环境中，我们坚定的相信，万事皆有可能。哪怕各个服务器都舒舒服服的活着，也可能有各种各样的情况导致网络传输中的数据丢失或者错误。并且在分布式文件系统中，同一份文件的数据，是存在大量冗余备份的，系统必须要维护所有的数据块内容完全同步，否则，一人一言，不同客户端读同一个文件读出不同数据，用户非得疯了不可。。。
在HDFS中，为了保证数据的正确性和同一份数据的一致性，做了大量的工作。首先，每一个数据块，都有一个版本标识，在Block类中，用一个长整型的数generationStamp来表示版本信息（Block类是所有表示数据块的数据结构的基类），一旦数据块上的数据有所变化，此版本号将向前增加。在主控服务器上，保存有此时每个数据块的版本，一旦出现数据服务器上相关数据块版本与其不一致，将会触发相关的恢复流程。这样的机制保证了各个数据服务器器上的数据块，在基本大方向上都是一致的。但是，由于网络的复杂性，简单的版本信息无法保证具体内容的一致性（因为此版本信息与内容无关，可能会出现版本相同，但内容不同的状况）。因此，为了保证数据内容上的一致，必须要依照内容，作出签名。。。
当客户端向数据服务器追加写入数据包时，每一个数据包的数据，都会切分成512字节大小的段，作为签名验证的基本单位，在HDFS中，把这个数据段称为Chunk，即传输块（注意，在GFS中，Chunk表达的是数据块...）。在每一个数据包中，都包含若干个传输块以及每一个传输块的签名，当下，这个签名是根据Java SDK提供的CRC算法算得的，其实就是一个奇偶校验。当数据包传输到流水线的最后一级，数据服务器会对其进行验证（想一想，为什么只在最后一级做验证，而不是每级都做...），一旦发现当前的传输块签名与在客户端中的签名不一致，整个数据包的写入被视为无效，Lease Recover（租约恢复）算法被触发。。。
从基本原理上看，这个算法很简单，就是取所有数据服务器上此数据块的最小长度当作正确内容的长度，将其他数据服务器上此数据块超出此长度的部分切除。从正确性上看，此算法无疑是正确的，因为至少有一个数据服务器会发现此错误，并拒绝写入，那么，如果写入了的，都是正确的；从效率上看，此算法也是高效的，因为它避免了重复的传输和复杂的验证，仅仅是各自删除尾部的一些内容即可。但从具体实现上来看，此算法稍微有些绕，因为，为了降低本已不堪重负的主控服务器的负担，此算法不是由主控服务器这个大脑发起的，而是通过选举一个数据服务器作为Primary，由Primary发起，通过调用与其他各数据服务器间的InterDatanodeProtocol协议，最终完成的。具体的算法流程，参见LeaseManager类上面的注释。需要说明的是此算法的触发时机和发起者。此算法可以由客户端或者是主控服务器发起，当客户端在写入一个数据包失败后，会发起租约恢复。因为，一次写入失败，不论是何种原因，很有可能就会导致流水线上有的服务器写了，有的没写，从而造成不统一。而主控服务器发起的时机，则是在占有租约的客户端超出一定时限没有续签，这说明客户端可能挂了，在临死前可能干过不利于数据块统一的事情，作为监督者，主控服务器需要发起一场恢复运动，确保一切正确。。。
3、负载均衡
负载的均衡，是分布式系统中一个永恒的话题，要让大家各尽其力齐心干活，发挥各自独特的优势，不能忙得忙死闲得闲死，影响战斗力。而且，负载均衡也是一个复杂的问题，什么是均衡，是一个很模糊的概念。比如，在分布式文件系统中，总共三百个数据块，平均分配到十个数据服务器上，就算均衡了么？其实不一定，因为每一个数据块需要若干个备份，各个备份的分布应该充分考虑到机架的位置，同一个机架的服务器间通信速度更快，而分布在不同机架则更具有安全性，不会在一棵树上吊死。。。
在这里说的负载均衡，是宽泛意义上的均衡过程，主要涵盖两个阶段的事务，一个是在任务初始分配的时候尽可能合理分配，另一个是在事后时刻监督及时调整。。。
在HDFS中，ReplicationTargetChooser类，是负责实现为新分配的数据块寻找婆家的。基本上来说，数据块的分配工作和备份的数量、申请的客户端地址（也就是写入者）、已注册的数据服务器位置，密切相关。其算法基本思路是只考量静态位置信息，优先照顾写入者的速度，让多份备份分配到不同的机架去。具体算法，自行参见源码。此外，HDFS的Balancer类，是为了实现动态的负载调整而存在的。Balancer类派生于Tool类，这说明，它是以一个独立的进程存在的，可以独立的运行和配置。它运行有NamenodeProtocol和ClientProtocol两个协议，与主控服务器进行通信，获取各个数据服务器的负载状况，从而进行调整。主要的调整其实就是一个操作，将一个数据块从一个服务器搬迁到另一个服务器上。Balancer会向相关的目标数据服务器发出一个DataTransferProtocol.OP_REPLACE_BLOCK消息，接收到这个消息的数据服务器，会将数据块写入本地，成功后，通知主控服务器，删除早先的那个数据服务器上的同一块数据块。具体的算法请自行参考源码。。。
4、垃圾回收
对于垃圾，大家应该耳熟能详了，在分布式文件系统而言，没有利用价值的数据块备份，就是垃圾。在现实生活中，我们提倡垃圾分类，为了更好的理解分布式文件系统的垃圾收集，搞个分类也是很有必要的。基本上，所有的垃圾都可以视为两类，一类是由系统正常逻辑产生的，比如某个文件被删除了，所有相关的数据块都沦为垃圾了，某个数据块被负载均衡器移动了，原始数据块也不幸成了垃圾了。此类垃圾最大的特点，就是主控服务器是生成垃圾的罪魁祸首，也就是说主控服务器完全了解有哪些垃圾需要处理。另外还有一类垃圾，是由于系统的一些异常症状产生的，比如某个数据服务器停机了一段，重启之后发现其上的某个数据块已经在其他服务器上重新增加了此数据块的备份，它上面的那个备份过期了失去价值了，需要被当作垃圾来处理了。此类垃圾的特点恰恰相反，主控服务器无法直接了解到垃圾状况，需要曲线救国。。。
在HDFS中，第一类垃圾的判定自然很容易，在一些正常的逻辑中产生的垃圾，全部被塞进了FSNamesystem的recentInvalidateSets这个Map中。而第二类垃圾的判定，则放在数据服务器发送其数据块信息来的过程中，经过与本地信息的比较，可以断定，此数据服务器上有哪些数据块已经不幸沦为垃圾。同样，这些垃圾也被塞到recentInvalidateSets中去。在与数据服务器进行心跳交流的过程中，主控服务器会将它上面有哪些数据块需要删除，数据服务器对这些数据块的态度是，直接物理删除。在GFS的论文中，对如何删除一个数据块有着不同的理解，它觉着应该先缓存起来，过几天没人想恢复它了再删除。在HDFS的文档中，则明确表示，在现行的应用场景中，没有需要这个需求的地方，因此，直接删除就完了。这说明，理念是一切分歧的根本：）。。。
V. 总结
整个分布式文件系统，计算系统，数据库系统的设计理念，基本是一脉相承的。三类服务器、作为单点存在的核心控制服务器、基于日志的恢复机制、基于租约的保持联系机制、等等，在后续分布式计算系统和分布式数据库中都可以看到类似的影子，在分布式文件系统这里，我详述了这些内容，可能在后续就会默认知道而说的比较简略了。而刨去这一些，分布式文件系统中最大特点，就是文件块的冗余存储，它直接导致了较为复杂的写入流程。当然，虽说分布式文件系统在分布式计算和数据库中都有用到，但如果对其机理没有兴趣，只要把它当成是一个可以在任何机器上使用的文件系统，就不会对其他上层建筑的理解产生障碍。。。
首先解释一下为什么它被称之为SOCKS。其实该协议设计之初是为了让有权限的用户可以穿过过防火墙的限制，使得高权限用户可以访问一般用户不能访问的外部资源。当时设计者考虑到几乎所有使用TCP/IP通信的应用软件都使用socket（套接字，实际上是一组应用程序接口）完成底层的数据通信。为了方便软件开发者使用该协议，协议设计者就刻意对应了几组socket编程最经典的操作，并且将协议定名为SOCKS。
最先被广泛使用的SOCKS协议是其第四版本，就是SOCKS4。IE和一些其他应用程序直接用“Socks”表示SOCKS4协议。该版本支持TCP的connect（作为客户端连接）和listen（打开一个监听端口），不支持UDP协议。SOCKS4A对SOCKS4作了一点增强，即允许客户端将域名发送给SOCKS服务器，让SOCKS服务器进行域名解析。
SOCKS5是第五版，相对第四版作了大幅度的增强。首先，它增加了对UDP协议的支持；其次，它可以支持多种用户身份验证方式和通信加密方式；最后，修改了SOCKS服务器进行域名解析的方法，使其更加优雅。经过这次脱胎换骨的升级，SOCKS5于1996年被IETF确认为标准通信协议，RFC编号为1928。经过10余年的时间，大量的网络应用程序都支持SOCKS5代理。
SOCKS5虽然可以支持多种用户身份验证方式，但是应用程序真正实现的一般也只有两种：不验证和用户名密码验证。所以大多数应用程序SOCKS5代理设置也只有用户名/密码这一种可选验证方法。另外，尽管从SOCKS4开始，就支持打开TCP监听端口，但是直到SOCKS5，也只允许这个端口接收一个客户端连接。因此网络服务提供者（如http服务器）不能使用SOCKS。实际上，很多SOCKS服务器的实现也不支持打开TCP监听端口。
由于SOCKS5实际上仍然对应了socket的经典操作，所以有人利用这一点编写了一种通用软件，可以让不支持SOCKS5协议的应用软件也能通过SOCKS5服务器进行网络通信，而应用软件则对此一无所知。这类软件最著名的莫过于SocksCap32了，它是Permeo公司（其前身是NEC北美公司的一个部门，而SOCKS最初就是NEC北美公司的工程师开发并维护的）早期推出的一款产品。用户可以免费使用其试用版。试用版和正式版相比，没有功能上的限制，只有使用时间的限制。但是到目前为止，Permeo总是会在老版本到期之前推出一个延后了期限的“新”版本，所以用户实际上可以免费使用。SocksCap32是利用API钩子，截获应用软件对socket函数的调用来实现对SOCKS5客户端的模拟。尽管SocksCap32很有名，但是由于推出的时间较早，对很多现代应用软件时常表现的力不从心，所以Permeo又提供了Permeo Security Driver（以下称为PSD）。这款产品使用了驱动技术从底层直接截获应用软件的socket通信，因此几乎可以为所有应用软件提供SOCKS5客户端的支持。PSD不提供试用版，但是可以找到其早期版本的注册码。
虽然说设计SOCKS协议的初衷是在保证网络隔离的情况下，提高部分人员的网络访问权限，但是国内似乎很少有组织机构这样使用。一般情况下，大家都会使用更新的网络安全技术来达到相同的目的。但是由于SocksCap32和PSD这类软件，人们找到了SOCKS协议新的用途——突破网络通信限制，这和该协议的初衷实际上正好相反。比如某些网游的部分服务器设置为只接收部分地区的IP地址的连接。为了突破这种限制，可以找一个该地区的SOCKS5代理服务器，然后用PSD接管网游客户端，通过SOCKS5代理服务器连接游戏服务器。这样游戏服务器就会认为该客户端位于本地区，从而允许进行游戏。还有一种情况是：防火墙仅允许部分端口（如http的80端口）通信，那么可以利用SOCKS5协议和一个打开80端口监听的SOCKS5服务器连接，从而可以连接公网上其他端口的服务器。利用一些额外的技术手段，甚至可以骗过内部的http代理服务器，这时在使用内网http代理上网的环境下也可以不受限制的使用网络服务，这称之为SOCKS over HTTP。通通通（[url]www.tongtongtong.com[/url]）是老牌SOCKS over HTTP代理提供商，实现了所有的SOCKS5的连接功能，且有多组国内外服务器。信天游（[url]www.xtyproxy.com[/url]），则是最近刚刚出现的代理服务提供商，功能和通通通相比还有差距，但是目前完全免费。当然，使用代理服务器后，将不可避免的出现通信延迟，所以应该尽量选择同网络（指网通/ 电信），距离近的服务器。
sock5代理的工作程序是：
1.需要向代理方服务器发出请求信息。
2.代理方应答
3.需要代理方接到应答后发送向代理方发送目的ip和端口
4.代理方与目的连接
5.代理方将需要代理方发出的信息传到目的方，将目的方发出的信息传到需要代理方。代理完成。
由于网上的信息传输都是运用tcp或udp进行的，所以使用socks5代理可以办到网上所能办到的一切，而且不舆目的方会查到你的ip,既安全又方
便 sock5支持UDP和TCP,但两种代理是有区别的，以下分类说明
如何用代理TCP协议
1.向服务器的1080端口建立tcp连接。
2.向服务器发送 05 01 00 （此为16进制码，以下同）
3.如果接到 05 00 则是可以代理
4.发送 05 01 00 01 + 目的地址(4字节） + 目的端口（2字节），目的地址和端口都是16进制码（不是字符串！！）。 例202.103.190.27 -7201 则发送的信息为：05 01 00 01 CA 67 BE 1B 1C 21 (CA=202 67=103 BE=190 1B=27 1C21=7201)
5.接受服务器返回的自身地址和端口，连接完成
6.以后操作和直接与目的方进行TCP连接相同。
如何用代理UDP连接
1.向服务器的1080端口建立udp连接
2.向服务器发送 05 01 00
3.如果接到 05 00 则是可以代理
4.发送 05 03 00 01 00 00 00 00 + 本地UDP端口（2字节）
5.服务器返回 05 00 00 01 +服务器地址+端口
6.需要申请方发送 00 00 00 01 +目的地址IP（4字节）+目的端口 +所要发送的信息
7.当有数据报返回时 向需要代理方发出00 00 00 01 +来源地址IP（4字节）+来源端口 +接受的信息
注：此为不需要密码的代理协议，只是socks5的一部分，完整协议请RFC1928
SOCKS V5的用户名/密码鉴定
（RFC1929 Username/Password Authentication for SOCKS V5）
本备忘录状态：
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程度和状态。本备忘录的发布不受任何限制。
1． 介绍
关于SOCKS V5的协议规范说明了在初始化SOCKS连接时所用到的任意验证协议的大致框架。这篇文档描述了这些协议中的其中一个适合SOCKS V5验证子协商(subnegotiation)。
注意：
除非特别注明，所有出现在数据包格式图中的十进制数字均以字节表示相应域的长度。如果某域需要给定一个字节的值，用X’hh’来表示这个字节中的值。如果某域中用到单词’Variable’，这表示该域的长度是可变的，且该长度定义在一个和这个域相关联（1 – 2个字节）的域中，或一个数据类型域中。
2．初始协商
一旦SOCKS V5服务器运行并且客户端选择了用户名/密码认证协议以后，就开始了用户名/密码协议的子协商过程。客户端先产生一个用户名/密码协议的请求：
| VER |
ULEN |
UNAME |
PLEN |
PASSWD |
| 1 |
1 |
1 to 255 |
1 |
1 to 255 |
VER中指明了子协商的当前版本，现在使用的是X’01’。ULEN域中包含了下一个UNAME域的长度。UNAME中包含一个源操作系统(source operating system)所知道的用户名。PLEN中指明了紧随其后的PASSWD的长度。PASSWD中则包含了对应UNAME用户的密码。
服务器验证用户名和密码，并且返回：
如果STATUS中返回X’00’则说明通过验证。如果服务器返回非X’00’则说明验证失败，并且关闭连接。
3．安全考虑
这篇文档描述了为SOCKS V5协议提供验证服务的子协商过程。因为密码是以明文传输的，所以这个子协商过程在可能被工具“嗅探(sniffing)”到的环境中不建议使用该子协商过程。
译者：Radeon（Radeon bise@cmmail.com）
译文发布时间：2001-6-18
目录
1.介绍
2．现有的协议
3．基于TCP协议的客户
4．请求
5．地址
6．应答
7．基于UDP协议的客户
8. 安全性考虑
9. 参考书目
1.介绍
利用网络防火墙可以将组织内部的网络结构从外部网络如INTERNET中有效地隔离，这种方法在许多网络系统中正变得流行起来。这种防火墙系统通常以应用层网关的形式工作在两个网络之间，提供TELNET、FTP、SMTP等的接入。随着越来越多的使全球信息查找更容易的复杂的应用层协议的出现，有必要提供一个通用框架来使这些协议安全透明地穿过防火墙。而且在实际应用中还需要一种安全的认证方式用以穿越防火墙。这个要求起源于两个组织的网络中客户/服务器关系的出现，这个关系需要得到控制并要求有安全的认证。
在这儿所描述的协议框架是为了让使用TCP和UDP的客户/服务器应用程序更方便安全地使用网络防火墙所提供的服务所设计的。这个协议从概念上来讲是介于应用层和传输层之间的“中介层(shim-layer)”，因而不提供如传递ICMP信息之类由网络层网关的所提供的服务。
2．现有的协议
当前存在一个协议SOCKS 4，它为TELNET、FTP、HTTP、WAIS和GOPHER等基于TCP协议的客户/服务器程序提供了一个不安全的防火墙。而这个新的协议扩展了SOCKS V4，以使其支持UDP、框架规定的安全认证方案、地址解析方案(addressing scheme)中所规定的域名和IPV6。为了实现这个SOCKS协议，通常需要重新编译或者重新链接基于TCP的客户端应用程序以使用SOCKS库中相应的加密函数。
注意：
除非特别注明，所有出现在数据包格式图中的十进制数字均以字节表示相应域的长度。如果某域需要给定一个字节的值，用X’hh’来表示这个字节中的值。如果某域中用到单词’Variable’，这表示该域的长度是可变的，且该长度定义在一个和这个域相关联（1 – 2个字节）的域中，或一个数据类型域中。
3．基于TCP协议的客户
当一个基于TCP协议的客户端希望与一个只能通过防火墙可以到达的目标(这是由实现所决定的)建立连接，它必须先建立一个与SOCKS服务器上SOCKS端口的TCP连接。通常这个TCP端口是1080。当连接建立后，客户端进入协议的“握手(negotiation)”过程：认证方式的选择，根据选中的方式进行认证，然后发送转发的要求。SOCKS服务器检查这个要求，根据结果，或建立合适的连接，或拒绝。
除非特别注明，所有出现在数据包格式图中的十进制数字均以字节表示相应域的长度。如果某域需要给定一个字节的值，用X’hh’来表示这个字节中的值。如果某域中用到单词’Variable’，这表示该域的长度是可变的，且该长度定义在一个和这个域相关联（1 – 2个字节）的域中，或一个数据类型域中。
客户端连到服务器后，然后就发送请求来协商版本和认证方法：
| VER |
NMETHODS |
METHODS |
| 1 |
1 |
1 to 255 |
这个版本的SOCKS协议中，VER字段被设置成X'05'。NMETHODS字段包含了在METHODS字段中出现的方法标示的数目（以字节为单位）。
服务器从这些给定的方法中选择一个并发送一个方法选中的消息回客户端：
如果选中的消息是X’FF’，这表示客户端所列出的方法列表中没有一个方法被选中，客户端必须关闭连接。
当前定义的方法有：
· X’00’ 不需要认证
· X’01’ GSSAPI
· X’02’ 用户名/密码
· X’03’ -- X’7F’ 由IANA分配
· X’80’ -- X’FE’ 为私人方法所保留的
· X’FF’ 没有可以接受的方法
然后客户和服务器进入由选定认证方法所决定的子协商过程(sub-negotiation)。各种不同的方法的子协商过程的描述请参考各自的备忘录。
开发者如果要为自己的方法得到一个方法号，可以联系IANA。可以参考关于已经被分配号码的文档以得到当前所有方法的列表和相应的协议。
符合本文档的SOCKS V5实现必须支持GSSAPI，并且在将来支持用户名/密码认证方式。
4．请求
一旦子协商过程结束后，客户端就发送详细的请求信息。如果协商的方法中有以完整性检查和/或安全性为目的的封装，这些请求必须按照该方法所定义的方式进行封装。
SOCKS请求的格式如下：
| VER |
CMD |
RSV |
ATYP |
DST.ADDR |
DST.PROT |
| 1 |
1 |
X’00’ |
1 |
Variable |
2 |
其中
· VER 协议版本: X’05’
· CMD
· CONNECT：X’01’
· BIND：X’02’
· UDP ASSOCIATE：X’03’
· RSV 保留
· ATYP 后面的地址类型
· IPV4：X’01’
· 域名：X’03’
· IPV6：X’04’'
· DST.ADDR 目的地址
· DST.PORT 以网络字节顺序出现的端口号
SOCKS服务器会根据源地址和目的地址来分析请求，然后根据请求类型返回一个或多个应答。
5．地址
ATYP字段中描述了地址字段(DST.ADDR，BND.ADDR)所包含的地址类型：
· X'01'
基于IPV4的IP地址，4个字节长
· X'03'
基于域名的地址，地址字段中的第一字节是以字节为单位的该域名的长度，没有结尾的NUL字节。
· X'04'
基于IPV6的IP地址，16个字节长
6．应答
一旦建立了一个到SOCKS服务器的连接，并且完成了认证方式的协商过程，客户机将会发送一个SOCKS请求信息给服务器。服务器将会根据请求，以如下格式返回：
| VER |
REP |
RSV |
ATYP |
BND.ADDR |
BND.PORT |
| 1 |
1 |
X’00’ |
1 |
Variable |
2 |
其中：
· VER 协议版本: X’05’
· REP 应答字段:
· X’00’ 成功
· X’01’ 普通的SOCKS服务器请求失败
· X’02’ 现有的规则不允许的连接
· X’03’ 网络不可达
· X’04’ 主机不可达
· X’05’ 连接被拒
· X’06’ TTL超时
· X’07’ 不支持的命令
· X’08’ 不支持的地址类型
· X’09’ – X’FF’ 未定义
· RSV 保留
· ATYP 后面的地址类型
· IPV4：X’01’
· 域名：X’03’
· IPV6：X’04’
· BND.ADDR 服务器绑定的地址
· BND.PORT 以网络字节顺序表示的服务器绑定的段口
标识为RSV的字段必须设为X’00’。
如果选中的方法中有以完整性检查和/或安全性为目的的封装，这些应答必须按照该方法所定义的方式进行封装。
CONNECT
在对一个CONNECT命令的应答中，BND.PORT包含了服务器分配的用来连到目标机的端口号，BND.ADDR则是相应的IP地址。由于SOCKS服务器通常有多个IP，应答中的BND.ADDR常和客户端连到SOCKS服务器的那个IP不同。
SOCKS服务器可以利用DST.ADDR和DST.PORT，以及客户端源地址和端口来对一个CONNECT请求进行分析。
BIND
BIND请求通常被用在那些要求客户端接受来自服务器的连接的协议上。FTP是一个典型的例子。它建立一个从客户端到服务器端的连接来执行命令以及接收状态的报告，而使用另一个从服务器到客户端的连接来接收传输数据的要求(如LS，GET，PUT)。
建议只有在一个应用协议的客户端在使用CONNECT命令建立主连接后才可以使用BIND命令建立第二个连接。建议SOCKS服务器使用DST.ADDR和DST.PORT来评价BIND请求。
在一个BIND请求的操作过程中，SOCKS服务器要发送两个应答给客户端。当服务器建立并绑定一个新的套接口时发送第一个应答。BND.PORT字段包含SOCKS服务器用来监听进入的连接的端口号，BAND.ADDR字段包含了对应的IP地址。客户端通常使用这些信息来告诉（通过主连接或控制连接）应用服务器连接的汇接点。第二个应答仅发生在所期望到来的连接成功或失败之后。在第二个应答中，BND.PORT和BND.ADDR字段包含了连上来的主机的IP地址和端口号。
UDP ASSOCIATE
UDP ASSOCIATE请求通常是要求建立一个UDP转发进程来控制到来的UDP数据报。DST.ADDR和DST.PORT 字段包含客户端所希望的用来发送UDP数据报的IP地址和端口号。服务器可以使用这个信息来限制进入的连接。如果客户端在发送这个请求时没有地址和端口信息，客户端必须用全0来填充。
当与UDP相应的TCP连接中断时，该UDP连接也必须中断。
应答UDP ASSOCIATE请求时，BND.PORT 和BND.ADDR字段指明了客户发送UDP消息至服务器的端口和地址。
应答处理
当一个应答(REP值不等于00)指明出错时，SOCKS服务器必须在发送完应答消息后一小段时间内终止TCP连接。这段时间应该在发现错误后少于10秒。
如果一个应答(REP值等于00)指明成功，并且请求是一个BIND或CONNECT时，客户端就可以开始发送数据了。如果协商的认证方法中有以完整性、认证和/或安全性为目的的封装，这些请求必须按照该方法所定义的方式进行封装。类似的，当以客户机为目的地的数据到达SOCKS服务器时，SOCKS服务器必须用正在使用的方法对这些数据进行封装。
7．基于UDP协议的客户
在UDP ASSOCIATE应答中由BND.PORT指明了服务器所使用的UDP端口，一个基于UDP协议的客户必须发送数据报至UDP转发服务器的该端口上。如果协商的认证方法中有以完整性、认证和/或安全性为目的的封装，这些数据报必须按照该方法所定义的方式进行封装。每个UDP数据报都有一个UDP请求头在其首部：
| RSV |
FRAG |
ATYP |
DST.ADDR |
DST.PORT |
DATA |
| 2 |
1 |
1 |
Variable |
2 |
Variable |
在UDP请求头中的字段是：
· RSV 保留 X’0000’
· FRAG 当前的分段号
· ATYP 后面的地址类型
· IPV4：X’01’
· 域名：X’03’
· IPV6：X’04’
· DST.ADDR 目的地址
· DST.PORT 以网络字节顺序出现的端口号
· DATA 用户数据
当一个UDP转发服务器转发一个UDP数据报时，不会发送任何通知给客户端；同样，它也将丢弃任何它不能发至远端主机的数据报。当UDP转发服务器从远端服务器收到一个应答的数据报时，必须加上上述UDP请求头，并对数据报进行封装。
UDP转发服务器必须从SOCKS服务器得到期望的客户端IP地址，并将数据报发送到UDP ASSOCIATE应答中给定的端口号。如果数据报从任何IP地址到来，而该IP地址与该特定连接中指定的IP地址不同，那么该数据报会被丢弃。
FRAG字段指明数据报是否是一些分片中的一片。如果SOCKS服务器要实现这个功能，X’00’指明数据报是独立的；其他则越大越是数据报的尾端。介于1到127之间的值说明了该分片在分片序列里的位置。每个接收者都为这些分片提供一个重组队列和一个重组的计时器。这个重组队列必须在重组计时器超时后重新初始化，并丢弃相应的数据报。或者当一个新到达的数据报有一个比当前在处理的数据报序列中最大的FRAG值要小时，也必须重新初始化从组队列。重组计时器必须小于5秒。只要有可能，应用程序最好不要使用分片。
分片的实现是可选的；如果某实现不支持分片，所有FRAG字段不为0的数据报都必须被丢弃。
一个SOCKS的UDP编程界面(The programming interface for a SOCKS-aware UDP)必须报告当前可用UDP数据报缓存空间小于操作系统提供的实际空间。
· 如果 ATYP是 X’01’ - 10+method_dependent octets smaller
· 如果 ATYP是X’03’ - 262+method_dependent octets smaller
· 如果 ATYP是X’04’ - 20+method_dependent octets smaller
8. 安全性考虑
这篇文档描述了一个用来透过IP网络防火墙的应用层协议。这种传输的安全性在很大程度上依赖于特定实现所拥有以及在SOCKS客户与SOCKS服务器之间经协商所选定的特殊的认证和封装方式。
系统管理员需要对用户认证方式的选择进行仔细考虑。
1.安装程序准备
你需要准备TortoiseSVN-1.5.5.14361-win32-svn-1.5.4.msi和VisualSVN-1.5.4.msi两个安装程序，其中TortoiseSVN-1.5.5.14361-win32-svn-1.5.4.msi安装之后主要用于察看和管理使用；VisualSVN-1.5.4.msi主要是为了VS2005使用。
先安装TortoiseSVN-1.5.5.14361-win32-svn-1.5.4.msi，一直下一步到底，然后安装VisualSVN-1.5.4.msi一直下一步到底，
提示：如果你不使用VS2005，那么不需要安装VisualSVN-1.5.4.msi2.破解VisualSVN由于默认安装VisualSVN-1.5.4.msi只有29天使用时限，下面说破解方法：
提示：只针对于VisualSVN 1.5.x第一步：首先去认你系统安装了.NET Framework;
第二步：进入.NET Framework命令提示符，输入或者直接复制：
ildasm "C:\Program Files\VisualSVN\bin\VisualSVN.Core.dll" /out="C:\Program Files\VisualSVN\bin\VisualSVN.Core.il"
第三步： 切换到“C:\Program Files\VisualSVN\bin\”目录，使用文本编辑器打开刚才输出的il文件，查找
.method public hidebysig static bool IsValid(
将该方法括号(
{})内的代码体替换成
.maxstack 8
IL_0000: ldc.i4.1
IL_0001: ret
第四步： 回到命令行输入
ilasm "C:\Program Files\VisualSVN\bin\VisualSVN.Core.il" /dll编译得到新的dll覆盖原VisualSVN.Core.dll，默认执行后就是覆盖了。
第五步： 破解完毕，打开VS.NET，点击VisualSVN菜单->Registration，输入任意字符点击OK注册成功。
在你所要设为自增型的键上（比如你的id）双击，弹出一个Column Properties对话框，右下角有一个Identify的选择框，选中它OK，就可以了。
再去查看Preview，就能看到用大写标识出来的AUTO_INCREMENT。
在RH Linux下修改IP、DNS和路由配置
ifconfig eth0 新ip
然后编辑/etc/sysconfig/network-scripts/ifcfg-eth0，修改ip
一、修改IP地址
[aeolus@db1 network-scripts]$ vi ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=219.136.241.211
NETMASK=255.255.255.128
GATEWAY=219.136.241.254
二、修改网关
vi /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=Aaron
GATEWAY=192.168.1.1
三、修改DNS
[aeolus@db1 etc]$ vi resolv.conf
nameserver 202.96.128.68
nameserver 219.136.241.206
四、重新启动网络配置
/etc/init.d/network restart
修改ip地址
即时生效:
# ifconfig eth0 192.168.0.20 netmask 255.255.255.0
启动生效:
修改/etc/sysconfig/network-scripts/ifcfg-eth0
修改default gateway
即时生效:
# route add default gw 192.168.0.254
启动生效:
修改/etc/sysconfig/network-scripts/ifcfg-eth0
修改dns
修改/etc/resolv.conf
修改后可即时生效，启动同样有效
修改host name
即时生效:
# hostname fc2
启动生效:
修改/etc/sysconfig/network.