如何适应松弛的一致性模型
这种松弛的一致性模型，实际上是一种不能保证一致性的模型，或者更准确的说是一致性的数 据中间夹杂不一致数据。
这些夹杂其中的不一致数据，对应用来说是不可接受的。在这种一致性下，应该如何使用GFS 那?GFS的论文中，给出了这样几条使用GFS的建议:依赖追加(append)而不是依赖覆盖 (overwrite)，设立检查点(checkpointing),写入自校验(write self-validating),自记录标识 (self-identifying records)。
使用方式1:只有单个写入的情况下，按从头到尾的方式生成文件。
- 方法1.1:先临时写入一个文件，再全部数据写入成功后，将文件改名成一个永久的名 字，文件的读取方只能通过永久的文件名访问到这个文件。
- 方法1.2:写入方按一定的周期，写入数据，写入成功后，记录一个写入进度检查点 (checkpoint )，这个检查点包括应用级的校验数(checksum)。读取方只去校验、处理检查点之前的数据。即便写入方出现宕机的情况，重启后的写入方或者新的写入方，会 从检查点开始，继续重新写入数据，这样就修复了不一致的数据。
使用方式2:多个写入并发向一个文件尾部追加，这个使用方式就像是一个生产消费型的消息 队列，多个生产者向一个文件尾部追加消息，消费者从文件读取消息
方法2.1:使用record append接口，保证数据至少被成功的写入一次。但是应用需要应对 不一致数据，和重复数据。
- 为了校验不一致数据，给每个记录添加校验数(checksum)，读取方通过校验数识别 出不一致的数据，并且丢弃不一致的数据。
- 如果应用读取数据没有幂等处理，那么应用就需要过滤掉重复数据。写入方写入记录时 额外写入一个唯一的标识(ident ifier)，读取方读取数据后通过标识辨别之前是否已经 处理过这个标识的数据。
GFS的设计哲学
可以看出基于GFS的应用需要通过一些特殊的手段来应对GFS松弛的一致性模型带来的各种问 题。GFS的一致性保证对于使用者是非常不友好的，很多人第一次看到这样的一致性保证都是 比较吃惊的。
那么GFS为什么要设计这样的一致性模型那?GFS在架构上选择这样的设计有它自己的设计哲 学。GFS追求的是简单、够用的原则。GFS主要要解决的问题是如何使用廉价的服务器存储海 量的数据，并且达到非常高的吞吐量(GFS非常好的做到了这2点，但不是本文的主题，这里 就不展开了)，并且文件系统本身的实现要简单，能够快速的实现出来(GFS的开发者在开发 完GFS之后，很快就去开发BigT able了)。GFS很好的完成了完成了这样的目标。但是留下了 一致性问题，给使用者带来的负担。但是在GFS应用的前期，一致性不是问题，GFS的主要使 用者(BigT able)就是GFS开发者，他们深知应该如何使用GFS，这种不一致在BigT able中被 很好屏蔽掉(采用上面所说的方法)，BigT able提供了很好的一致性保证。
但是随着GFS使用的不断深入，GFS简单够用的架构开始带来很多问题，一致性问题仅仅是其 中的一个。主导了GFS很⻓时间的Leader Sean Quinlan在一次采访中，详细说明了在GFS度 过了应用的初期之后，这种简单的架构带来的各种问题[1]。
开源分布式文件系统HDFS，清晰的看到了GFS的一致性模型给使用者带来的不方便，坚定地 摒弃了GFS的一致性模型，提供了很好的一致性保证。HDFS达到了怎样的一致性，这里就不 在展开了，另外再做详细的讨论。
总之，保证一直性对于分布式文件系统，甚至所有的分布式系统都是很重要的。
1.GFS: Evolution on Fast-forward, Sean Quinlan， 2009,
https://queue.acm.org/detail.cf m?id=1594206
