三驾马车
- gfs 解决存储问题
- MapReduce 解决计算问题
- bigtable 实时服务,利用mmtable+sstable底层格式,解决大集群,机械硬盘高性能随机读写问题
![[files/Pasted image 20211028081150.png]]
两个基础
- 数据一致性分布式锁
- 序列化和分布式系统间通信
![[files/Pasted image 20211028081520.png]]
gfs-master的3个身份
两种服务器, master 主控节点, chunkserver 实际数据节点
对于chunkserver,目录服务
- 文件和 chunk 的命名空间信息，也就是类似前面 /data/geektime/bigdata/gfs01 这样的路径和文件名；
- 这些文件被拆分成了哪几个 chunk，也就是这个全路径文件名到多个 chunk handle 的映射关系；
- 这些 chunk 实际被存储在了哪些 chunkserver 上，也就是 chunk handle 到 chunkserver 的映射关系。
![[Pasted image 20211028212055.png]]
读取文件的流程?
- 客户端先去问 master，我们想要读取的数据在哪里。这里，客户端会发出两部分信息，一个是文件名，另一个则是要读取哪一段数据，也就是读取文件的 offset 及 length。因为所有文件都被切成 64MB 大小的一个 chunk 了，所以根据 offset 和 length，我们可以很容易地算出客户端要读取的数据在哪几个 chunk 里面。于是，客户端就会告诉 master，我要哪个文件的第几个 chunk。
- master 拿到了这个请求之后，就会把这个 chunk 对应的所有副本所在的 chunkserver，告诉客户端。
- 等客户端拿到 chunk 所在的 chunkserver 信息后，客户端就可以直接去找其中任意的一个 chunkserver 读取自己所要的数据。
![[Pasted image 20211028212236.png]]
对于backupmaster,同步复制主从架构的主节点
数据放在内存里带来的问题，就是一旦 master 挂掉，数据就会都丢了。所以，master 会通过记录操作日志和定期生成对应的 Checkpoints 进行持久化，也就是写到硬盘上。
当 master 节点重启的时候，就会先读取最新的 Checkpoints，然后重放（replay）Checkpoints 之后的操作日志，把 master 节点的状态恢复到之前最新的状态。这是最常见的存储系统会用到的可恢复机制。
可要是 master 节点的硬件彻底故障了呢？
去数据中心重新更换硬件可不是几分钟的事情，所以 GFS 还为 master 准备好了几个“备胎”，也就是另外几台 Backup Master。所有针对 master 的数据操作，都需要同样写到另外准备的这几台服务器上。只有当数据在 master 上操作成功，对应的操作记录刷新到硬盘上，并且这几个 Backup Master 的数据也写入成功，并把操作记录刷新到硬盘上，整个操作才会被视为操作成功。这种方式，叫做数据的“同步复制”
对于shadowmaster,异步复制到主从架构主节点
只读的“影子 Master”，这些影子 Master 和前面的备胎不同，master 写入数据并不需要等到影子 Master 也写入完成才返回成功。而是影子 Master 不断同步 master 输入的写入，尽可能保持追上 master 的最新状态。这种方式，叫做数据的“异步复制”，是分布式系统里另一种典型模式。异步复制下，影子 Master 并不是和 master 的数据完全同步的，而是可能会有一些小小的延时。
![[Pasted image 20211028212528.png]]