Azure Cloud Block Blob，防止进程覆盖其他进程所做的更改

我的 Azure 云 block blob 用例场景如下:

1. Azure 存储容器中有一个名为 phone-numbers.txt 的 blob

2.机器 A 下载 Blob，进行一些更改，然后将其上传到具有相同 Blob 名称的容器。

3. 机器 B 可能会做与机器 A 相同的事情，但有不同的变化。

计算机 A 和 B 可以同时下载 blob，但计算机 A 可能会更快地完成更改并将更改上传到容器。

当计算机 B 在不知道计算机 A 已对 blob 进行更改的情况下上传其更改时，就会出现此问题。当然，我可以让每台机器只进行 Append 操作，但是如果两台机器所做的更改相同，我只需要保留一个，而不是追加相同的更改两次。

所以我想知道Azure存储是否有任何现有机制来防止这种覆盖发生。如果Azure没有它，我正在考虑使用blob中的元数据并在元数据中拥有版本字段:

当机器更新 blob 时，它会将版本增加 +1。在机器上传 blob 之前，它会下载相同的 blob 并检查其版本与第一次下载相比是否已更改。我知道这并不完美，而且 blob 下载似乎是多余的。

还有其他更好的方法来防止覆盖发生吗？

最佳答案

恕我直言，blob 租赁并不是解决此问题的正确方法。让我解释一下。

假设进程 A 和 B 都下载了 blob 来处理它，并且 A 能够获取该 blob 的租约。现在考虑这些场景:

B 在 A 之前完成了作业:即使 B 在 A 之前完成了作业，B 也无法保存该 blob，因为 A 对该 blob 具有独占锁。 B 需要等待 A 释放锁才能保存更改。
A 在 B 之前完成了作业:在这种情况下，锁将被释放，因此 B 将能够保存更改，但它不知道 A 已进行更改，因此 A 也进行了更改将被 B 的更改覆盖。

要解决此问题，您需要使用 Azure 存储默认支持的乐观并发功能。这是通过利用 Blob 的 ETag 属性来完成的，该属性会在 Blob 发生更改时更新。

因此考虑与上面相同的示例，A 和 B 都下载了 blob 并开始对其进行编辑。

B 在 A 之前完成工作:在这种情况下，B 将能够保存更改。一旦 B 保存更改，blob 的 ETag 将被更改，现在当 A 尝试保存更改时，存储服务将抛出一个错误(419 - Precondition Failed)，该错误将告诉 A:该 Blob 已经改变。 A 需要再次下载 blob 并进行更改并再次保存。
A 在 B 之前完成了作业:将会发生与上面相同的情况，但现在 B 将出现相同的错误，并且 B 将需要重新下载 blob 并进行更改并再次保存。

关于Azure Cloud Block Blob，防止进程覆盖其他进程所做的更改，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57614917/