在前面的 MapReduce 中我们聊到这个至简的模型为我们构建分布式系统开启了新的大门，今天我们来聊聊 MapReduce 中负责输入输出的文件系统案例。
首先我们来了解一下 GFS 的设计目标：在成千上百台 Linux 普通机器存储巨量数据，保证高并发。
前几篇一直提一致性，啥是一致性？举个例子，我在支付宝上存了 100后，在全国无论什么地方连上哪台支付宝的服务器，我的账户上都得增加 100。如果支付宝全国只有一万个人在用，一台机器一个数据库就足够了，但用户的数量是数以亿计，所以肯定是好多机器在服务，所以如果保证不了一致性，是一秒钟都干不下去的。
但话又说回来，不是每家企业都是像支付宝一样一分钱都不能错，比如微博，你关注的明星发了一个动态，1分钟后你才刷新到，其实也是可以接受，所以根据不同业务对一致性的要求不同，可分为强一致性和弱一致性。
我们以文件系统举例，弱一致性的文件读取操作 read() 可能会读不到最新写入的数据；而强一致性保证 read() 始终读到最新写入的数据。不同的场景有不同的一致性策略，那么理想状态下的一致性模型是怎样的？
- 文件副本可以像没有副本的文件系统一样使用：像多个客户端访问一台机器上某个磁盘上的文件。
- 如果一个应用正在写入，之后的读取操作应该读到写入的内容。
- 两个应用并发写入同一个文件。如果该文件不存在，最后文件中可能会有混合的内容。
- 如果两个应用并发写入同一个目录，第一个先写，另一个后写。
理想的拦路虎是什么：机器故障，网络隔离，要一致性又要高并发。然后会发现自相矛盾的理想是不可能实现的。所以 GFS 在现实和理想中间找到一个平衡点。看看现实是什么：
- 大部分文件都很大，GB 级别
- 文件不用删除
- 文件的修改只有追加操作
- 偶尔读不到最新数据也可以接受，毕竟浏览网页不是查看账户余额
- 最重要的是，数据量巨大，并发量大，性能要求很高
在 GFS 架构中有 Client，Master Server 和 Chunk Server 三种角色，文件被分为固定大小的数据块，在 Chunk 上使用多(默认 3)台机器进行主从备份提高可用性，而 Master 主要管理元数据和 Chunk。对于 Master 操作如修改目录是强一致性的，而对于 Chunk 是弱一致性。
有道是解决主要矛盾，忽略次要矛盾。既然要提高并发量和可用性，我们认为每个文件追加操作在所有副本执行成功就算本次客户端操作成功，而对于一条数据重复添加，两条追加记录中插入其他数据都视为正常，这大大提高了并发，但要求业务代码区别每个记录的唯一性。这里并发性和可用性是主要矛盾，而一致性则是次要矛盾。
GFS 对 Master Server 和 Chunk Server 合理分配了各自的负载重点，让 Master 保持轻量和简单的一致性模型；而 Chunk Server 负责实际的文件数据与 Linux 的交互以及主副本与其他备份的复制优化。
容错方面，Master 采用传统的 Write Ahead Log 和 CheckPoint 机制外几台热备份 Master。而 Chunk Server 采用主从备份，一致性要求不高。
学习一个系统，场景很重要哦。GFS 为大规模读写，追加，吞吐量巨大，一致性要求不高的需求设计。所以不适合大量小文件，多客户端对同一文件随机修改，master 逻辑复杂且容易出错的场景。
