1. 工具解决语言差距

首先上工具“有道速读”，这个工具号称大模型读论文工具，最有用的地方还是有道最擅长的翻译，其它涉及大模型的地方还在尝试，不敢妄评。（当前国外比较火的大模型读论文工具是DocsGPT，github地址是DocsGPT github，需要翻墙，还没有体验过。）

简单介绍一下，登录后，点击上传文件，左边是原文，右边是中文翻译，实现了：
1）点击左边段落，右边跳转到相应翻译
2）点击右边段落，左边跳转到相应原文
这个功能还是相当强大的，作为一个强大的论文翻译器，还是能很好解决中国人的语言差距。如下示意图：

GFS

借助工具阅读

下面几个步骤：
1）使用“有道速读”的"文章解读"，大概了解一下论文讲什么

解读

2）使用“有道速读”的“文章摘要”，做个脑图，对论文有进一步的认识。观察了一下摘要，基本都是摘取段落的前一两句进行摘要，对做脑图，绰绰有余了。

摘要

2. GFS

借助工具，我们就可以跨过对英文不熟悉，开始愉快的阅读了。速读摘要，汇总GFS主要要点。论文按照假设、接口定义、架构、系统交互、容错余诊断几个方面讲解整篇论文。

全文结构

• 假设，说明当时的背景下，要解决什么样的问题。读是大规模流式读，写是大规模顺序写，写后不再修改。
• 接口定义，和文件系统对比，目录树形分层，类似文件系统，额外增加文件追加和快照接口。
• 架构，一个master和多个chunk服务器，根据假设，抽象了元数据，定义了chunk尺寸为64M。
• 系统交互，使用租约和追加保持写入顺序，并且使用控制流和数据流分离的方式。
• master节点，说明名字空间锁，对于元数据初始化以及内存保存；对于副本的位置选择及创删操作，特殊的垃圾回收策略。
• 容错与诊断，说明了高可用的如何达成，chunksum和rpc日志保持数据一致性。

2.1 GFS的架构

GFS架构

GFS的架构如图，是master和chunserver的分布式服务组成，chunserver是规模成百上千计算的。这个架构有几个重要的概念要理解：

• 元数据，包括文件和 Chunk 的命名空间、文件和 Chunk 的对应关系、每个 Chunk 副本的存放地点。命名空间按照层级结构组成，类似于文件的目录；每个叶子节点是个目录或者文件，每个文件对应着N个Chunk，每个Chunk对应若干个副本。
• 副本，一般是3副本机制，这是典型的冗余机制，每个数据有主Chunk和2个副本Chunk，当主Chunk损坏，会使用副本数据保证数据完整。
• Chunk大小，Chunk大小设置为64M。按照假设，文件一般都比较大，并且都是大规模读写，所以Chunk为64M，可以有效减少元数据的数量。

按照这些基本概念，我们可以根据论文学习并自己推测系统架构的运转。

• 启动的时候master怎样初始化，初始化的元数据来自哪里？GFS master的元数据是从GFS chunkserver轮询获得的，而不是持久化在本地的。为了应对大规模的访问，GFS设计者将数据保存在内存中，而不是数据库。根据这里结合原文推测，GFS chunkserver也有一套管理机制，通过心跳定时与GFS master联系，推送自身的Chunk状态。
• GFS client怎样读文件？首先访问GFS master，通过GFS master的目录获取到元数据，并且将元数据保存在本地。然后不是通过GFS master去访问GFS chunkserver，否则会把mster变成瓶颈，它通过元数据（包括Chunk的位置信息）直接访问GFS chunkserver，然后根据读写内容的偏移，持续与GFS chunkserver交互。
• GFS client如何写文件？当写文件的时候，首先也还是访问GFS master，GFS master传递回控制流元数据；然后通过控制流和数据流分离方式（见），将数据送到主Chunk和2个Chunk副本。当3个Chunk所在的GFS chunkserver均回复GFS client写入成功，这才算写入成功。否则就不成功。
• GFS client 如何删除数据？GFS client删除数据，是调用GFS master的delete文件接口删除，此时删除只是从文件目录上删除，将文件变的不可见，但是并非真正删除了文件。真正删除是类似于垃圾回收机制，垃圾回收机制在后台进行，将文件真正删除。

2.2 控制流和数据流分离

控制流与数据流分离

2.2.1 租约

这里有个基本概念叫做租约（用2.2.2第二步，选取主Chunk，以及数据写入过程）。在client/master分布式一致性缓存系统中，当client向master请求元数据时，master返回数据并给返回的数据设置一个租约(lease)。这个租约有一定的有效期。在有效期内，master承诺不会修改跟这个租约关联的数据。不论master发出去的元数据client是否有收到，client是否宕机，master将不会对有租约的数据进行修改，这样变保证了client跟master的数据保持一致。

如果master在有效期内master收到请求修改带有租约的数据， master修改数据时，先阻塞所有对该数据的读请求，并等待该数据上的租约失效后再进行修改，然后再返回结果。
对于client，在读取元数据时， 先检查 本地的是否存在有效期内的cache，如果没有的话向master请求带有租约的元数据，并将其缓存起来。当租约到期后则将本地的cache删除

2.2.2 控制流和数据流分离

当GFS client向GFS master请求写文件的步骤如下：

• 第一步，客户端会去问 master 要写入的数据，应该在哪些 chunkserver 上。
• 第二步，和读数据一样，master 会告诉客户端所有的次副本（secondary replica）所在的 chunkserver。这还不够，master 还会告诉客户端哪个 replica 是“老大”，也就是主副本（primary replica），数据此时以它为准。
• 第三步，拿到数据应该写到哪些 chunkserver 里之后，客户端会把要写的数据发给所有的 replica。不过此时，chunkserver 拿到发过来的数据后还不会真的写下来，只会把数据放在一个 LRU 的缓冲区里。
• 第四步，等到所有次副本都接收完数据后，客户端就会发送一个写请求给到主副本。我在上节课一开始就说过，GFS 面对的是几百个并发的客户端，所以主副本可能会收到很多个客户端的写入请求。主副本自己会给这些请求排一个顺序，确保所有的数据写入是有一个固定顺序的。接下来，主副本就开始按照这个顺序，把刚才 LRU 的缓冲区里的数据写到实际的 chunk 里去。
• 第五步，主副本会把对应的写请求转发给所有的次副本，所有次副本会和主副本以同样的数据写入顺序，把数据写入到硬盘上。
• 第六步，次副本的数据写入完成之后，会回复主副本，我也把数据和你一样写完了。
• 第七步，主副本再去告诉客户端，这个数据写入成功了。而如果在任何一个副本写入数据的过程中出错了，这个出错都会告诉客户端，也就意味着这次写入其实失败了

3 小结

学习AI或者大数据领域，从论文入手是个提高品味的方法。对于大数据，反复通读google三架马车的论文，是个好办法，否则就是零零碎碎的知识。