http://blog.csdn.net/tujiyue/article/details/7042367
序：
一旦存在多台实际服务器提供同样的web服务时，一个潜在的问题就是如何保证多台实际服务器的程序和文件一致呢？
13.1 网络共享
从使用角度看，共享文件系统几乎不用你考虑网络传输和访问的细节，完全可以像访问本地文件一样访问网络上其它服务器文件系统上的文件。这可以在一定程度上解决开始提的问题，即为集群中的多台实际服务器共享同一台物理存储设备。
刚才提到的同一台物理存储设备可以是独立的一台服务器如图片服务器，也可以是集群中某台实际服务器的磁盘。
共享文件系统并不是通常我们说的磁盘文件系统，它不能用于存储和管理磁盘数据，而只是定义了文件在网络上传输时的组织格式和传输协议。所以，一个文件从网络的一端到另一端需要进行两次转换，分别发生在进入网络和离开网络的时候。
对于共享文件系统的实现通常有NFS和Samba，其中NFS主要用于Linux/Unix平台下，而Samba用于将Linux/Unix平台下的文件映射到Window系统网络邻居上，用于实现Linux/Unix到Window平台的共享，当然，它也可以实现Linux/Unix平台之间的文件共享。
NFS和Samba实现完全不同，其性能存在较大的差异。
13.2 NFS
NFS是sun公司于1984年开发，直到现在，它一直是主流异构平台实现文件共享的首选方案之一。
共享文件系统主要包括文件格式和传输协议的定义，NFS并没有设计自己的传输协议，它是直接使用基于RPC的传协议，工作在应用层，负责客户端和服务器端之间请求和响应数据的传输控制。
NFS的服务器和客户端软件一般在Linux中被默认安装，配置也比较容易。NFS虽然采用RPC作为应用层协议，但其性能更多取决于传输层协议TCP/UDP以及服务器端和客户端程序的实现。
对于传输层，RPC服务默认使用UDP，当网络质量较差的时候，一旦数据包发生丢失，这些数据包的重发工作由应用层的RPC来进行，它将重发整个RPC请求，显然这种效率没有TCP自动重传机制更高效。当然，TCP也有缺点，它没有UDP无状态的优越性，但也不是绝对的，要取决于具体的应用。
NFS服务器采用多进程模型，而且进程数是固定的，默认情况下为4，当然，可以进行修改。不论怎么对NFS进行性能优化，NFS注定不适合IO密集型文件的共享方案。但作为一般用途比如提供站内资源的共享，它是比较容易搭建的，可以减少不必要的数据冗余。
NFS远程写操作有同步和异步两种模式，对于异步模式，NFS可以在接收到写操作请求后立即返回成功，然后在后台执行真正的写操作。对于同步模式，NFS在写操作完成后才返回，当然，这里不一定是写到磁盘。对于异步模式，由于存在实际写入磁盘的延迟，所以非常有可能发生实际写入失败而应用程序并不知晓的情况，在没有保障的情况下，使用异步模式要格外谨慎。
13.3 局限性
不同于本地磁盘IO，通过NFS对远程文件进行写操作时，影响性能的不仅仅是NFS服务器本身磁盘吞吐率上限，还有NFS服务器端的并发处理能力和网络带宽。
对于小文件的远程访问，NFS服务器程序的并发处理能力不容乐观。对于较大文件的访问，数据在网络上的传输占了主要时间，这时网络带宽的充分消耗意味着NFS服务器的磁盘吞吐率也随之趋向极限，同时NFS服务器将成为文件访问的瓶颈，它只能为很少的服务器提供文件共享服务，特别是当web服务器拥有较大网络带宽时，并且几乎消耗殆尽的时候，这样的一台web服务器足以让NFS服务器不堪重负，当然，可以为NFS提供RAID磁盘阵列来提高并发处理能力，同时提高磁盘吞吐率上限。
共享文件系统最重要的一点是存在单点故障缺陷。