【NFS】Linux中nfs和rpcbind的关系
只知道装nfs和rpcbind，然后简单发布，nfs就好了。
现在想了解下底层的原理。
我看有些文档说只装nfs-utils就能启动了，那么，rpcbind到底是个东西，充当个什么角色？
nfs组件，portmap新版下改名为rpcbind了。
- /etc/init.d/rpcbind里面有说明
rpcbind Start/Stop RPCbind
#
# chkconfig: 2345 13 87
# description: The rpcbind utility is a server that converts RPC program \
# numbers into universal addresses. It must be running on the \
# host to be able to make RPC calls on a server on that machine.
-
它是一个RPC服务，主要是在nfs共享时候负责通知客户端，服务器的nfs端口号的。简单理解rpc就是一个中介服务。
-
/etc/init.d/rpcbind是开启rpc服务的命令
NFS基于RPC（远程过程调用），NFS本身没有提供传输机制，传输机制通过RPC实现，RPC服务在rhel6中是rpcbind，在rhel5中是portmap，rpc端口号111，nfs端口号2049
所以 要启动 nfs服务，先要开启rpc机制！
设置共享文件时，要同时关注配置文件对文件/目录 和 本地对 文件/目录 的权限设置问题。
在Linux中的rpcbind服务到底是做什么的？
RPC即Remote Procedure Call Protocol（远程过程调用协议），rpcbind用于取代旧版本中的portmap组件。
简单说，rpcbind就是为了将不同服务与对应的端口进行绑定，以便支持机器间的互操作。
RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。
在服务器端，进程保持睡眠状态直到调用信息到达为止。
当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。
有多种 RPC模式和执行。最初由 Sun 公司提出。IETF ONC 宪章重新修订了 Sun 版本，使得 ONC RPC 协议成为 IETF 标准协议。现在使用最普遍的模式和执行是开放式软件基础的分布式计算环境（DCE）。
RPC 的主要功能目标是让构建分布式计算（应用）更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性。为实现该目标，RPC 框架需提供一种透明调用机制让使用者不必显式的区分本地调用和远程调用，在前文《浅出篇》中给出了一种实现结构，基于 stub 的结构来实现。
下面我们将具体细化 stub 结构的实现。
RPC 调用分类
RPC 调用分以下两种：
-
同步调用
客户方等待调用执行完成并返回结果。 -
异步调用
客户方调用后不用等待执行结果返回，但依然可以通过回调通知等方式获取返回结果。
若客户方不关心调用返回结果，则变成单向异步调用，单向调用不用返回结果。
RPC 实现概念结构
image.png
RPC 服务方通过 RpcServer 去导出（export）远程接口方法，而客户方通过 RpcClient 去引入（import）远程接口方法。客户方像调用本地方法一样去调用远程接口方法，RPC 框架提供接口的代理实现，实际的调用将委托给代理RpcProxy 。代理封装调用信息并将调用转交给RpcInvoker 去实际执行。
在客户端的RpcInvoker 通过连接器RpcConnector 去维持与服务端的通道RpcChannel，并使用RpcProtocol 执行协议编码（encode）并将编码后的请求消息通过通道发送给服务方。
RPC 服务端接收器 RpcAcceptor 接收客户端的调用请求，同样使用RpcProtocol 执行协议解码（decode）。解码后的调用信息传递给RpcProcessor 去控制处理调用过程，最后再委托调用给RpcInvoker 去实际执行并返回调用结果。
