05 | The Google File System （三）： 多写几次也没关系

GFS系统设计中的一致性要求是一个挑战性话题。2003年的GFS对一致性的要求非常宽松，主要考虑了保持简单和硬件特性。在GFS中，一致性分为“一致的”和“确定的”两个层级。数据写入失败会导致数据不一致，而顺序写入成功则保证数据的确定性。然而，并发写入可能导致数据一致但非确定的状态，这是因为数据写入顺序不需要通过Master协调，并且随机的数据写入可能要跨越多个chunk。因此，建议在客户端应用层面保障数据写入是顺序的，以避免并发写入的出现。 GFS的宽松一致性要求体现了其设计原则和硬件特性，为分布式系统中的一致性问题提供了新的思路。 GFS支持记录追加（Record Appends）操作，这是GFS希望主要使用的数据写入方式，具有原子性和并发写入时的基本确定性。然而，GFS的一致性保障相当低，只保证数据追加至少被写入一次，无法保证数据追加的顺序。这种设计适合Google的应用场景，如搜索引擎抓取网页存储和日志数据。虽然GFS的一致性保障较低，但其设计简单、围绕硬件性能设计，适用于高并发大量追加写入的应用场景。 GFS的记录追加模型带来了高并发和高性能的好处，同时也简化了系统架构，减少了一致性模型的复杂性。尽管GFS的一致性保障较低，但其设计与应用场景匹配，为高并发大量追加写入的新日志、网页和索引等应用提供了有效支持。在后续的MapReduce和Bigtable论文中，我们也会看到类似的设计选择。 总的来说，GFS的设计原则是简单、围绕硬件性能设计，并对一致性有宽松要求。这使得GFS成为一个非常优秀的工程化系统，适用于特定的大规模分布式应用场景。