【精品】基于hadoop的分布式存储平台的搭建与验证毕业论文

(此文档为word格式，下载后您可任意编辑修
改！)
毕业设计（论文）
中文题目:基于hadoop的分布式存储平台的搭建与验证
英文题目:Setuping and verification distributed storage platform based on the principle of Google file system developed and implemented by the great
concern of the IT industry, and widely used.
The thesis aims to set up Hadoop multi-node distributed storage platform and analyze its security mechanisms to be implemented on a separate computer.
The thesis first introduces the research background knowledge of the subject, and detailed description of the study and the principle of the of the platform, and its performance were verified, further security mechanisms. First the industry generally accepted user requirements and the architecture of the distributed file system model are introduced。

Then for HDFS architecture to achieve the Hadoop security mechanisms and the corresponding security policy. In addition,the advantages of HDFS in the field of cloud computing applications and the security problem are summarized. At last thedesign and application recommendations are presented.
The experimental platform installed virtualbox ubuntu10.10 of application is a the this experiment platform.
Keywords: ，HDFS, MapReduce，ZooKeeper，Avro，Chukwa,HBase，Hive，Mahout，Pig 在内的10 个子项目。

其中，HDFS 和MapReduce 是这个项目的核心。

要使用HADOOP 构建自己的云计算服务平台，必须深刻的理解和掌握HDFS 和MapReduce。

其实，作为一个开源项目，HADOOP 主要产生于Google 分布式文件系统GFS以及Google 的MapReduce 编程模式[2]。

2．2 HDFS(HADOOP 分布式文件系统)机制
HDFS 是一个运行在普通的组件集群上的分布式文件系统，它是HADOOP 框架主要的存储系统。

由于HADOOP 具有高数据吞吐量，并且实现了高度容错，因此具有很高的效能。

本节将对HDFS 的核心机制和架构作深入的研究和分析。

研究内容和观点主要来自Hadoop 的官方站点。

2．2．1 前提和设计目标
①硬件错误
硬件错误是常态而不是异常。

HDFS 可能由成百上千的服务器所构成，每个服务器上存储着文件系统的部分数据。

我们面对的现实是构成系统的组件数目是巨大的，而且任一组件都有可能失效，这意味着总是有一部分HDFS 的组件是不工作的。

因此错误检测和快速、自动的恢复是HDFS 最核心的架构目标。

②流式数据访问
运行在HDFS 上的应用和普通的应用不同，需要流式访问它们的数据集。

HDFS的设计中更多的考虑到了数据批处理，而不是用户交互处理。

比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。

POSIX 标准设置的很多硬性约束对HDFS 应用系统不是必需的。

为了提高数据的吞吐量，在一些关键方面对POSIX的语义做了一些修改。

③大规模数据集
运行在HDFS 上的应用具有很大的数据集。

HDFS 上的一个典型文件大小一般都在G 字节至T 字节。

因此，HDFS 被调节以支持大文件存储。

它应该能提供整体上高的数据传输带宽，能在一个集群里扩展到数百个节点。

一个单一的HDFS实例应该能支撑数以千万计的文件。

④简单的一致性模型
HDFS 应用需要一个―一次写入多次读取‖的文件访问模型。

一个文件经过创建、写入和关闭之后就不需要改变。

这一假设简化了数据一致性问题，并且使高吞吐量的数据访问成为可能。

MapReduce 应用或者网络爬虫应用都非常适合这个模型。

目前还有计划在将来扩充这个模型，使之支持文件的附加写操作。

⑤―移动计算比移动数据更划算‖
一个应用请求的计算，离它操作的数据越近就越高效，在数据达到海量级别的时候更是如此。

因为这样就能降低网络阻塞的影响，提高系统数据的吞吐量。

将计算移动到数据附近，比之将数据移动到应用所在显然更好。

HDFS 为应用提供了将它们自己移动到数据附近的接口。

⑥异构软硬件平台间的可移植性
HDFS 在设计的时候就考虑到平台的可移植性。

这种特性方便了HDFS 作为大规模数据应用平台的推广[3]。

2．2．2 Namenode 和Datanode
HDFS 采用masterslave 架构。

一个HDFS 集群是由一个Namenode 和一定数目的Datanodes 组成。

Namenode 是一个中心服务器，负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。

集群中的Datanode 一般是一个节点一个，负责管理它所在节点上的存储。

HDFS 暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。

从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组Datanode 上。

Namenode 执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录。

它也负责确定数据块到具体Datanode 节点的映射。

Datanode 负责处理文件系统客户端的读写请求。

在Namenode 的统一调度下进行数据块的创建、删除和复制。

Namenode 和Datanode 被设计成可以在普通的商用机器上运行。

这些机器一般运行着GNULinux 操作系统(OS)。

HDFS 采用Java 语言开发，因此任何支持Java的机器都可以部署Namenode 或Datanode。

由于采用了可移植性极强的Java 语言，使得HDFS 可以部署到多种类型的机器上。

一个典型的部署场景是一台机器上只运行一个Namenode 实例，而集群中的其它机器分别运行一个Datanode 实例。

这种架构并不排斥在一台机器上运行多个Datanode，只不过这样的情况比较少见。

集群中单一Namenode 的结构大大简化了系统的架构。

Namenode 是所有HDFS 元数据的仲裁者和管理者，这样，用户数据永远不会流过Namenode[4]。

2．2．3 文件系统的名字空间
HDFS 支持传统的层次型文件组织结构。

用户或者应用程序可以创建目录，然后将文件保存在这些目录里。

文件系统名字空间的层次结构和大多数现有的文件系统类似：用户可以创建、删除、移动或重命名文件。

当前，HDFS 不支持用户磁盘配额和访问权限控制，也不支持硬链接和软链接。

但是HDFS 架构并不妨碍实现这些特性。

Namenode 负责维护文件系统的名字空间，任何对文件系统名字空间或属性的修改都将被Namenode 记录下来。

应用程序可以设置HDFS 保存的文件的副本数目。

文件副本的数目称为文件的副本系数，这个信息也是由Namenode 保存的。

2．2．4 通讯协议
所有的HDFS 通讯协议都是建立在TCPIP 协议之上。

客户端通过一个可配置的TCP 端口连接到Namenode，通过ClientProtocol 协议与Namenode 交互。

而Datanode 使用DatanodeProtocol 协议与Namenode 交互。

一个远程过程调用(RPC)模型被抽象出来封装ClientProtocol 和Datanodeprotocol 协议。

在设计上，Namenode不会主动发起RPC，而是响应来自客户端或Datanode 的RPC 请求。

2．2．5 健壮性
HDFS 的主要目标就是即使在出错的情况下也要保证数据存储的可靠性。

常见的三种出错情况是：Namenode 出错, Datanode 出错和网络割裂(network partitions)。

①磁盘数据错误，心跳检测和重新复制
每个Datanode 节点周期性地向Namenode 发送心跳信号。

网络割裂可能导致一部分Datanode 跟Namenode 失去联系。

Namenode 通过心跳信号的缺失来检测这一情况，并将这些近期不再发送心跳信号Datanode 标记为宕机，不会再将新的IO 请求发给它们。

任何存储在宕机Datanode 上的数据将不再有效。

Datanode 的宕机可能会引起一些数据块的副本系数低于指定值，Namenode 不断地检测这些需要复制的数据块，一旦发现就启动复制操作。

在下列情况下，可能需要重新复制：某个Datanode 节点失效，某个副本遭到损坏，Datanode 上的硬盘错误，或者文件的副本系数增大。

②集群均衡
HDFS 的架构支持数据均衡策略。

如果某个Datanode 节点上的空闲空间低于特定的临界点，按照均衡策略系统就会自动地将数据从这个Datanode 移动到其他空闲的Datanode。

当对某个文件的请求突然增加，那么也可能启动一个计划创建该文件新的副本，并且同时重新平衡集群中的其他数据。

③数据完整性
从某个Datanode 获取的数据块有可能是损坏的，损坏可能是由Datanode 的存储设备错误、网络错误或者软件bug 造成的。

HDFS 客户端软件实现了对HDFS文件内容的校验和(checksum)检查。

当客户端创建一个新的HDFS 文件，会计算这个文件每个数据块的校验和，并将校验和作为一个单独的隐藏文件保存在同一个HDFS 名字空间下。

当客户端获取文件内容后，它会检验从Datanode 获取的数据跟相应的校验和文件中的校验和是否匹配，如果不匹配，客户端可以选择从其他Datanode 获取该数据块的副本。

④元数据磁盘错误
FsImage 和Editlog 是HDFS 的核心数据结构。

如果这些文件损坏了，整个HDFS实例都将失效。

因而，Namenode 可以配置成支持维护多个FsImage 和Editlog 的副本。

任何对FsImage 或者Editlog 的修改，都将同步到它们的副本上。

这种多副本的同步操作可能会降低Namenode 每秒处理的名字空间事务数量。

然而这个代价是可以接受的，因为即使HDFS 的应用是数据密集的，它们也非元数据密集的。

当Namenode 重启的时候，它会选取最近的完整的FsImage 和Editlog 来使用。

Namenode 是HDFS 集群中的单点故障(single point of failure)所在。

如果Namenode机器故障，是需要手工干预的[5]。

2．3 HADOOP MapReduce 编程模型
2．3．1 操作介绍
MapReduce 的操作主要包括Map，Combine 和Reduce 过程。

①Map 操作
在MapReduce 框架中，Map 过程是高度并行的。

Map 的数目通常是由输入数据的大小决定的，即输入文件的总块数。

对于输入文件，框架会根据文件所占的块的个数而将文件划分为相应的片段。

在文件划分的时候，不会考虑文件的内部逻辑结构。

文件都会按照二进制字节数大小进行片段划分。

对于产生的每一个文件片段，框架会自动的创建一个Map 任务用来处理文件片段。

形式将键值对传递给Map 函数。

InputFormat 会将
文件划分为多个逻辑InputSplit 实例。

每个InputSplit 会对应着一个Map 函数。

同时，InputFormat 会提供RecordReader 的实现。

这个RecordReader 把InputSplit 的输入文件转化成(key,value)的形式，传递给Map。

同时，InputFormat 类也需要处理达到FileSplit 边界值的记录。

比如，默认的TextInputFormat 会读取超过分割边界值的FileSplit 的最后一行，当读取其他的非第一个FileSplit 时，TextInputFormat 会忽略第一个新行以上部分的内容。

InputFormat 产生给Map 的键值对可以不必严格控制。

即我们只需要完全传递给Map 文件的内容即可。

比如默认TextInputFormat 的输出中，key 即为行在文件中的偏移量，而value 则为行的内容，并使用Text 对象来表示。

Map 函数被定义在一个Mapper 类中。

Mapper 对象会获取从RecordReader 中得到的(key,value)对。

用户在Map 函数中会定义自己的处理规则来处理(key,value)，然后输出另一对(key,value)，这个键值对被成为中间键值对，并被Output 使用collect方法收集。

对于输出的中间键值对，我们可以自己定义key 和value 的类型，这个与输入键值对的类型没有关系。

但是，在HADOOP 框架中，所有的key 必须要实现WritableComparable 接口，所有的value 必须实现Writable 接口，这样，所有的kay，value 都能被序列化，并且可以通过key 对键值对进行排序操作。

②Combine 操作
当Map 操作输出它的(key,value)键值对之后，这些值会由于效率的原因存留在内存中。

对于每一个的Map 的输出键值对，我们会聚集然后分发到不同的Reduce执行规约的操作。

但有时候，对于特定的任务，我们可以在Map 本地就执行一个规约的操作，这样，Map 输出的结果得到的键值对就会得到大大的缩减，这样不光提高了效率，也减少了网络传输的负荷。

这个在Map 本地执行的规约过程我们使用Combiner 对象来完成。

当我们定义和使用了一个Combiner 类之后，Map 过程产生的(key，value)键值对就不会理解写到输出。

这些输出会先被手机到列表，每个key 对应一个列表。

当一定的数量的键值对被写入时，这个缓冲区里所有的键值对会被清空并转移到Combliner 类中的Reduce 方法中进行相应的规约操作。

最后，将操作合并后，产生的键值对输出并进行集合，最后分发给Reduce。

③Reduce
Reduce 规约任务的输出来自于Map 的输入。

Reduce 过程只要通过三个阶段来完成。

在第一阶段，框架会获得所有的Map 过程的输出。

第二阶段，Reduce 会按照key 的值对Reduce 的输入进行分组。

其实，第一阶段和第二阶段是同时进行的，Map 的输出在被取回的同时被合并。

第三阶段就是调用Reduce 函数进行规约操作的阶段。

每一个Reduce 被分配了Map 的输出后，这些键值对会作为一个集合被Reduce 操作。

在
分布式环境下，在开始任务之前，这些键值对集合就会被拷贝到Reduce 任务所在节点的本地文件系统。

一旦数据准备就绪，Reduce 规约操作开始。

其实，Reduce 的过程很简单：键值对被顺序读入，进行操作。

在Reduce 过程中，作为key 都是相同的，我们只需对value 进行一个循环迭代的操作。

当规约完成，每个执行的Reduce 的输出都会包含到一个输出文件。

输出文件的格式由JobConf。

SetOutputFormat 方法来指定[6]。

2．4 本章小结
本章详细介绍了HADOOP 系统中HADOOP 分布式文件系统HDFS 和
HADOOP 并行编程模式MapReduce 的核心机制和实现原理。

在本章最后，介绍了MapReduce 的调度和容错。

在对HDFS 的介绍上，主要从HDFS 和其他文件系统的差别入手进行分析。

对HDFS 的缺点也做了一些相应的介绍。

另外，重点对HDFS 的实现和使用做了很多的研究和分析。

对MapReduce 的研究我们主要建立在如何更好的使用MapReduce 进行并行编程的角度。

我们对MapReduce 的编程模式、执行流程以及各种计算过程的细节都做了较深入的分析。

本章的最后我们介绍了MapReduce 的容错机制、调度管理等内容。

第三章平台的搭建与验证
3．1 安装Ubuntu Linux操作系统
Linux操作系统的安装比较简单，在vitualbox上安装ubuntu10.10。

3．2 安装jdk
jdk的下载地址.。

安装步骤：
打开终端，进入放置jdk安装文件的目录cd
图3.2.2
执行该文件，执行命令。

jdk-6u43-linux-x64。

bin
JDK自动安装到:$JRE_HOMEbin:$PATH
保存并关闭文件，至此，jdk的安装与配置就完成了。

3．3 修改机器名
本次试验一共用到了三台虚拟机上的机器，其中一台机器作为master，另外两台机器分别为slaver1和slaver2，这样方便区分机器，机器名由etc –t rsa –p ―‖，当出现如下的提示之后，说明配置成功：
图3.4.2
然后执行cat ~。

sshid_dsa.pub >> ~.sshauthorized_keys，完成之后，就可以实现无密码登陆了。

图3.4.3
图3.4.4
3．5 安装hadoop
我们这个实验，选用的是目前hadoop的稳定版本：>
<property>
<name>fs。

default。

name<name>
<value>>
配置conf>
<property>
<name>dfs。

replication<name>
<value>1<value>
<property>
<configuration>
配置confmapred-site。

xml:
<configuration>
<property>
<name>mapred。

job。

tracker<name>
<value>localhost:9001<value>
<property>
3．6 在单机上运行hadoop
启动hadoop:
图3.6.1
打开浏览器，输入htto:localhost:50030，若出现如下页面，则说明hadoop成功启动：
图3.6.2
下面是运行hadoop自带的wordcount例子的过程，先在hdfs的根目录下创建一个input文件夹，然后将bin目录下的所有。

sh文件放入input 中：
图3.6.3
运行程序：
图3.6.4
下面是例子运行的结果，结果保存在output文件夹中：
图3.6.5
至此，我们已经在单机上成功安装了hadoop。

接下来结合其它两台电脑部署一个hadoop的集群。

3．7 在三台电脑上部署hadoop集群
修改
等人提出的基于代数签名的方法;Wang 等人提出的基于BLS 同态签名
和RS 纠错码的方法等。

4．1．4 数据隐私保护
云中数据隐私保护涉及数据生命周期的每一个阶段。

Roy等人将集中信息流控制(DIFC)和差分隐私保护技术融入云中的数据生成与计算阶段,提出了一种隐私保护系统airavat,防止map reduce 计算过程中非授权的隐私数据泄露出去,并支持对计算结果的自动除密。

在数据存储和使用阶段,Mowbray 等人提出了一种基于客户端的隐私管理工具,提供以用户为中心的信任模型,帮助用户控制自己的敏感信息在云端的存储和使用。

Munts-Mulero 等人讨论了现有的隐私处理技术,包括K 匿名、图匿名以及数据预处理等,作用于大规模待发布数据时所面临的问题和现有的一些解决方案。

Rankova 等人则在文献中提出一种匿名数据搜索引擎,可以使得交互双方搜索对方的数据,获取自己所需要的部分,同时保证搜索询问的内容不被对方所知,搜索时与请求不相关的内容不会被获取。

虚拟安全技术虚拟技术是实现云计算的关键核心技术,使用虚拟技术的云计算平台上的云架构提供者必须向其客户提供安全性和隔离保证。

Santhanam 等人提出了基于虚拟机技术实现的grid 环境下的隔离执行机。

Raj 等人提出了通过缓存层次可感知的核心分配,以及给予缓存划分的页染色的两种资源管理方法实现性能与安全隔离。

这些方法在隔离影响一个VM 的缓存接口时是有效的,并整合到一个样例云架构的资源管理(RM)框架中。

Wei等人在文献中关注了虚拟机映像文件的安全问题,每一个映像文件对应一个客户应用,它们必须具有高完整性,且需要可以安全共享的机制。

所提出的映像文件管理系统实现了映像文件的访问控制、来源追踪、过滤和扫描等,可以检测和修复安全性违背问题。

4．1．5 云资源访问控制
在云计算环境中,各个云应用属于不同的安全管理域,每个安全域都管理着本地的资源和用户。

当用户跨域访问资源时,需在域边界设置认证服务,对访问共享资源的用户进行统一的身份认证管理。

在跨多个域的资源访问中,各域有自己的访问控制策略,在进行资源共享和保护时必须对共享资源制定一个公共的、双方都认同的访问控制策略,因此,需要支持策略的合成。

这个问题最早由Mclean 在强制访问控制框架下提出,他提出了一个强制访问控制策略的合成框架,将两个安全格合成一个新的格结构。

策略合成的同时还要保证新策略的安全性,新的合成策略必须不能违背各个域原来的访问控制策略。

为此,Gong 提出了自治原则和安全原则。

Bonatti 提出了一个访问控制策略合成代数,基于集合论使用合成运算符来合成安全策略。

Wijesekera 等人提出了基于授权状态变化的策略合成代数框架。

Agarwal 构造了语义Web 服务的策略合成方案。

Shafiq 提出了一个多信任域RBAC 策略合成策略,侧重于解决合成的策略与各域原有策略的一致性问题。

4．1．6 可信云计算
将可信计算技术融入云计算环境,以可信赖方式提供云服务已成为云安全研究领域的一大热点。

Santos 等人在文献中提出了一种可信云计算平台TCCP,基于此平台,IaaS 服务商可以向其用户提供一个密闭的箱式执行环境,保证客户虚拟机运行的机密性。

另外,它允许用户在启动虚拟机前检验Iaas 服务商的服务是否安全。

Sadeghi 等人认为,可信计算技术提供了可信的软件和硬件以及证明自身行为可信的机制,可以被用来解决外包数据的机密性和完整性问题。

同时设计了一种可信软件令牌,将其与一个安全功能验证模块相互绑定,以求在不泄露任何信息的前提条件下,对外包的敏感(加密)数据执行各种功能操作[7]。

4．2 Hadoop 企业级应用的弱点分析
4．2．1 Hadoop 系统单点设计瓶颈
当前Hadoop 单一NameNode，单一JobTracker 的设计严重制约了整个Hadoop可扩展性和可靠性。

尤其Namenode 是HDFS 集群中的单点故障(single point of failure)的关键所在。

单一的NameNode 主要存在以下三方面的问题。

第一，单一NameNode 如果出现宕机或者需要重启，那么整个Hadoop 集群将不能正常运行，一般重新启动NameNode 需要数小时。

对于一个对生产环境要求比较严格的企业来说，Hadoop 集群不能够保证7*24 的稳定生产环境，这一点是Hadoop 的致命弱点。

第二，单一Namenode 的内存容量有限，使得Hadoop 集群的节点数量被限制到2000 个左右，能支持的文件系统大小被限制在10-50PB, 最多能支持的文件数量大约为1。

5 亿左右。

第三，单一Namenode 造成DataNode 的blocks report 也会对Namenode 的性能造成严重的影响。

例如系统有1800 个Datanode, 每个
Datanode 有3T 存储，整个集群大约有1。

8P 有效存储。

那么每个Datanode 上有大约50000 个左右的block，假设Datanode 每小时会发送一次block report，那么Namenode 每两秒会收到一次block report，每个block report 包含50000 条数据，处理这些数据无疑会占用相当多的资源。

4．2．2 作业调度方式单一
Hadoop 内置有一种简单的先进先出(FIFO)的作业调度算法，对于不同大小的作业，FIFO 调度算法对于小作业就表现出了严重的不公平性，为了缓解这一问题，又有一些新的调度算法被以插件的形式集成到Hadoop 中去，使用比较多的有公平调度算法(Fair Scheduler) 和计算能力调度算法(Capacity Scheduler)。

虽然相对FIFO 算法已经有了较大的进步。

但是由于企业环境复杂，作业类型繁多，作业的个性化需求也很多，使得Hadoop 现有的作业调度算法很难满足企业的需求，所以为了有效地满足企业复杂的需求，就需要更多的作业调度算法。

LSF 是在企业经过多年验证的一个网格计算框架，其中内置了大量的作业调度算法，论文通过将LSF 与Hadoop 集成来弥补Hadoop 作业调度算法匮乏的问题。

4．2．3 异构平台兼容性
从Hadoop 应用的诸多成功案例中可以看出，主要是互联网企业，例如Facebook，Yahoo 等。

而互联网应用模式是一种简单的应用模式，传统IT 行业则复杂得多，传统的IT 企业由于发展时间比较长，企业内部存在大量的异构机器，目前的Hadoop 只考虑了同构的环境，在异构环境下效率低下。

论文提出的LSF与Hadoop 的系统整合会让Hadoop 在异构平台上也能够发挥很高的效率[8]。

第五章公司提出。

IETF ONC 宪章重新修订了Sun 版本，使得ONC RPC 协议成为IETF 标准协议。

现在使用最普遍的模式和执行是开放式软件基础的分布式计算环境（DCE）。

5．1．1 工作原理
运行时,一次客户机对服务器的RPC调用,其内部操作大致有如下十步：
1.调用客户端句柄；执行传送参数
2.调用本地系统内核发送网络消息
3.消息传送到远程主机
4.服务器句柄得到消息并取得参数
5.执行远程过程
6.执行的过程将结果返回服务器句柄
7.服务器句柄返回结果，调用远程系统内核
8.消息传回本地主机
9.客户句柄由内核接收消息
10.客户接收句柄返回的数据
RPC OVER HTTP
Microsoft RPC-over-HTTP 部署(RPC over HTTP)允许RPC客户端安全和有效地通过Internet 连接到RPC 服务器程序并执行远程过程调用。

这是在一个名称为RPC-over-HTTP 代理，或简称为RPC 代理的中间件的帮助下完成的。

RPC 代理运行在IIS计算机上。

它接受来自Internet 的RPC 请求，在这些请求上执行认证，检验和访问检查，如果请求通过所有的测试，RPC 代理将请求转发给执行真正处理的RPC 服务器。

通过RPC over HTTP，RPC客户端不和服务器直接通信，它们使用RPC 代理作为中间件。

5．1．2 协议结构
远程过程调用（RPC）信息协议由两个不同结构组成：调用信息和答复信息。

信息流程如下所示：
RPC：远程过程调用流程
RPC 调用信息：每条远程过程调用信息包括以下无符号整数字段，以独立识别远程过程：
程序号（Program number）
程序版本号（Program version number）
过程号（Procedure number）
RPC 调用信息主体形式如下：
struct call_body {
unsigned int rpcvers;
unsigned int prog;
unsigned int vers;
unsigned int proc;
opaque_auth cred;
opaque_auth verf;
1 parameter
2 parameter 。

}；
RPC 答复信息：RPC 协议的答复信息的改变取决于网络服务器对调用信息是接收还是拒绝。

答复信息请求包括区别以下情形的各种信息：RPC 成功执行调用信息。

RPC 的远程实现不是协议第二版，返回RPC 支持的最低和最高版本号。

在远程系统中，远程程序不可用。

远程程序不支持被请求的版本号。

返回远程程序所支持的最低和最高版本号。

请求的过程号不存在。

通常是呼叫方协议或程序差错。

RPC答复信息形式如下：
enum reply_stat stat
{MSG_ACCEPTED = 0,
MSG_DENIED = 1 }；
5．1．3 Hadoop RPC机制及原理
Hadoop RPC的实现主要在org.apache.：RPC Server数据的接收者。

提供接收数据，解析数据包的功能。

Server.Call：持有客户端的Call信息。

RPC Server的主要流程
RPC Server作为服务的提供者主要有两部分组成：接收Call调用和处理Call调用。

接收Call调用负责接收来自RPC Client的调用请求，编码成Call对象放入到Call队列中，这一过程有Server。

Listener完成。

具体步骤如下：Listener线程监听RPC Client发过来的数据
当有数据可以接收时，调用Connection的readAndProcess方法
Connection对边接受过来的数据边处理，当接到一个完整的Call包，则构建一个Call对象，PUSH到Call队列中，有Handler来处理Call队列中的所有Call
处理完的Call调用负责处理Call队列中的每一个调用请求，有Handler 线程来完成：
Handler线程监听Call队列，如果Call队列非空，按FIFO规则从Call 队列中取出Call
将Call交给RPC.Server来处理
借助JDK提供的Method，完成对目标方法的调用，目标方法由具体的业务逻辑实现
返回响应。

Server.Handler按照异步非阻塞的方式向RPC Client发送响应，如果有未发送出的数据，则交由Server.Responder来完成。

完整的交互过程如下:。