学习GFS架构总结

基本问题

为什么需要分布式？

因为需要支持百万级的文件，单机无法满足，所以需要用许多廉价机器来协作完成。

如何设计架构

按最简单的来理解。我们存一个文件，就需要知道文件在磁盘中的位置。现在我们存大文件，我们则需要知道这个文件存在哪台机器上。顺着这个思路我们就构建了简单的索引->机器的架构。如下图所示：

我们把元数据放到master机器上，然后把真正的物理文件，存放到chunk机器上。这种架构就简单的实现了索引到文件的架构。

chunk server如何存文件

正常情况下，我们的文件大小，是按需求进行创建的，需要多大空间就存多大文件。而这里需要支持的是大文件，可能是比一个磁盘还大的文件。所以不可避免需要做文件切分。而切分之后，则是通过多个文件来构成大文件。使用定长的文件块为64M，有如下好处：

1. 非常好构建索引
2. 查询效率高，能直接找到偏移地址进行读取
3. 之所以使用比较大的64M作为chunk size，可以减少许多文件与master的交互。

chunk server如何保证文件的High Availability

分布式系统让文件提升可靠，永远只有一个办法：副本。在chunk server对每个chunk进行副本的复制。正常情况下， 可以是保存三个副本

master为什么使用单点设计

总体来说，master成为单点，除了可用性之后，拥有非常多好处。

1. 首先，让设计变得非常简单，master拥有了全局视角。能在全局上把握chunk server的各种控制。
2. 一些并发的操作，如果只有一个master，能将分布式锁降级成本地锁，使得设计变得简单。
3. master知道所有chunk server的负载，能够非常方便的做全局的负载均衡

如何克服master单点带来的问题

master如何解决高可用

1. master在变更之前，它会写一份日志到本地。并且把变更同步到master的副本节点中，该节点称为影子节点。正常情况下，如果master进程挂了，能够在秒级被拉起来恢复服务。如果master出现硬件故障，那就得依赖下面一条了。
2. master服务会部署多个影子master作为主master的备份，平时不工作。如果主master挂掉的时候，master无法重启时，外部的监控会让影子master接入进行工作。

master避免成为性能瓶颈

1. 读写操作时，都不需要通过master节点。只需要开始的时候，让master找到对应的chunk server，后续直接与chunk server进行读写操作。

正常的写操作如何进行

1. 首先，一定是写多副本保证高可用。
2. 如何保证多副本数据的一致性，简单的方案，多副本的串行顺序写，全部写OK了，那数据一定是一致的。
3. 由client向master请求可写入的副本。master会返回一个primary replica和两个secondary replica，正常情况下，client就不需要再与master进行交互了。写入过程如下图所示。

写入过程如何优化

正常情况下，可以是客户端依次顺序的写入三个节点。但这样效率会比较底，比如说有一个节点是不同国家。GFS论文中采用的做法是，由client选择一个最近的节点进行写入，例如A节点。数据一旦写入A节点，则A节点收到数据的同时，马上会在内部找到一个最近的节点C，C节点会找最近的B节点。顺序进行写入内存缓存中。当A和B都在内存中写完数据之后，会通知primary节点，primary通知client，再由client对primary发起写入的通知。最后由primary对B和C进行写入指令操作。写入正常完成后，由primary返回client成功。

为什么先写其中一个节点，再由其他节点内部复制

因为内部机器之间，往往网络带宽会非常好。特别是跨地区通信的时候，远比client直接写多个节点来得快。充分利用了机房之间的带宽。

为什么先写到缓存再落盘

如果直接一个命令就落盘，然后primary再直接复制到两个secondary节点，那可能后面出错的概率非常大，而且client只能阻塞等待。这样的设计相当于给用户提供了一个类似“事务”的过程。可以理解为是一个分布式事务的过程，需要三个节点的资源准备好，再做提交。本质上的做法这里类似于两阶段提交。如果第一个阶段，快速通过网络缓存到节点的内存中，那么，后续再进行落盘操作的成功率应该是99%以上了。

异常如何处理

这里如果出错，那是让他错吧。因为本身分布式系统的错误就是比较复杂，尝试在一个复杂的错误中去修复，往往会把问题搞得更糟。这里直接返回错误，让客户端来决定是否进行重试。

正常的读过程

1. 访问master，拿到对应的文件名的chunk server的副本机器集。
2. 根据自己判断，哪台机器离自己较“近”。选择离对自己延时较低的机器来进行chunk server的数据访问。

master如何运筹帷幄

如何做整体负载均衡

1. 通过与chunk server保持心跳，持续收集各台机器的硬盘使用率，网络IO情况。对新的读写请求分配低的硬盘使用率的chunk server。
2. 注意避免新上线的机器成热点，因为新写入的文件往往热度比较高，避免使用单一的磁盘使用率作为指标返回。

如何解决热点问题

本质的办法还是多副本。将热点副本多复制到其他低负载的chunk server上解决热点问题

引用

GFS paper