这是我参与「第四届青训营 」笔记创作活动的第16天
我们为什么要阅读这篇论文？
分布式存储是一个关键的抽象 接口/语义应该是什么样的？ 它应该如何在内部工作？ GFS 论文涉及 6.824 的许多主题 并行性能、容错、复制、一致性 优秀的系统论文——从应用程序到网络的详细信息 成功的现实世界设计 影响力：Hadoop的HDFS
为什么分布式存储很难？
高性能 -> 在多台服务器上分片数据 许多服务器 -> 不断的故障 容错->复制 复制 -> 潜在的不一致 更好的一致性 -> 低性能
我们想要什么来保持一致性？
理想模型：与单个服务器相同的行为 理想的服务器一次执行一个客户端操作 即使多个客户端同时发出操作，读取显示的是以前的写入 即使服务器崩溃并重新启动，所有客户看到相同的数据 因此： 假设 C1 和 C2 并发写入，并且在写入之后，完成后，C3 和 C4 读取。他们能看到什么？ C1: W x=1 C2: W x=2 C3: R x=? C4: R x=? 答案：1 或 2，但两者必须看到相同的值。这是一个“强”一致性模型。 但是单台服务器的容错能力很差。
容错的复制使强一致性变得棘手
一个简单但不好的复制方案： 两个副本服务器S1 和 S2，客户端写入是并行向两个服务器同时发送，客户端读取是向其中的一个服务器读取 在我们的示例中，C1 和 C2 的写消息可能会以不同的顺序到达两个副本 如果 C3 读取 S1，它可能会看到 x=1 如果 C4 读取 S2，它可能会看到 x=2 或者如果 S1 收到一个写操作，但是客户端在将写入发送到 S2 之前崩溃？ 那不是强一致性！ 更好的一致性通常需要与确保副本保持同步——可能很慢！ 性能和一致性之间可能有很多权衡
背景
许多谷歌服务需要一个大而快速的统一存储系统，如Mapreduce、爬虫、索引器、日志存储/分析 在多个应用程序之间共享，例如抓取、索引、分析 在许多服务器/磁盘上自动“分片”每个文件
对于有许多客户端的并行性能，例如MapReduce 对于一台服务器来说，大文件太大 从故障中自动恢复 每个部署只有一个数据中心 只有谷歌应用程序/用户 针对大文件的顺序访问，read or append 对于小文件，也不是低延迟
这在 2003 年有什么新变化？他们是如何让 SOSP 论文被接受的？ 不是分布式、分片、容错的基本思想。 而是规模巨大；用于工业，真实世界的经验；成功使用弱一致性
整体结构
chunkservers 上存储 64 MB chunks；大文件在很多hunkservers上分成 64 MB chunks 每个chunks在 3 个chunkservers上复制，为什么是 3 而不是 2？
客户端想要读取文件的步骤是什么？
协调器如何知道哪些块服务器具有给定的块？
客户端想要进行“记录追加”时的步骤是什么？
GFS 向客户提供哪些一致性保证？
协调器崩溃+重启会导致它忘记文件吗？或者忘记了哪些块服务器持有相关的块？
两个客户端确实同时记录追加，他们会覆盖彼此的记录吗？
假设一个辅助节点没有听到来自主节点的追加命令，由于临时网络故障，如果读取客户端从该辅助读取怎么办？
