GFS经典设计，给了我们哪些架构启示？（第84讲）

《架构师之路：架构设计中的100个知识点》

84.GFS架构启示

工程架构，Google乃先驱。其GFS（Google File System）有哪些优秀的架构设计点，值得我们学习借鉴呢？

GFS是什么？

Google早期研发的分布式文件系统。

GFS的设计目标是什么？

主要有四个目标：

1. 高可用（availability）；

2. 高可靠（reliability）；

3. 高性能（performance）；

4. 可扩展（scalability）；

GFS对外提供什么接口？

文件创建，删除，打开，关闭，读，写，快照。

画外音：

除了快照，接口和单机文件系统差不多。

快照其实是快速文件目录树的拷贝，并不是所有文件的快照。

GFS能够成为分布式架构的经典案例，原因之一，就是接口简单，但反映的架构理念不简单。

GFS的系统架构如何？

系统里只有文件客户端，主服务器，存储服务器三个角色。

图片

如上图：

1. 客户端（GFS client），是以库的形式提供的，提供的就是对外要用的接口；

2. 主服务器（GFS master），是单点，存储文件信息，目录信息，文件服务器信息，那个文件存在哪些文件服务器上等元数据；

3. 存储服务器（GFS chunk-server），是集群，存储文件；

画外音：角色简单，但反映的架构理念不简单。

为什么要设计单点master？

单点master意味着有一个节点可以避免分布式锁，可以拥有全局视野，能够统一调度与监控，系统整体复杂度降低很多。

画外音：锁可以降级成本地锁，分布式调度可以降级为单点调度。

更具体的：

1. master拥有所有文件目录结构，要操作某个文件，必须获得相应的锁；

画外音：一般情况下，不会对同一个网页进行并发写操作，应用场景决定锁冲突其实不大；

2. master拥有全局视野，能够避免死锁；

3. master知道chunk-server的信息，能够很容易的做chunk-server监控，负载均衡；

4. master知道所有文件的副本分布信息，能够很容易的做文件大小的负载均衡；

画外音：负载均衡分为请求量的均衡，文件存储的容量均衡。

GFS的高可用是怎么保证的？

高可用又分为服务高可用，文件存储高可用，均通过“冗余+自动故障转移”的思路来实现。

1. master高可用：冗余了一台影子master，平时不工作，master挂了工作，以保证master的高可用；

画外音：master资源利用率只有50%。

2. chunk-server高可用：本身是集群，冗余服务；

画外音：当有chunk-server挂掉，master能检测到，并且知道哪些文件存储在chunk-server上，就可以启动新的实例，并复制相关文件。

3. 文件存储高可用：每一份文件会存三份，冗余文件；

GFS的高性能是怎么保证的？

多个chunk-server可以通过线性扩展提升处理能力和存储空间，GFS的潜在瓶颈是单点master，所以GFS要想达到超高性能，主要架构优化思路在于，“提升master性能，减少与master交互”。

1. 只存储元数据，不存储文件数据，不让磁盘容量成为master瓶颈；

2. 元数据会存储在磁盘和内存里，不让磁盘IO成为master瓶颈；

3. 元数据大小内存完全能装得下，不让内存容量成为master瓶颈；

4. 所有数据流，数据缓存，都不走master，不让带宽成为master瓶颈；

5. 元数据可以缓存在客户端，每次从客户端本地缓存访问元数据，只有元数据不准确的时候，才会访问master，不让CPU成为成为master瓶颈；

当然，chunk-server虽然有多个，也会通过一些手段提升chunk-server的性能，例如：

1. 文件块使用64M，避免太多碎片降低性能；

2. 使用追加写，而不是随机写，提升性能；

3. 使用TCP长连接，提升性能；

GFS如何保证系统可靠性？

保证元数据与文件数据的可靠性，GFS使用了很多非常经典的手段。

1. 元数据的变更，会先写日志，以确保不会丢失；

画外音：日志也会冗余，具备高可用。

2. master会轮询探测chunk-server的存活性，保证有chunk-server失效时，chunk-server的状态是准确的；

画外音：文件会存多份，短时间内chunk-server挂掉是不影响的。

3. 元数据的修改是原子的，由master控制，master必须保证元数据修改的顺序性；

4. 文件的正确性，通过checksum保证；

5. 监控，快速发现问题；

读操作的核心流程？

文件读取是最高频的操作。

1. client读本地缓存，看文件在哪些chunk-server上；

2. 如果client本地缓存miss，询问master文件所在位置，并更新本地缓存；

3. 从一个chunk-server里读文件，如果读取到，就返回；

写操作的核心流程？

写操作会复杂很多。

为了保证数据高可用，数据必须在多个chunk-server上写入多个副本，首先要解决的问题是，如何保证多个chunk-server上的数据是一致的呢？

想想一个MySQL集群的多个MySQL实例，是如何保证多个实例的数据一致性的。bingo！确定一个主实例，串行化所有写操作，然后在其他实例重放相同的操作序列，以保证多个实例数据的一致性。

GFS也采用了类似的策略，一个文件冗余3份，存在3个chunk-server上，如下图步骤1-7：

图片

1. client访问master，要发起文件写操作；

画外音：假设client本地缓存未生效；

2. master返回数据存储在ABC三个实例上，并且告之其中一个实例是主chunk-server；

3. client将数据流传递给所有chunk-server；

4. client将控制流产地给主chunk-server；

5. 主chunk-server进行本地操作串行化，并将序列化后的命令发送给其他chunk-server；

6. 其他chunk-server按照相同的控制流对数据进行操作，并将结果告诉主chunk-server；

7. 主chunk-server收到其他所有chunk-server的成果执行结果后，将结果返回client；

画外音：MySQL的主库是写瓶颈，GFS不会出现这样的问题，每个文件的主chunk-server是不同的，所以每个实例的写请求也是均衡的。

这里需要说明的是，GFS对于写操作，执行的是最保守的策略，必须所有chunk写成功，才会返回client写成功（写吞吐会降低）；这样的好处是，读操作只要一个chunk读取成功，就能返回读成功（读吞吐会提升）。

画外音：这也符合R+W>N的定理，N=3份副本，W=3写3个副本才算成功，R=1读1个副本就算成功。R+W>N定理未来再详述。

之所以这么设计，和文件操作“读多写少”的特性有关的，Google抓取的网页，更新较少，读取较多，这也是一个设计折衷的典型。

画外音：任何脱离业务的架构设计都是耍流氓。

除此之外，这里还有一个“数据流与控制流分离”的设计准则：

1. 控制流数据量小，client直接与主chunk-server交互；

2. 数据流数据量大，client选择“最近的路径”发送数据；

画外音：所谓“最近”，可以通过IP的相似度计算得到。

总结

GFS的架构，体现了很多经典的设计实践：

1. 简化系统角色，单点master降低系统复杂度；

2. 不管是文件还是服务，均通过“冗余+故障自动转移”保证高可用；

3. 由于存在单点master，GFS将“降低与单点master的交互”作为性能优化核心；

4. 通过写日志，原子修改，checksum，快速监控快速恢复等方式保证可靠性与完整性；

5. 通过串行化保证多个副本数据的一致性；

6. 控制流与数据流分离，提高性能；

知其然，知其所以然。

思路比结论更重要。

==全文完==