《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会从旧的块中读取数据。所以这个由缓存的超时时间和文件的从新打开而受限制。（为何会受限制？是由于读取的时候都要验证过文件名和块索引生成的密钥吗？）