我在Azure blob存储上托管了一个Excel文件，用于记录与网站相关的使用情况统计信息。访问Azure存储的应用程序是一个Web API，它利用blob引用和内存流来从blob 异步来回写入数据。
将数据写回blob的异步操作是否作为读写器问题的一部分进行处理，例如我们说最初有10条记录，现在有两个用户同时访问blob。是否会更新blob到最后有12条记录？
答案 0 :(得分：1)
将数据写回blob的异步操作 作为读写者问题的一部分处理，例如我们说吧 最初有10条记录，现在有两个用户正在访问 blob在同一时间。是否会更新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没有这个问题。