This page looks best with JavaScript enabled

GFS 一致性模型

 ·  ☕ 2 min read  ·  🙄 睡沙发の沙皮狗 · 👀... views

前言

一致性背景

分布式存储系统中,不管是文件系统还是数据库,只要数据存在多个副本,都涉及一致性问题。其中一致性包括内部一致性和副本一致性,内部一致性即单机版数据库中的数据满足一定的约束条件。副本一致性表示同一数据的多个副本的值相同。GFS 作为一种分布式文件系统,采用了多副本机制,自然也会有一致性问题

一致性模型

GFS 一致性模型

具体操作

修改操作: 包括写操作和追加操作,写操作需要指定文件块 + offset。追加操作成功后系统会将追加成功的偏移量返回给客户端。

并发写: 如果两个客户端同时写同一个文件块的同一偏移量,那么就有个先后顺序问题,如果接近同时,系统不保证这个顺序。那么客户端再去读,就不一定能读到自己刚写的数据。

追加失败: 追加操作会保证至少成功一次。追加操作时,假设配置三副本,但是只有两个副本写成功,最后一个副本超时了(可能对应块服务器宕机,当然重启后 GFS 会用 chunk version 来标记其过期 stale 了,从而跳过该 offset。),那么追加操作会重试,并且失败数据不会删除,但是 GFS 有对齐操作,即重试成功后,三个副本中该追加数据的起始偏移量是定义的(也就是一致的),那么其中那个上次失败的副本就会有个空洞,系统会用特殊字符填充。

结论:
定义未定义针对的是多客户端并发写同一个偏移量的覆盖顺序问题;一致不一致针对的是多个副本相同偏移量的内容是否相同

概念解析

已定义(defined):客户端写某个偏移量后,再读,读到的一定是自己的。

未定义的但是一致的(undefined but consistent):多个客户端并发写同一个偏移量,不确定谁会覆盖谁(这个顺序由 Primary Replica 所在 Chunkserver 来安排,后面将会讲),即写完后再读,不确定是自己写的还是其他人写的。但是保证最终一致性,即并发写完成后,最后几个副本是一致的。

不一致的(inconsistent):即修改操作后,所有副本同一偏移量的数据并不完全相同。

Share on

睡沙发の沙皮狗
WRITTEN BY
睡沙发の沙皮狗
👨‍💻 Backend Developer/📚 Learner/🚀 Opensource enthusiast

 

What's on this Page