Google 文件系统一致性模型答案

【问题标题】：Google File System Consistency ModelGoogle 文件系统一致性模型
【发布时间】：2015-01-09 16:01:30
【问题描述】：

我正在阅读有关 GFS 及其一致性模型的信息，但我没有掌握其中的一些内容。特别是，有人可以为我提供一个具体的示例场景（或解释为什么它不会发生）：

【问题讨论】：

【解决方案1】：

我引用http://research.google.com/archive/gfs.html。查看表 1，它总结了写入/追加的可能结果：

"如果记录追加在任何副本失败，客户端会重试手术。因此，同一块的副本可能包含不同的数据可能包括相同的重复全部或部分记录。” 因此，副本上的任何故障（例如超时）都会导致至少在其他副本上出现重复记录。这可能在没有并发写入的情况下发生。
导致重复记录的相同情况也会导致不一致（因此未定义）区域。如果一个副本未能确认突变，它可能没有执行它。在这种情况下，当客户端重试追加时，此副本将必须添加填充来代替丢失的数据，以便可以在正确的偏移量处写入记录。因此，一个副本将有填充，而另一个副本将具有该区域中先前写入的记录。
写入失败也可能导致区域不一致（因此未定义）。更有趣的是，成功的并发写入会导致一致但未定义的区域。 "如果应用程序的写入很大或跨越一个块边界，GFS 客户端代码将其分解为多个写操作。它们 [...] 可能与并发交错并被并发覆盖来自其他客户的操作。因此，共享文件区域可能最终包含来自不同的片段客户端，虽然副本将是相同的，因为个人操作在同一个成功完成订购所有副本。这使文件区域保持一致但未定义的状态 [...]。”

【讨论】：

嗨丹尼尔感谢您的回答，它回答了我的大部分问题。不过还有一件事：我的主要困惑来自客户端只与主副本通信，而正是这个副本等待其他副本的确认。因此，如果一个辅助副本在追加失败，那么主副本将知道这已经发生并且没有理由增加指向文件末尾的指针；因此，新的追加应该稍后覆盖该不一致的区域。我错过了什么？
我觉得按照你说的做是可以的。但我认为 GFS 不会那样做。我想如果他们这样做了，他们会提到这一点。我未经教育的猜测是，这是为了增加并发追加的吞吐量。如果主节点希望能够在失败的情况下将指针移回，那么它将无法在一个正在进行时接受其他记录追加。如果即使对于失败的突变它也会增加指针，那么它就能够立即接受其他追加。如果有人能证实/纠正这个理论，那就太好了。
一旦主副本在副本上收到故障，它插入的下一条记录必然是相同的，对吧？正如它所说的“客户端重试”操作。那么像你说的那样，其他的追加怎么可能呢
为什么不可能？

【解决方案2】：

我不认为它真的与 并发追加有关，但与他们系统的 至少一次语义有关。

故障是大型分布式系统的一个基本问题。如果出现故障，发件人可能不知道网络另一端的计算机是否完全收到了它的消息。

在这种情况下，分布式系统保证消息要么最多发送一次，要么至少发送一次。

在这种情况下，似乎 GFS 决定至少一次向存储节点交付。

【讨论】：