我在 Azure blob 存储上托管了一个 Excel 文件，用于记录与网站有关的使用情况统计信息。访问 Azure 存储的应用程序是一个 Web API，它利用 blob 引用和内存流从 blob 异步来回写入数据。
将数据写回 blob 的异步操作是否作为读写器问题的一部分进行处理，例如假设最初有 10 条记录，现在两个用户同时访问 blob。最终 Blob 是否会更新为 12 条记录？
【问题讨论】：
标签： azure
执行将数据写回 blob 的异步操作 作为读写器问题的一部分进行处理，例如让我们说 最初有 10 条记录，现在有两个用户正在访问 同时出现斑点。是否将 blob 更新为包含 12 条记录 结束了吗？
假设两个用户同时读取 blob，最后一个更新 blob 的用户将覆盖另一个用户所做的更改。所以用户 A 和 B 读取了 blob。现在用户 A 更新了 blob，不久之后用户 B 更新了 blob。在这种情况下，用户 A 所做的更改将被用户 B 覆盖。
您可以通过在更新请求中指定条件标头来防止这种行为。这由许多事情促成，但最常见的是使用 blob 上的 ETag 属性。在这种情况下，用户 A 和 B 都将读取该 blob。对于 blob 的 ETag，它们都具有相同的值。现在，用户 A 有条件地更新 blob（即，仅当更新期间出现的 ETag 值与 blob 的最新 ETag 值匹配时才告诉 Azure 存储服务更新 blob）。由于该 blob 尚未被其他任何人更新，因此此操作将成功。现在用户 B 也有条件地更新 blob，但是此更新将失败，因为当用户 A 更新 blob 时，其 ETag 值已更改。在这种情况下，用户 B 需要再次获取 blob 的内容并应用更改并再次保存 blob。
如果用户一直在将数据添加到 blob 的末尾，则另一种选择是使用 Append Blobs。 Append Blobs没有这个问题。
【讨论】：