GCS - 删除 + 重命名的全局一致性答案

【问题标题】：GCS - Global Consistency with delete + renameGCS - 删除 + 重命名的全局一致性
【发布时间】：2015-12-22 18:54:17
【问题描述】：

我的问题可能是由于我对 google 存储的全局一致性存在误解，但由于我直到最近（11 月中旬）才遇到这个问题，现在它似乎很容易重现，我想澄清一下。该问题开始发生在使用 bdutil 在计算引擎上运行的一段 spark 代码中，但我可以使用 gsutil 从命令行重现。

我的代码正在删除目标路径，然后立即将源路径重命名为目标路径。由于目标路径不再存在，我希望具有全局一致性，src 将被重命名为目标，但 src 被嵌套在目标内部，就好像目标仍然存在并且不一致。

重现的hadoop代码如下：

fs.delete(new Path(dest), true)
fs.rename(new Path(src), new Path(dest))

从命令行我可以重现：

gsutil -m rm -r gs://mybucket/dest
gsutil -m cp -r gs://mybucket/src gs://mybucket/dest

如果原因是因为列表操作最终一致并且FileSystem实现是使用列表操作来确定目标是否仍然存在，那么我理解，那么是否有推荐的解决方案来确保在重命名之前目标不再存在？

谢谢，卢克

【问题讨论】：

【解决方案1】：

特拉维斯的回答是几年前的，不再是真的了。对象列表操作现在是强一致的。阅读谷歌的post。

【讨论】：

【解决方案2】：

写后读（包括删除）操作是强一致的，例如，如果你这样做了：

gsutil -m rm -r gs://mybucket/dest
# Command output shows it removed gs://mybucket/dest/file1
gsutil cp gs://mybucket/dest/file1 my_local_dir/file1

那总是会失败的。

但是，要确定“目录”是否存在，gsutil 必须执行最终一致的列表操作，以确定 Google Cloud Storage 的平面名称空间中的任何对象是否具有带有该“目录”名称的前缀。这可能会导致您描述的问题，我希望 hadoop 代码的行为类似。

没有针对此问题的高度一致的解决方法，因为无法以高度一致的方式检查前缀是否存在。

【讨论】：