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

Question

我的问题可能是我对 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

如果是因为list操作最终一致，FileSystem实现是用list操作来判断destination是否还存在，那么我明白了，然后有没有推荐的解决方案，确保destination之前不再存在重命名？

谢谢，卢克

Answer 1

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

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

那总是会失败。

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

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

Answer 2

特拉维斯的回答已经有几年历史了，不再正确了。 Object 列表操作现在是强一致的。阅读 Google 的 post.

GCS - Global Consistency with delete + rename