《Google File System》读书笔记（1）

今天开始看《Google File System》，由于只是为了完善我自己的分布式文件系统以及时间的限制，并不会深度的研究，只是大致的过一遍了解谷歌公司在分布式文件系统上的设计模式，取长补短（大概）

由于我是边读边记录，所以几乎没有整理，都只是零散的知识点和设计要点。

---

GFS的设计是通过观察应用程序的工作负载和当前-预期的技术环境来推动的

GFS中将组件的故障设置为常态，因此设计需求要在常态的组件故障中保障应用程序服务能继续可用。因此，系统中的持续监控，错误检测，容错和自动恢复都是必须的。

GFS在设计中有许多假设：

1.运行时经常出现由于廉价的服务器导致组件错误，因此GFS需要不断监视自己检测错误以及容错和自动恢复 ——————持续监控，错误检测，容错和自动恢复机制

2.存储几百万个100M左右的文件，因此需要适量的存储大文件，并且必须支持小文件，但是不需要对小文件进行优化。 ——————形成文件块，每块文件64M

3.工作负载来自大型流读取以及小型随机读取。大型流读取通常一次读取数百KB或者1M或更高，来自同一客户端的连续操作通常是读取文件的连续区域。小的随机读取通常在某个任意便宜出读取几KB。注重性能的应用程序通常对小文件进行批处理和排序，以便在文件中连续读取而不是多次跳跃 ———————对读写的优化，W+R>E,读一次成功就可以，写必须要写三次，允许同时读，但不能同时写，写操作是原子操作

4.高持续的带宽 ———持久化连接

元数据：包括文件命名空间，访问控制信息，从文件到块的映射以及块当前的位置，他还控制系统范围的活动，例如租约的管理孤立块的垃圾收集以及块服务器之间的块迁移，主设备定义与每个块进行心跳检测，以便为其提供指令和收集状态

文件数据不缓存，客户端只缓存元数据

master永远不会和client产生文件传输的交互，client只会通过master获知那些chunk-server，然后直接与chunk-server进行交互

client与master的交互：

1.client将应用程序中的文件名的字节偏移转换为文件中的块索引

2.client向master发送包含文件名和块索引的请求
⚠️：client通常会在同一个请求中请求多个块

3.master回应相应的块句柄和chunk-server位置
⚠️：master通常会在回复的那些块信息后面再跟上一些块信息

4.client使用文件名和块索引作为密钥缓存此信息
⚠️：该信息有生存时间，在信息过期或者重新打开此文件之前，client对同一文件的读取都不需要再重新经过master

5.client向最近的chunk-server发送请求，请求指定块句柄和该块中的字节范围

块大小为64M：这比之前的分布式文件块大小要大得多，每个块副本都作为普通linux文件存储在服务器上，惰性空间分配避免了由于内部碎片造成的浪费空间。 大块的优点：

1.减少了client与master交互的需要，在同一个块上的读写只需要向master请求一次即可
2.通过保持与块的持久TCP连接来减少网络消耗
3.减少了master中的元数据的大小，使得master可以将元数据存储在内存中
复制代码

大块的缺点：

1.如果是小文件可能只有一个块，如果有多个client同时访问该文件，会导致该文件成为热点，导致存储该块的服务器过载
复制代码

出现的问题：当GFS被批处理队列系统使用时，可执行文件作为单块文件写入GFS，然后同事在数百台计算机上启动，存储此可执行文件的服务器因数百个并发请求而过载

解决办法：通过存储具有更高复制因子的可执行文件并使批处理队列系统错开应用程序启动时间来解决

潜在的长期解决方案：允许客户在这种情况下从其他地方读取数据（不向最近chunk-server请求，向空闲的其他地区的chunk-server发起请求，请求压力方面的负载均衡

master主要存储三种类型的元数据：文件名和块命名空间，从文件到块的映射以及每个块的副本的位置。所有元数据都保存在master的内存中，前两种类型（名称空间和文件到块的映射）也通过将变化记录存储到主服务器本地磁盘上，并且在远程计算机上复制操作日志来保持文件持久性。而master不会持久化每个块的位置信息，他会在master启动时或chunk-server接入时主动向chunk-server询问其块信息

不将块位置信息存储在master的好处：

1.消除了master服务器加入/离开集群，更改名称，失败，重新请求等等问题时解决了master和块服务器的同步问题
2.chunk-server的块可能自己消失（磁盘损坏），操作员重命名这个块服务器名称。这种情况下在master维护该信息是没有意义的
复制代码

master会有周期性扫描chunk-server，用于实现块垃圾收集以及chunk-server故障时重新复制，以及块迁移以平衡块服务器之间的负载和磁盘空间使用（会自动将文件移动到磁盘压力小的chunk-server上

master为每个64MB的块维护少于64字节的元数据，大部分块都已满，因为大多数文件具有多个块，只有最后一个块可以部分填充。文件命名空间数据通常需要每个文件少于64字节，因为它使用前缀压缩紧凑地存储文件名。如果需要支持更大的文件系统，为主机添加额外内存是一个很小的代价，通过将元数据存储在内存中获得简单性，可靠性，高性能和灵活性。

master会有心跳监视chunk-server状态

操作日志是GFS的核心，操作日志是元数据的唯一持久记录，而且还充当并发操作顺序的逻辑

只有当日志记录持久化完成后才开始进行后续的操作，否则会丢失块的操作

master通过重播操作来回复其文件系统状态，为了最小化启动时间，日志大小有规定，当超过一定大小的时候会重新生成新的日志文件。而且恢复的时候是检查最新的检查点，并在此基础上恢复最新的几条操作记录（更前面的操作记录是系统正常时候的操作记录，一定是成功执行的），检查点采用紧凑的B树形式，可以直接映射到内存，用于命名空间的查找而无需额外的解析，进一步加快了系统恢复速度并提高了可用性

这里对日志的构建不清楚
复制代码

构建日志检查点并恢复的操作是在一个新的线程中进行的，这样可以在系统重新构建的同时接收新的操作日志

检查点的代码会跳过不完整的检查点

GFS为了保证统一而进行的操作：

1.文件命名空间突变（例：文件创建）是原子操作。命名空间锁保证原子性和正确性
复制代码

每次修改文件块都会同时修改他的版本号，如果出现文件块副本版本号不对应，则该文件块未垃圾文件块

由于客户端保存了块位置信息，导致client会从旧的块中读取数据。因此这个由缓存的超时时间和文件的重新打开而受限制。（为什么会受限制？是因为读取的时候都要验证过文件名和块索引生成的密钥吗？）