本帖最后由 资深从业爱好者 于 2022-11-7 14:00 编辑
分布式文件系统的主要功能有两个：一个是存储文档、图像、视频之类的 Blob 类型数据；另外一个是作为分布式表格系统的持久化层。
1、 Google 文件系统（ GFS ）
GFS, Big Table, Map Reduce 称为 Google 的三驾马车，是许多基础服务的基石。
GFS 于 2003 年提出，是一个分布式的文件系统，与此前的很多分布式系统的前提假设存在很大的不同，适用于以下场景
（ 1 ）认为组件失效是一种常态，提供了容错机制，自动负载均衡，使得分布式文件系统可以在廉价机器上运行；
（ 2 ）面向大文件存储，系统主要的工作负载是大规模的流式读取，写操作主要是追加方式写，很少有随机写；
（ 3 ）一次写入，多次读取，例如互联网上的网页存储
GFS 文件被划分为固定大小的数据块（ chunk ），由主服务器在创建时分配一个 64 位全局唯一的 chunk 句柄。CS 以普通的 Linux 文件的形式将 chunk 存储在磁盘中。为了保证可靠性， chunk 在不同的机器中复制多份，默认为三份。
主控服务器中维护了系统的元数据，包括文件及 chunk 命名空间、文件到 chunk 之间的映射、 chunk 位置信息。它也负责整个系统的全局控制，如 chunk 租约管理、垃圾回收无用 chunk 、 chunk 复制等。主控服务器会定期与 CS 通过心跳的方式交换信息。
客户端是 GFS 提供给应用程序的访问接口，它是一组专用接口，不遵循 POSIX 规范，以库文件的形式提供。客户端访问 GFS 时，首先访问主控服务器节点，获取与之进行交互的 CS 信息，然后直接访问这些 CS ，完成数据存取工作。
需要注意的是， GFS 中的客户端不缓存文件数据，只缓存主控服务器中获取的元数据，这是由 GFS 的应用特点决定的。GFS 最主要的应用有两个：MapReduce 与 Bigtable 。对于 MapReduce,GFS 客户端使用方式为顺序读写，没有缓存文件数据的必要；而 Bigtable 作为分布式表格系统，内部实现了一套缓存机制。另外，如何维护客户端缓存与实际数据之间的一致性是一个极其复杂的问题。
由此可见， Hadoop 的 HDFS 其实是 GFS 的简化版，是 Cutting 博士“山寨” GFS 出来的产物。是盗火种的产物。
2、 Taobao 文件系统（ TFS ）
互联网应用经常需要存储用户上传的文档、图片、视频等，比如 Facebook 相册、淘宝图片、 Dropbox 文档等。文档、图片、视频一般称为 Blob 数据。Blob 文件系统的特点是数据写入后基本都是只读，很少出现更新操作，这就是 Taobao 文件系统（ TFS ）的主要特点。
TFS 架构上借鉴了 GFS ，但与 GFS 又有很大的不同。
（1） TFS 内部不维护文件目录树，扁平化的数据组织结构，可将文件名映射到文件的物理地址，简化了文件的访问流程；
（2） 针对海量小文件的随机读写访问性能做了特殊优化，满足了淘宝对小文件存储的需求，被广泛地应用在淘宝各项应用中；
（3） 采用了 HA 架构和平滑扩容，保证了整个文件系统的可用性和扩展性。
一个 TFS 集群由两个 NameServer 节点（一主一备）和多个 DataServer 节点组成， NameServer 通过心跳对 DataSrver 的状态进行监测。NameServer 相当于 GFS 中的 Master,DataServer 相当于 GFS 中的 ChunkServer 。NameServer 区分为主 NameServer 和备 NameServer ，只有主 NameServer 提供服务，当主 NameServer 出现故障时，能够被心跳守护进程检测到，并将服务切换到备 NameServer 。每个 DataServer 上会运行多个 dsp 进程，一个 dsp 对应一个挂载点，这个挂载点一般对应一个独立磁盘，从而管理多块磁盘。
在 TFS 中，将大量的小文件（实际数据文件）合并成一个大文件（这一点比 HDFS 有优化和改进），这个大文件称为块（ Block ），每个 Block 拥有在集群内唯一的编号（块 ID ），通过＜块 ID ，块内偏移＞可以唯一确定一个文件。TFS 中 Block 的实际数据都存储在 DataServer 中，大小一般为 64MB ，默认存储三份，相当于 GFS 中的 chunk 。应用客户端是 TFS 提供给应用程序的访问接口，应用客户端不缓存文件数据，只缓存 NameServer 的元数据。
3、 Fackbook Haystack 文件系统
到 2014 年， Facebook 大概有超 4000 亿张图片，总大小为 30PB ，通过计算可以得出每张照片的平均大小为 30PB/260GB ，约为 100KB 。用户每周新增照片数为 10 亿（总大小为 60TB ），平均每秒新增的照片数为 109/7/40000 （按每天 40000s 计），约为每秒 3800 次写操作，读操作峰值可以达到每秒百万次。
Facebook 相册后端早期采用基于 NAS 的存储，通过 NFS 挂载 NAS 中的照片文件来提供服务。后来出于性能和成本考虑，自主研发了 Facebook Haystack 存储相册数据。
和 TFS 类似， Facebook Haystack 新架构主要解决图片存取 IO 次数过多的文件，主要的思路是多个逻辑文件共享同一个物理文件。Haystack 架构及读请求处理流程图如下
Haystack 架构主要有三个部分：Haystack Directory ， Haystack Store 以及 Haystack Cache 。Haystack Store 是物理存储节点，以物理卷轴 (physical volume) 的形式组织存储空间，每个物理卷轴一般很大，比如 100GB ，这样 10TB 的数据也只有 100 个物理卷轴。每个物理卷轴对应一个物理文件，因此，每个存储节点上的物理文件元信息都很小。多个物理存储节点上的物理卷轴组成一个逻辑卷轴 (logical volume) ，用于备份。Haystack Directory 存放逻辑卷轴和物理卷轴的对应关系，假设每个卷轴的大小为 100GB ，对应关系的条数为 20PB / 100GB = 0.2MB ，占用的内存可以忽略。Haystack cache 主要用于解决对 CDN 提供商过于依赖的问题，提供最近增加的图片的缓存服务。
Haystack 图片读取请求大致流程为：用户访问一个页面时， Web Server 请求 Haystack Directory 构造一个 URL ：http:// ＜ CDN ＞ / ＜ Cache ＞ / ＜ Machine id ＞ / ＜ Logical volume,Photo ＞ ，后续根据各个部分的信息依次访问 CDN ， Cache 和后端的 Haystack Store 存储节点。Haystack Directory 构造 URL 时可以省略 部分从而使得用户直接请求 Haystack Cache 而不必经过 CDN 。Haystack cache 收到的请求包含两个部分：用户 Browser 的请求及 CDN 的请求， Haystack cache 只缓存用户 Browser 发送的请求且要求请求的 Haystack Store 存储节点是可写的。一般来说， Haystack Store 的存储节点写一段时间以后达到容量上限变为只读，因此，可写节点的图片为最近增加的图片，是热点数据。
Haystack 的写请求 ( 图片上传 ) 处理流程为：Web Server 首先请求 Haystack Directory 获取图片的 id 和可写的逻辑卷轴，接着将数据写入对应的每一个物理卷轴 ( 备份数一般为 3) 。
Facebook Haystack 及 Taobao TFS 这样的文件系统一般称为 Blob 文件系统。它们都是解决大量的小图片文件的问题，因此架构很类似，不同点包括
（1） 逻辑卷轴大小的选择，比如 Haystack 选择 100GB 的逻辑卷轴大小， TFS 中 block 大小一般为 64MB ；
（2） Haystack 使用 RAID 6 ，且底层文件系统使用性能更好的 XFS ，淘宝后期摈除了 RAID 机制，文件系统使用 Ext3 ；
（3） Haystack 使用了 Akamai & Limelight 的 CDN 服务，而 Taobao 已经使用自建的 CDN ，当然， Facebook 也在考虑自建 CDN 。
4、 CDN 内容分发网络
CDN 的全称是 Content Delivery Network ，即内容分发网络。其目的是通过在现有的 Internet 中增加一层新的网络架构，将网站的内容发布到最接近用户的网络 " 边缘 " 。实现如下三个目的
（ 1 ）解决因分布、带宽、服务器性能带来的访问延迟问题，适用于站点加速、点播、直播等场景。使用户可就近取得所需内容，解决 Internet 网络拥挤的状况，提高用户访问网站的响应速度和成功率。
（ 2 ）控制时延无疑是现代信息科技的重要指标， CDN 的意图就是尽可能的减少资源在转发、传输、链路抖动等情况下顺利保障信息的连贯性。
（ 3 ） CDN 就是扮演者护航者和加速者的角色，更快准狠的触发信息和触达每一个用户，带来更为极致的使用体验。
如下图所示 DNS 在对域名解析时不再向用户返回源服务器的 IP ，而是返回了由智 CDN 负载均衡系统选定的某个边缘节点的 IP 。用户利用这个 IP 访问边缘节点，然后该节点通过其内部 DNS 解析得到源服务器 IP 并发出请求来获取用户所需的页面，如果请求成功，边缘节点会将页面缓存下来，下次用户访问时可以直接读取，而不需要每次都访问源服务器。
Taobao 的 CDN 架构是自研的，用于支持用户购物，尤其是“双 11” 光棍节时的海量图片请求，图片存储在后台的 TFS 集群中， CDN 系统将这些图片缓存到离用户最近的边缘节点。CDN 采用两级 Cache ：L1-Cache 以及 L2-Cache 。用户访问淘宝网的图片时，通过全局调度系统（ Global Load Balancing ）调度到某个 L1-Cache 节点。如果 L1-Cache 命中，那么直接将图片数据返回用户；否则，请求 L2-Cache 节点，并将返回的图片数据缓存到 L1-Cache 节点。如果 L2-Cache 命中，直接将图片数据返回给 L1-Cache 节点；否则，请求源服务器的图片服务器集群。每台图片服务器是一个运行着 Nginx 的 Web 服务器，它还会在本地缓存图片，只有当本地缓存也不命中时才会请求后端的 TFS 集群，图片服务器集群和 TFS 集群部署在同一个数据中心内。
对于每个 CDN 节点，其架构如图 4-11 所示。从图中可以看出，每个 CDN 节点内部通过 LVS+Haproxy 的方式进行负载均衡。其中， LVS 是四层负载均衡软件，性能好；Haproxy 是七层负载均衡软件，能够支持更加灵活的负载均衡策略。通过有机结合两者，可以将不同的图片请求调度到不同的 Squid 服务器。
上图是 CDN 的单节点架构，它有以下三个特点
（1） Squid 服务器构成淘宝单节点中的 CDN 中的分布式缓存，这个实现比分布式缓存简单很多，因为不需要考虑数据持久化。
（2） 分级缓存，由于缓存数据有较高的局部性，在 Squid 服务器上使用 SSD+SAS+SATA 混合存储，图片随着热点变化而迁移，最热门的存储到 SSD ，中等热度的存储到 SAS ，轻热度的存储到 SATA 。通过这样的方式，能够很好地结合 SSD 的性能和 SAS 、 SATA 磁盘的成本优势；
（3） 低功耗服务器定制， CDN 缓存服务是 IO 密集型而不是 CPU 密集型的服务，因此，选用 Intel Atom CPU 定制低功耗服务器，在保证服务性能的前提下大大降低了整体功耗。
|
楼主
标题置顶
标题高亮
;){kind=link}
不错