Azure的Put Blob REST API操作文档告诉我们,只需一个请求即可上传最大64 MB的块blob。
我想知道这样的操作是否是原子的。特别是我需要知道以下假设是真还是假。
如果两个或多个客户端同时使用此API指定If-None-Match: *
来放置特定的非现有blob,则其中最多只有一个会成功。
使用此API的blob将永远不会被部分暴露。它将不存在或存在于包含元数据的整个内容(<64MB)。
任何人都可以确认或反驳这些假设吗?
答案 0 :(得分:5)
我已收到Microsoft支持技术人员直接确认这两个假设都是正确的:
如果两个或多个客户端同时使用此API指定If-None-Match: *
来放置特定的非现有blob,则其中最多只有一个会成功。
使用此API的blob将永远不会被部分暴露。它将不存在或存在于包含元数据的整个内容(<64MB)。
答案 1 :(得分:2)
Azure Put Blob操作是原子的吗? 答:完全没有。
任何在步骤3完成之前读取blob的尝试都会 导致HTTP 404(未找到)。
是的,100%安全,您将获得404
任何在步骤3完成后读取blob的尝试都会 要么看到整个blob内容和元数据,要么导致HTTP 如果步骤3未成功,则为404(未找到)。
是的,如果操作未完成,则blob存储中没有文件
尝试在blob之前添加带有If-None-Match:*标头的blob 步骤2的开始必须等到步骤3完成 成功在这种情况下,请求必须通过HTTP 409失败 (前提条件失败)或正常继续,因为blob不会 存在。
在我的测试中:没有等待。
因此,通常在第二次尝试上传相同的文件名后,您将收到 HTTP / 1.1 409指定的blob已存在。 (如果您使用 If-None-Match:* 标题发送了请求)
问题是,如果第一个上传文件尚未收到第一个201确认(如果您在一个请求中上传所有内容,则为唯一),那么即使第二个文件已启动,也将允许第二个文件创建资源在第一个之后。如果第二个文件比第一个文件短,则会发生这种情况,因为可能只是在第一个(短)请求中文件将完成传输。
最奇怪的是,当发生这种情况时,第一个流将继续正常上传数据,直到发出最后一个请求为止,最后一个请求的答案将为409.
我强烈建议您创建一个尖峰解决方案来测试您的特定用例,因为上述情况可能不是您应用程序的有效用例。