前言
最近，部门内部组织了学习活动，前两课就是研读著名的可扩展分布式文件系统 GFS 论文，并布置了学习作业，就是整理 GFS 中提出的一致性模型，如下文：
一致性背景
分布式存储系统中，不管是文件系统还是数据库，只要数据存在多个副本，都涉及一致性问题。其中一致性包括内部一致性和副本一致性，内部一致性即单机版数据库中的数据满足一定的约束条件。副本一致性表示同一数据的多个副本的值相同。GFS 作为一种分布式文件系统，采用了多副本机制，自然也会有一致性问题
一致性模型
具体操作
修改操作： 包括写操作和追加操作，写操作需要指定文件块 + offset。追加操作成功后系统会将追加成功的偏移量返回给客户端。
并发写： 如果两个客户端同时写同一个文件块的同一偏移量，那么就有个先后顺序问题，如果接近同时，系统不保证这个顺序。那么客户端再去读，就不一定能读到自己刚写的数据。
追加失败： 追加操作会保证至少成功一次。追加操作时，假设配置三副本，但是只有两个副本写成功，最后一个副本超时了（可能对应块服务器宕机，当然重启后 GFS 会用 chunk version 来标记其过期 stale 了，从而跳过该 offset。），那么追加操作会重试，并且失败数据不会删除，但是 GFS 有对齐操作，即重试成功后，三个副本中该追加数据的起始偏移量是定义的（也就是一致的），那么其中那个上次失败的副本就会有个空洞，系统会用特殊字符填充。
结论： 定义未定义针对的是多客户端并发写同一个偏移量的覆盖顺序问题；一致不一致针对的是多个副本相同偏移量的内容是否相同
概念解析
已定义（defined）：客户端写某个偏移量后，再读，读到的一定是自己的。
未定义的但是一致的（undefined but consistent）：多个客户端并发写同一个偏移量，不确定谁会覆盖谁（这个顺序由 Primary Replica 所在 Chunkserver 来安排，后面将会讲），即写完后再读，不确定是自己写的还是其他人写的。但是保证最终一致性，即并发写完成后，最后几个副本是一致的。
不一致的（inconsistent）：即修改操作后，所有副本同一偏移量的数据并不完全相同。
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
