首先GFS是一个分布式存储系统。要设计一个分布式存储系统，面临着很多问题，比较有名的CAP，即一致性，可用性，分区容灾性，CAP得出的结论，只能满足其中两个，作为分布式系统，必不可少的就是分区容灾性，如果某个地区服务crash了，仍能够利用其他地区的服务器保证服务。因此就要在一致性和可用性之间做一个平衡。
GFS的设计目标（数据存储，极少修改）：
1 大型，大容量，单机纵向扩展很难满足剧增的数据量，横向扩展。
2 性能，自动分片，对外就如一个单机存储系统
3 全局，就有泛用性，适用各种应用。
4 容错，部分服务器crash，能够自动修复。
GFS的集群框架
1 一个master和多个chunkserver
2 数据以chunk为单位存储，为了防止某一个服务器crash，同一个chunk共三个副本，分别存储在三个不同的chunkserver上。
3 master主要是存储metadata，其中包括多个映射，文件到chunk的映射（一个大文件分多个chunk存储），chunk到chunkserver list的映射。同时，master还作为管理者起调度作用，chunk的迁移复制（新加入chunkserver后复制chunk），负载均衡（减小对同一个chunkserver的QPS），垃圾回收，并保持和chunkserver的心跳，通信等。如果要读取数据，可以理解为是master做了一个重定向。
4 chunkserver主要是存储功能，client获取数据从chunkserver中获取
读功能（对于master的负载不大，只是做映射，+负载处理等问题）
1 client向master发送读请求，master返回chunk 的id和所在的chunkserver
2 client缓存刚才的元数据（减少对master的访问），向chunkserver发送请求
存在文件跨越多个chunk的情况，多次读取
写功能（对于单master的GFS系统，所有写）
租约（减少写对master的压力）
1 当client要写数据时，访问master获取要写的chunkserver，其中包括secondary和primary，primary为租约，租约负责写的一致性管理
2 client缓存租约以及chunkserver信息之后，会把数据写到每个chunkserver缓存（LRU），没有落盘
3 然后primary确定写入顺序，告诉其他chunkserver，等到所有都写入之后，应答租约，租约回复client成功与否（此处不是强一致性，没有raft和paxos的保证所有写入副本一致）
GFS是弱一致性
对于顺序写，是确定的define
对于并发写，是一致的（因为每个副本的顺序是primary保证的，但不是确定的，因为不确定哪个client数据先写入）
对于顺序和并发 append写入，是确定的，但是确定的数据之间会有失败记录（如果有个副本追加写失败，他不会覆盖原来失败写，会在后面继续写入，记录新的offset）
其他技术
1快照，用来做备份和恢复（checkpoint）
2 单master但是有shadow master用户保证容错
3 checksum用于块的完整性
FAQ
1 chunk 64M这么大的好处
减少client保存块的元数据信息
减少client与master通信次数（读取64M只需通信1-2次，太小就要通信很多次）
一个chunk大使得client一个长时间tcp通信获得数据，减少了client与chunkserver频繁建立tcp连接次数
坏处导致热点问题严重
2快照实现
利用一个引用计数，产生快照并不是立即复制一个副本，而是用一个引用计数，当要对chunk进行修改的时候，利用写时复制修改原来chunk。
存在问题，GFS只有一个master，存储元数据，内存容易耗尽，对于高并发的client访问，master故障不能自动切换。
这些问题的解决就是共识算法的任务。
标签：chunkserver,--,GFS,chunk,client,master,租约,分布式 From： https://www.cnblogs.com/super-xtc/p/17149541.html