Google文件系统的一致性模型

Question

我正在阅读关于GFS以及其一致性模型的内容，但是有些地方我还无法理解。

特别是，能否有人提供具体的示例场景（或者为什么不可能发生）：

• 并发记录追加可能导致记录重复
• 并发记录追加可能导致未定义区域
• 并发写入（在单个块上）可能导致未定义区域

- Simone

Answer 1

以下内容摘自http://research.google.com/archive/gfs.html，请查看表格1，这是写入/追加可能的结果概要：

1. "如果记录追加在任何一个副本上失败，则客户端将重试该 操作。因此，同一块的副本可能包含 不同的数据，可能包括相同的重复记录 完全或部分." 因此，任何一个副本失败（如超时）都会导致至少在其他副本上出现重复记录。这可以在没有并发写入的情况下发生。

2. 导致重复记录的相同情况也会导致不一致（因此未定义）的区域。如果副本未能确认变异，则可能未执行变异。在这种情况下，当客户端重试附加操作时，此副本将不得不添加填充以代替缺失的数据，以便可以在正确的偏移量处编写记录。 因此，一个副本将具有填充而另一个副本将在该区域中具有先前编写的记录。

3. 失败的写入也可能导致不一致（因此未定义）的区域。更有趣的是，成功的并发写入也可能导致一致但未定义的区域。"如果应用程序的写入很大或跨越块 边界，GFS客户端代码将其分解成多个 写操作。它们[...]可能会与来自其他客户端的并发操作交错和覆盖。 因此，共享文件区域可能包含来自不同客户端的片段， 虽然副本将是相同的，因为各个 操作在所有副本上以相同的顺序成功完成。这使得文件区域处于一种一致但未定义的状态[...]。"

- Daniel Darabos

---

嗨，Daniel，感谢您的答案，它回答了我的大部分问题。然而仍有一件事情：我的主要困惑源于客户端仅与主副本通信，并且是这个副本等待其他副本的确认。因此，如果一个辅助副本在追加时失败，那么主副本将知道发生了这种情况，并且没有理由增加文件末尾的指针； 因此，后续的新追加应该覆盖该不一致区域。我漏掉了什么？ - Simone

我认为按照你所说的做是可能的。但我认为GFS并没有这样做。如果他们这样做了，我想他们会提到这一点。我的无知猜测是这样做是为了增加并发追加的吞吐量。如果主节点想要在失败的情况下能够移动指针，那么它将无法接受其他记录的追加，而其中一个正在进行中。如果即使对于失败的变异也增加指针，则可以立即接受其他追加。如果有人能够确认/更正这个理论，那就太好了。 - Daniel Darabos

一旦主节点在副本上收到故障，它插入的下一个记录必然是相同的，因为它会进行“客户端重试”操作。那么，像您所说的其他附加操作如何实现呢？ - sww

为什么它们不可能呢？ - Daniel Darabos

Answer 2

我认为这与“并发追加”无关，但与他们系统的“至少一次语义”有关。

失败是大型分布式系统的根本问题。在存在故障的情况下，发送方可能不知道网络另一端的计算机是否完全接收了其消息。

对于这种情况，分布式系统保证消息只会被传递“至多一次”或“至少一次”。

在这种情况下，GFS选择将消息“至少一次”传递到存储节点。

- Michael Deardeuff

---

谢谢您的回答！所以，只有在主块服务器在写入数据并更新文件结尾后遇到错误时，才会发生这种情况，对吗？ - Simone