分布式文件系统（DFS）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连；或是若干不同的逻辑磁盘分区或卷标组合在一起而形成的完整的有层次的文件系统。
分布式文件系统（Distributed File System，DFS）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点（可简单的理解为一台计算机）相连；或是若干不同的逻辑磁盘分区或卷标组合在一起而形成的完整的有层次的文件系统。
DFS 为分布在网络上任意位置的资源提供一个逻辑上的树形文件系统结构，从而使用户访问分布在网络上的共享文件更加简便。单独的 DFS 共享文件夹的作用是相对于通过网络上的其他共享文件夹的访问点。
简介
计算机通过文件系统管理、存储数据，而信息爆炸时代中人们可以获取的数据成指数倍的增长，单纯通过增加硬盘个数来扩展计算机文件系统的存储容量的方式，在容量大小、容量增长速度、数据备份、数据安全等方面的表现都差强人意。分布式文件系统可以有效解决数据的存储和管理难题：将固定于某个地点的某个文件系统，扩展到任意多个地点/多个文件系统，众多的节点组成一个文件系统网络。每个节点可以分布在不同的地点，通过网络进行节点间的通信和数据传输。
人们在使用分布式文件系统时，无需关心数据是存储在哪个节点上、或者是从哪个节点从获取的，只需要像使用本地文件系统一样管理和存储文件系统中的数据。分布式文件系统是建立在客户机/服务器技术基础之上的，一个或多个文件服务器与客户机文件系统协同操作，这样客户机就能够访问由服务器管理的文件。分布式文件系统的发展大体上经历子三个阶段：靠前阶段是网络文件系统，第二阶段是共享 SAN 文件系统，第三阶段是面向对象的并行文件系统。
分布式文件系统把大量数据分散到不同的节点上存储，大大减小了数据丢失的风险。分布式文件系统具有冗余性，部分节点的故障并不影响整体的正常运行，而且即使出现故障的计算机存储的数据已经损坏，也可以由其它节点将损坏的数据恢复出来。因此，安全性是分布式文件系统最主要的特征。分布式文件系统通过网络将大量零散的计算机连接在一起，形成一个巨大的计算机集群，使各主机均可以充分发挥其价值。此外，集群之外的计算机只需要经过简单的配置就可以加入到分布式文件系统中，具有极强的可扩展能力。
系统分类
网络文件系统
(NFS) 最早由 Sun 微系统公司作为 TCP/IP 网上的文件共享系统开发。Sun 公司估计大约有超过 310 万个系统在运行 NFS，大到大型计算机、小至 PC 机，其中至少有 80%的系统是非 Sun 平台。
Andrew 系统
AFS 是一种分布式的文件系统用来共享与获得在计算机网络中存放的文件。AFS 使得用户获得网络文件就像本地机器般方便。AFS 文件系统被称为“分布式”是因为文件可以分散地存放在很多不同的机器上，但这些文件对于用户而言是可及的，用户可以通过一定的方式得到这些文件。
KASS 系统
KASS File System（简称 KFS）是开始软件自主研发基于 JAVA 的纯分布式文件系统，功能类似于 DFS、GFS、Hadoop，通过 HTTP WEB 为企业的各种信息系统提供底层文件存储及访问服务，搭建企业私有云存储服务平台。
DFS 系统
DFS 是 AFS 的一个版本，作为开放软件基金会(OSF)的分布
式计算环境 DCE 中的文件系统部分。
如果文件的访问仅限于一个用户，那么分布式文件系统就很容易实现。可惜的是，在许多网络环境中这种限制是不现实的，必须采取并发控制来实现文件的多用户访问，表现为如下几个形式：
只读共享 任何客户机只能访问文件，而不能修改它，这实现起来很简单。
受控写操作 采用这种方法，可有多个用户打开一个文件，但只有一个用户进行写修改。而该用户所作的修改并不一定出现在其它已打开此文件的用户的屏幕上。
并发写操作 这种方法允许多个用户同时读写一个文件。但这需要操作系统作大量的监控工作以防止文件重写，并保证用户能够看到最新信息。这种方法即使实现得很好，许多环境中的处理要求和网络通信量也可能使它变得不可接受。
网络文件系统
网络文件系统（Network File System，NFS）是个分布式的客户机/服务器文件系统。NFS 的实质在于用户间计算机的共享。用户可以联结到共享计算机并像访问本地硬盘一样访问共享计算机上的文件。管理员可以建立远程系统上文件的访问，以至于用户感觉不到他们是在访问远程文件。NFS 是个到处可用和广泛实现的开放式系统。
NFS 设计目标
允许用户象访问本地文件一样访问其他系统上的文件。提供对无盘工作站的支持以降低网络开销。
简化应用程序对远程文件的访问使得不需要因访问这些文件而调用特殊的过程。
使用一次一个服务请求以使系统能从已崩溃的服务器或工作站上恢复。
采用安全措施保护文件免遭偷窃与破坏。
使 NFS 协议可移植和简单，以便它们能在许多不同计算机上实现，包括低档的 PC 机。
大型计算机、小型计算机和文件服务器运行 NFS 时，都为多个用户提供了一个文件存储区。工作站只需要运行 TCP/IP 协议来访问这些系统和位于 NFS 存储区内的文件。工作站上的 NFS 通常由 TCP/IP 软件支持。对 DOS 用户，一个远程 NFS 文件存储区看起来是另一个磁盘驱动器盘符。对 Macintosh 用户，远程 NFS 文件存储区就是一个图标。
分布式文件系统 KFS
一个 KFS 集群包括单个元数据服务器节点和多个 Chunk 服务器节点，并由多个客户端来访问。其中元数据服务器主要用于维护元数据并负责控制垃圾回收、负载均衡等系统活动，Chunk 服务器负责保存数据以及接收处理数据 I/O 请求。这两类节点均运行 Linux 操作系统，需要分别安装、运行 KFS 提供的元数据服务器和 Chunk 服务器软件。客户端需要安装专门的 KFS 客户端库，由应用程序链接使用来访问 KFS 文件系统。KFS 的所有节点都均采用 X86 架构硬件，并通过以太网方式连接在一起，节点之间采用 TCP 协议通讯，使得整个系统具有较高的性价比。
Chunk 服务器
在 KFS 中，一个文件被分割成多个 Chunk，每个 Chunk 大小固定为 64MB，所以可以通过简单的模运算计算出某文件偏移量在该文件第几个 Chunk 的多少偏移量上。每个 Chunk 由一个全局较早的 Chunk 号来标识。Chunk 服务器主要的功能就是保存 Chunk，并对外提供创建、删除、读写 Chunk 的访问接口。一个 Chunk 默认被复制成 3 份，保存在 3 个不同的 Chunk 服务器中，客户端可以为每个文件指定不同的副本个数。三副本就保证了在两个 Chunk 服务器故障的情况下，仍能从第三个 Chunk 服务器上的副本读出数据，提高了系统的可靠性。在 Chunk 数据写入时，若某个 Chunk 服务器突然故障，会导致的相应副本更新失败，进而影响 Chunk 各副本数据的一致性。
为了解决这个问题，KFS 为每个 Chunk 副本分配一个版本号，副本每被更新一次则版本号上升，这样就可以通过比较版本号来发现过期的副本。Chunk 服务器中，单个 Chunk 由一个文件来表示，这些 Chunk 文件被保存在本地的文件系统中，文件系统可以是 XFS、Ext3/4 等。每个 Chunk 文件除了保存数据外，其头部还保存了 16KB 大小的校验和信息：写数据时，为每个 64K 数据块计算一个 32 位校验和（Adler-32 算法），保存至 Chunk 文件头部；读数据时，首先验证读出数据的校验和，这就保证了本地磁盘保存数据时可能发生的数据损坏可以被检查出来。
Chunk 文件在本地文件系统的文件名命名规则为：文件号.Chunk 号.版本号。Chunk 服务器启动时通过扫描存放 Chunk 文件的目录，就可获知自己拥有哪些 Chunk，然后把该信息提交给元数据服务器。元数据服务器在验证 Chunk 信息后，会告知 Chunk 服务器哪些 Chunk 已经过期（版本号过期或属于已被删除的文件），Chunk 服务器便可以删除这些 Chunk。
在 KFS 中，一个文件系统的所有元数据由单个元数据服务器统一管理，这一做法虽然影响了系统的可扩展性，但极大简化了系统的设计。元数据包括了：
（1） 目录项信息：KFS 采用传统的目录结构命名空间，目录树中的所有节点（文件和目录），均由一个全局较早的文件号来标识，根目录的文件号固定为 2，目录项信息指的是目录树中各目录所包含的各目录项（可以是子目录或文件）的名称及文件 ID；
（2） 属性信息：各目录、文件的创建、修改时间，及文件的副本数、大小；
（3） Chunk 信息：一个文件依次由哪些 Chunk 组成的；
（4） 位置信息：Chunk 的各个副本的被保存在哪个 Chunk 服务器上；
（5） 租约信息：KFS 采用租约来维持多个客户端情况下数据的一致性，这些租约信息由元数据服务器统一管理。
客户端
KFS 的客户端库向应用程序开发者提供了 create、read、write、mkdir、rmdir 等类似 POSIX 语义的编程接口，支持的编程语言有 C++、Python、Java。客户端库通过与元数据服务器及 Chunk 服务器交互，完成对文件系统中文件的修改、访问等操作。此外，客户端还支持 FUSE（File system in Userspace），使得传统文件系统工具（如 ls 命令）也可以访问 KFS 文件系统，提高了系统的互操作性。
为了减少与元数据服务器的交互次数，客户端会缓存元数据信息。此外，KFS 的客户端还会对读取、写入的数据进行缓存，这就存在缓存一致性的问题，KFS 采用读写租约（Lease）解决了这个问题，所有的租约由元数据服务器统一管理，每个租约有 300 秒的时限，过期作废。读写租约的具体方式是：
（1） 写租约：当需要向 Chunk 写入数据时，对应的主 Chunk 服务器首先查看是否拥有该 Chunk 的写租约，如果没有或已过期则尝试向元数据服务器获取或更新写租约，如果该 Chunk 正在被复制到其他 Chunk 服务器或者已经分配写租约或读租约，则返回失败，否则返回成功并且 Chunk 的版本号增一；
（2） 读租约：在客户端需要读取某个 Chunk 的数据时，它首先尝试去获取这个 Chunk 的读租约，如果该 Chunk 没有分配写租约而且数据已全部写入磁盘，则返回成功，否则返回失败。读写租约保证了一个 Chunk 同时只能由一个客户端写入，而且一个或多个客户端在读取某 Chunk 数据时，该 Chunk 数据不会被修改，这样客户端就能够把读取的数据缓存在本地，因为缓存中的数据与 Chunk 服务器上保存的数据一定是一致的。
分布式系统负载均衡策略
在分布式系统中通常有数量巨大的服务器节点，由于客户端在访问服务器节点的时候具有随机性，这就必然会导致部分主机在某些时刻成为热点，对整个分布式系统的性能产生了制约。与此同时，部分服务器节点的负载却远远没有达到额定值，从而造成资源浪费。显然，在分布式文件系统中进行负载均衡控制是十分必要的。在软件工程中，网站访问流量的分配、数据库访问的重定向等都是负载均衡应用的典型场景。通过负载均衡技术的应用，可以实现分布式系统中所有节点的负载相对平衡，既保证了系统的性能，又充分利用了资源。负载均衡意味着节点之间需要进行数据迁移，因此负载均衡本身需要有一定的开销，所以通常要求负载均衡算法具有较高的效率。
分布式文件系统是以数据服务器为核心的存储系统，根据数据服务器在形式上是否具有中心节点，一般将其分为集中式和非集中式两大类拓扑结构，其中前者是以某台服务器作为中心节点进行分布式组网，而后者则不需要中心节点服务器。之所以要这样区分，是因为中心节点的存在与否，对负载均衡策略的制定有重要影响。
免责声明：文章内容不代表本站立场，本站不对其内容的真实性、完整性、准确性给予任何担保、暗示和承诺，仅供读者参考；文章版权归原作者所有！本站作为信息内容发布平台，页面展示内容的目的在于传播更多信息；本站不提供任何相关服务，阁下应知本站所提供的内容不能做为操作依据。市场有风险，投资需谨慎！如本文内容影响到您的合法权益（含文章中内容、图片等），请及时联系本站，我们会及时删除处理。
