GFS

构建分布式系统大多都是关于如何设计存储系统，或是设计其它基于大型分布式存储的系统。所以我们会更加关注如何为大型分布式存储系统设计一个优秀的接口，以及如何设计存储系统的内部结构，这样系统才能良好运行。

GFS的设计目标

1、分布式出发点：性能问题

2、我们需要一个自动的容错系统，这就引出了容错这个话题（fault tolerance）

3、当其中一个故障了，你就可以使用另一个。所以，如果想要容错能力，就得有复制（replication）

4、如果我们有了复制，我们就有不一致的问题（inconsistency）

5、如果你想要一致性，你的代价就是低性能

还有一些特征并非是设计目标。比如GFS被设计成只在一个数据中心运行；其次，GFS并不面向普通的用户；第三，GFS在各个方面对大型的顺序文件读写做了定制

GFS-Master节点

GFS的大致架构

Master节点用来管理文件和Chunk的信息，而Chunk服务器用来存储实际的数据

GFS的一致性以及GFS是如何处理故障？

第一个是文件名到Chunk ID或者Chunk Handle数组的对应。这个表单告诉你，文件对应了哪些Chunk。但是只有Chunk ID是做不了太多事情的，所以有了第二个表单。

第二个表单记录了Chunk ID到Chunk数据的对应关系。这里的数据又包括了：

每个Chunk存储在哪些服务器上，所以这部分是Chunk服务器的列表
每个Chunk当前的版本号，所以Master节点必须记住每个Chunk对应的版本号。
所有对于Chunk的写操作都必须在主Chunk（Primary Chunk）上顺序处理，主Chunk是Chunk的多个副本之一。所以，Master节点必须记住哪个Chunk服务器持有主Chunk。
并且，主Chunk只能在特定的租约时间内担任主Chunk，所以，Master节点要记住主Chunk的租约过期时间。

以上数据都存储在内存中，如果Master故障了，这些数据就都丢失了。为了能让Master重启而不丢失数据，Master节点会同时将数据存储在磁盘上。所以Master节点读数据只会从内存读，但是写数据的时候，至少有一部分数据会接入到磁盘中。更具体来说，Master会在磁盘上存储log，每次有数据变更时，Master会在磁盘的log中追加一条记录，并生成CheckPoint（类似于备份点）。

当然，有些数据需要存在磁盘上，而有些不用。

GFS-Read File

客户端会选择一个网络上最近的服务器（Google的数据中心中，IP地址是连续的，所以可以从IP地址的差异判断网络位置的远近），并将读请求发送到那个服务器

GFS-Write File

knightforyou commented 1 year ago

Distributed Transaction

12.1 分布式事务初探（Distributed Transaction）

第一个是并发控制（Concurrency Control）第二个是原子提交（Atomic Commit）。

事务就是并发控制+原子提交；

我们需要一个概念来定义什么是正确的结果。一旦我们知道了这个概念，我们需要构建能执行这些事务的机制，在可能存在并发和失败的前提下，仍然得到正确的结果。所以，首先，什么是正确性？数据库通常对于正确性有一个概念称为ACID：Atomic，原子性；Consistent，一致性；Isolated，隔离性；Durable，持久化的

knightforyou / testcyber

0625-0630distributed system #6

GFS