文章页面
分布式系统
3.GFS

3.GFS

bg 这个东西学起来抽象，但是用起来是一点也不抽象
论文写的相当工业化，这里就不看了，如果想看可以B站找个视频看看讲解

这不是学术论文，是我被6.824折磨后想明白的东西。GFS（Google File System） 是2003年Google为MapReduce量身定做的存储系统，核心就一句话：在廉价硬件上可靠地存超大型文件，让批量数据处理飞起来

GFS的场景

在你学习GFS的时候请你忘记你的电脑磁盘，这两个完全不是一个东西

  1. 几十GB的网页快照(一个文件就塞满你硬盘)
  2. 只写一次，读很多次，几乎不更新
  3. 批量分析为主（MapReduce），不是随机访问
  4. 机器天天坏（上千台廉价PC，故障是常态）

这就像你用卡车运矿石，而不是用跑车送快递。

三个特性

1. 每块文件64MB大小

  • 正常文件系统用4KB块，GFS用64MB。为什么？
    • 减少元数据：Master只需记住更少的块位置
    • 流式读取优势：MapReduce按顺序扫大文件，一次读很多才划算
    • 减少网络开销：客户端和ChunkServer长连接传输大量数据

    现实比喻：搬家用卡车一次装完，而不是用自行车跑100趟
    少量多次，也减少网络请求方面的故障和以外

2. 单Master

这种东西一般叫做单点故障,形容的是整个系统只有一个管理节点，这个节点一旦挂掉整个系统崩溃
万事万物都有一个但是，GFS也是这样

  • Master只存元数据（文件名→块映射、块位置），内存够用
  • 写路径上Master参与少：写数据时，Master只告诉客户端往哪写，然后客户端直接和ChunkServer对话
  • 后来他们当然改了（Colossus解决了单点问题），但最初就这么糙

这种架构使得Master节点不再是性能瓶颈，Master的压力也不大

3. 一致性模型

GFS的一致性要求并不是非常非常高的强一致性，它要求的是最终一致性(Eventual Consistency)，中间可能暂时看不到结果，但是最终肯定会被更新
因为GFS每次吞吐过大，并且Google当时机器非常烂也非常多，不可能让每个机器保持强一致性

工作机制

1. 租约(Lease)

Master把某个Chuck的读写权力暂时交给某一个ChuckServer，然后:

  • 客户端找Master要写位置
  • Master说：“找A服务器（主副本），它负责协调这次写”
  • 客户端把数据推给所有副本（流水线传输，节省时间）
  • 主副本确定写入顺序，告诉所有副本：“按这个顺序写”
  • 副本们回复主副本：“写完了”
  • 主副本告诉客户端：“搞定了”

Warning

在此次租约中，如果Primary炸了，心跳无法进行下去，Master会选择一个新的Primary并且进行租约，通知客户端重发

2. 追加（Append） vs 覆盖（Overwrite）

GFS里面使用追加，很少很少使用覆盖
追加就是在全部数据的末端进行填充，然后记录下来信息，下次使用的时候计算偏移量即可
我自己的思路是Master在设计的时候可以定义版本上下限，超过下限就可以回收掉老旧的Chuck
也可能不会进行删除，因为老数据也可能会有作用

4. 容错

当然，机器绝对不是完全可信的，这时候我们就需要设计出来一些冗余，让我们整个系统继续运行，那么我们怎么进行设计呢？

  • chunk副本：默认3副本，跨机架存放(防机架电源故障)
  • Master状态：操作日志+checkpoint，可快速恢复
  • 数据完整性：每个chunk用校验和检测损坏

或者我们设计两套进行交替运行，一套运行的时候另一套停止运行，当A出现了无可挽回的故障就用B顶上 不过这个设计挺烂的，好的架构肯定不是两套

总结

GFS 是一个面向大规模数据的分布式文件系统，通过 Primary + Lease + 多副本 + append-heavy 设计，把复杂的一致性和容错问题封装起来，实现高吞吐、高可用、可扩展，同时对开发者透明

如果想看怎么写一个的话就需要等明年5-6月了，那时候应该没啥事情，可以写写然后发视频

2.RPC和线程