如何适应松弛的一致性模型
这种松弛的一致性模型,实际上是一种不能保证一致性的模型,或者更准确的说是一致性的数 据中间夹杂不一致数据。
这些夹杂其中的不一致数据,对应用来说是不可接受的。在这种一致性下,应该如何使用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