Lecture 03 ： GFS
一、一致性
1， 弱一致性
可能会读到旧数据
2， 强一致性
读到的数据都是最新的
3， 一致性比较
强一致性对于app的写方便， 但是性能差
弱一致性有良好的性能， 并且容易延伸服务器， 但是出问题难定位
二、系统设计
1， 为什么chunks那么大
- 为了均摊费用
- 减小master的保存chunk状态 大小 （chunk handle）
2， master知道文件架构
- 对于目录， 知道什么文件在里面
- 对于文件， 知道每个64MB 的chunk 服务器
- 保存状态在内存里
- master可以恢复
- 操作日志写到磁盘
- 压缩checkpoint
- shadow master 落后master， 可以被选拔为master
3， client读过程
- 发送文件名和chunk index给master
- master恢复包含目标 chunk 的chunkserver set
- 包括chunk版本号
- client缓存上面的信息
- client询问最近的chunk server
- 检查版本
- 如果版本检查错误， 重新联系master
4， client写过程
-
随机client写到已存在的文件
- client询问master 目标chunk的位置 和 primary（leases 租约）
- master回复： chunk servers set、chunk 版本、并且指定谁是primary（有60s的租约）
- client计算副本的网络拓补结构
- client发送数据到第一个备份，然后由备份发送给其他备份
- 使用管道网络（pipeline network？？）
- 备份确认数据回执
- client 通知primary写
- primary写
- 通知其他备份写
- 全部完成通知client
- 如果有另一个client对同一个chunk进行写，那么c1/c2会有数据冲突，但是所有的备份数据仍然相同
-
client 追加：
same deal, but may put parts from C1 and C2 in any order consistent, but not defined or, if just one client writes, no problem -- both consistent and defined
5，record append
Client record append
client asks master for chunk locations
client pushes data to replicas, but specifies no offset
client contacts primary when data is on all chunk servers
primary assigns sequence number
primary checks if append fits into chunk
if not, pad until chunk boundary
primary picks offset for append
primary applies change locally
primary forwards request to replicas
let's saw R3 fails mid-way through applying the write
primary detects error, tells client to try again
client retries after contacting master
master has perhaps brought up R4 in the meantime (or R3 came back)
one replica now has a gap in the byte sequence, so can't just append
pad to next available offset across all replicas
primary and secondaries apply writes
primary responds to client after receiving acks from all replicas三、错误
如果master下线了 shadow master可以提供服务， 但是只能提供读操作（脑裂额综合征，导致不能写）
四、 总结
1， GFS缺陷
- master容错性差
- 小文件
- 客户端能读到旧数据
- 追加可能会有冗余