|
系统特点：对大文件友好，支持追加写。
租约机制：Chunk之间通过租约机制选主，减少了Master的压力。
追加流程
数据流是复制连，控制流与数据流分开。数据流是复制连的优点是，减少延时、节省带宽，尤其是在跨交换机的情境下。
数据流与控制流分开的优点是，GFS专门设计给大文件（舍弃小文件），猜测可能是在异常情况下（例如，切主）减少带宽（数据流记录在日志中，控制流决定是否写入，如果切主可以重发控制流，不用发数据）。
多端并发，通过重试解决，Chunk上的数据保证数据的偏移量和长度一致，但不保证二进制级别一致。
负载均衡：特别说明一下，GFS中限制了最近创建次数，防止新机器加入导致单点过热问题。
快照：GFS支持文件快照，这个实现比较复杂，机制比较经典。在元数据中需要记录快照信息，但是ChunkServer上的数据并不复制，而是写时复制。
注：GFS的成功，说明单Master是可以支持几k-1w甚至更大规模的集群，只要设计合理。
业务特点：主要用于存储淘宝网的图片，写少读多，追加写多、随机写少。
系统瓶颈
1. 数据量很大，元数据过大（100亿张图片，一张图片100字节，1TB源数据），解决方法是元数据分级中心节点存一部分，DataServer存一部分。
2. 读多写少的场景，大量的读会导致IO次数放大，至少三次，第一是读目录到内存，第二是文件的Inode加载到内存，第三是读数据。解决方法是数据组织单位是Block，很多个图片数据组成一个Block，一个Block对应一个物理文件（类似Chunk）。
TFS架构
中心节点一主一备，强一致，通过外部服务监控切主。数据节点一主两备，强一致模型，并未采用复制链的方式，更没有将数据流与控制流分开。每个图片有一个ID，与Block ID，组成唯一表示，作为元数据存储在Meta表中。给每个图片分一个ID，不用Block的偏移量和长度表示，主要还是考虑系统内部迁移、容灾等情况下对业务的透明。DataServer会维护Block ID 与 图片 ID的关系和索引。
追加流程
每次写会请求Master询问Block和主从关系，然后主强一致同步给两个从。这样做主要是业务场景为写少。
注：TFS从接口上说不遵循POSIX接口，且不维护目录树，数据间不存在依赖关系，更像是对象系统或者Blob系统，与传统的文件系统区别较大。
业务特点
读写QPS较高，写达到3.5K，读甚至达到百万级别。
系统架构
主要分为目录、存储、缓存。目录中的元数据包括照片ID多逻辑卷轴的对应关系，逻辑卷轴到物理卷轴的对应关系，一个物理卷轴100G。写请求想目录申请照片ID、逻辑卷轴以及对应的物理卷轴位置，客户端写三分保证强一致。
讨论
100G的物理卷轴在数据迁移等操作是恢复时间较慢，20M带宽预计1个半小时。
注：本文介绍的过于简单，可以看论文了解更多。
主要思想：靠近用户的位置缓存数据，分级缓存，不命中回源。
接入层：4层结构 + 7层结构，保证性能 + 功能。
业务场景：Blob类型存储写少读多，比较适合CDN，有事起热点视频更适合，写一次读可能达到上亿次。
注意问题：数据失效，数据被删除之后如何使CDN及时失效？
GFS作为文件系统的鼻祖，论文更是被广泛研究，本文着重介绍了GFS，其他部分主要是针对不同的设计方案进行了一下对比，并没有过多详细的介绍。
| 
转播
