System | 分布式 | GFS | 腾讯 后端工程师 | Julia is a best learner | Excellent article in depth

Here is the article. 

gfs被称为谷歌的三驾马车之一，主要面向谷歌的大流量流式读取和append写，通过控制流与数据流解耦提升并发能力。

GFS架构

GFS核心在于，master只告诉你地址，不给你数据，要取数据？自己去问chunkserver。至于chunksever给不给，master说了算。

GFS的本质就是将数据流和控制流解耦，master只负责控制流，提供metadata，chunkserver只负责数据流，提供data。

Performance can be improved by scheduling expensive data flow based on the network topology。在数据推送过程中，可以选择最近的chunkserver，而不需要在意推送顺序。推送顺序由同步保证

 就是这么设计，master 只提供 url，但是 client 允许直接访问数据而没有加入校验的控制流，所以也不是很完善，而且返回url本身开销也很大 ( once per request )，增加控制流开销，也算是 trade-off 了。

相比之下，gfs 增加了 master 对数据的控制流，并且数据流远远大于控制流，在这种 workload下控制流和数据流分离就是绝佳的设计了。此时虽然 client 上控制流和数据流仍然耦合，但是因为他只是边缘端的，根本没有多少流量，所以也不会有什么性能瓶颈。

Single Master

存储文件系统的metadata于内存中

• Namespace
• Access Control Information
• Mapping from files to chunks
• Current locations of chunks

namespace 和 mapping 同时通过 operation log 持久化，location 则通过 chunkserver 的心跳来获得，决定系统的访问权限。

这里的 namespace 并非 inode 文件系统，没有 symlink 也没有 hardlink，路径名并非真正的目录，通过前缀压缩性能优化。（猜测数据结构为Trie，单词查找树，是哈希树的变种）每个节点都有一把读写锁。

master虽然有全局了解，简化设计，但不是bottleneck(后来的改进证明谷歌还是乐观了）

• client 从不读写 master，只请求通信的 chunkserver 地址
• master 可以提供后续 chunk 的额外信息，从而减少延迟
• 这些后续的 chunk 的读并不需要访问 master

master 的状态通过 log 和 checkpoint 备份，宕机时启动备份并且修改 DNS 从而得到primary。

这些备份的 "shadow"master 提供只读权限，但不要求强一致性从而避免性能开销，允许延后根据日志来进行同步。因此master在恢复的时候也允许进行读取，提供 fault tolerance。

Multiple Chunkservers

存储文件系统的data于内存中，每个chunk大小固定64MB。

数据冗余采用 3-way mirror，分散在不同机器、不同 rack，防止同时崩溃。

通过心跳信息与 master 通信，由 master 决定访问权限，但是 chunk 是否存在则由chunkserver 自己决定而非 master。

存在 primary/backup，由 primary 决定写入顺序保证同步并减轻 master 负担，primary 通过抢锁获得，抢到锁的成为 primary，但是需要定期续约，否则会自动释放（primary崩溃）。

读操作

• 应用向 client 发出读请求 read(filename, byte range)
• client 翻译为 read(filename, chunk index) 并请求 master
• master 响应 chunk handle 并告诉所有 replicas 的地址
• client 选择一个 replicas 并请求 read (chunk handle, byte range)
• chunk 根据访问权限，决定是否返回请求的数据
• client 将数据返回给用户

如果选择 replicas 检测到 checksum 不正确，则会返回错误并要求 client 重试其他 replicas，并向 master 请求同步其他 replicas。

checksum具体实现复制 https://www.cnblogs.com/lushilin/p/8665178.html

• 读操作的Checksum：只取Chunk小部分额外相关数据进行校验，客户端每次把读取操作对齐在Chunk块的边界上

写操作

1. 应用向client发出写请求write(filename,data)
2. client翻译为write(filename, chunk index) 并请求master
3. master响应chunk handle并告诉所有primary/backup replicas的地址
4. client对所有replicas请求write(chunk handle, byte range, data)或单纯append(chunk handle , data)
5. client请求primary 进行同步，进行持久化
6. primary决定buffer数据写的顺序，并写入chunk
7. primary把顺序告诉所有的backup要求他们以同样顺序执行
8. primary等待所有backup响应
9. primary返回响应给client，如果任意backup失败，client重试同步。

checksum具体实现复制 https://www.cnblogs.com/lushilin/p/8665178.html

• 记录追加操作的Checksum（高度优化）：只增量更新最后一个不完整Chunk块的Checksum
• 写操作的Checksum：先读取和校验被写操作覆盖的第一个和最后一个Chunk块，写操作完成后再重新计算和写入Chunksum

云时代的改进

Here is the link. 

Storage software: Colossus

• Next-generation cluster-level file system
• Automatically sharded metadata layer
• Data typically written using Reed-Solomn (1.5x)
• Client-driven replication, encoding and replication
• Metadata space has enabled availability analyses

Why Reed-Solomon?

• Cost. Especially w/ cross cluster replication.
• Field data and simulations show improved MTTF
• More flexible cost vs. availability choices

对于Master采取数据切分，进一步提高并发能力

对于Chunk使用1.5倍的冗余编码Reed-Solomon减少冗余备份，提供纠错机制

Problem: 提供大规模文件的分布式存储

Related work: 组件故障是常态, 规模不够大, 没有append专门优化，应用API没有共同设计

Observation: 控制流数据流分离 + 先推送数据再执行同步

Solution: Master只寻址chunk,Primary只需要顺序同步不需要数据同步。

Evaluation: 单Master掌握全局,高度中心化

Comments: 如果每个区域都需要本地化的GFS,那么Master放哪里呢？如果全球通用GFS,那么如何保证时延平衡呢？

编辑于 2020-07-11

•