GFS(Google File System)详解 各种阅读问题

Chunk的大小为何选择64MB？这个选择主要基于哪些考虑？

• 同一chunk的多次读写只需要跟master通信一次
• 一个client更可能在给定的chunk上进行多次访问，因此可以与chunkserver保持一个长时间的TCP连接
• 减少了master需要存放的元数据量，因此可以把整个元数据放在内存中

关于这个问题我还有一些其他的想法，比如为什么不是32MB，不是128MB，后来跟师兄讨论了一下，这种64MB的设计可能是根据工程实践，选出来的最佳大小，有可能是先拍脑袋决定了一个32MB的chunk，再在实际使用中调整最后选择的一个最佳值。

GFS主要支持append，overwrite操作比较少。为什么这样设计？

• 改写操作相对较少
• 改写数据量较大时，尤其是跨越chunk边界的写操作，难以保证一致性

如何基于一个只支持Append操作的文件系统构建分布式表格系统Bigtable？

利用memtable, SSTable，将增删改操作全部转化为结点的增加操作，并且将内存中不可变的memtable转化为对应SSTable追加到文件末尾

为什么要将数据流和控制流分开？

能够提高数据流的传输效率，因为当前client并不一定离主副本最近，选择一个由近及远的传输顺序可以使得整个数据的传输时间最短

如果不分开，如何实现Append流程？

可以先传输数据到主副本，又主副本执行追加操作，执行成功后将当前结果发送给其他从副本

GFS有时会出现重复记录或者padding，为什么？

这种情况主要发生在record append失败时，假如ABC三个副本中，AB执行追加成功，而C失败，此时三副本数据不一致被判定为写入失败，需要重试append操作。再次append时就不再在原偏移处append了，而是在原先失败的append的后面追加，所以会出现重复记录。

Lease是什么？在GFS起什么作用？它与heartbeat有何区别？

1. 租约是由master分配的一种用于标记主副本的机制。
2. 这种机制可以减小master管理各个副本之间的一致性等问题的负担。
3. 心跳信息是周期性的，持续产生的，用于帮助master获取当前各个chunkserver管理的所有chunk的状态。而租约只发生在有修改操作时，并且租约是有时长限制的，如果一分钟内没有完成写操作的话需要通过心跳信息向master持续申请延长租约的有效时间

GFS append过程中如果Secondary出现故障，如何处理？如果Primary出现故障，如何处理？

1. 从副本出现故障的话，可以在主副本成功的操作后面继续重试追加操作
2. 主副本出现故障的话，主副本不会产生对应的写操作序列号，其他副本也都不会执行对应的写操作

GFS Master需要存