Azure Blob存储不会暴露任何类型的“blob重命名”操作 - 这听起来很荒谬，因为重命名实体的想法几乎是任何存储系统中的基本操作 - 而Azure的文档没有提及blob的名称是如何内部使用（例如作为DHT密钥），但是我们可以指定自己的名称，很明显Azure没有使用内容可寻址的存储模型（因此，一旦Azure存储团队，就可以重命名 决定允许它。）
微软主张改为“重命名”一个blob，你只需复制它，然后删除原始文件 - 这看起来非常低效 - 例如，如果你有一个200GB的视频文件blob，blob名称中有拼写错误 - 除非内部Azure有一些重复数据删除系统 - 在这种情况下，消除“blob重命名”的特殊情况是完全合理的，因为在内部它实际上是一个“名称复制”操作。
不幸的是，blob副本的当前文档（https://docs.microsoft.com/en-us/rest/api/storageservices/fileservices/copy-blob）没有描述任何内部进程，事实上，这表明blob副本可能是一个非常长的操作：
复制操作的状态，包含以下值：
success：副本已成功完成。pending：副本正在进行中。
如果它在内部使用重复数据删除系统，则所有blob复制操作都是即时的，因此不需要“进行中”状态;同样令人困惑的是，它使用“待定”来表示“正在进行中” - 通常情况下，“待定”意味着“排队，尚未开始”。
令人震惊的是，文件还说明了这一点：
2周后未完成的复制尝试并留下空白斑点
...可以理解为复制blob所需的时间没有任何保证。与更大的blob相比，页面中没有任何内容表明较小的blob被更快地复制 - 因此由于某种原因（例如长队列，不幸的中断等），在假设的200GB中纠正我的假设错误可能需要2周时间视频文件 - 并且不要忘记在复制操作完成之前我无法删除原始错误名称的blob - 这意味着需要设计我的客户端软件以不断检查并最终发出删除操作（并确保我的软件连续运行到2周......）。
是否有关于Azure Blob复制操作的运行时特征和性质的权威信息？
答案 0 :(得分：2)
您可能已经知道Copy Blob操作是一个异步操作，上面提到的所有内容都是正确的，但有一点需要注意。 复制操作在同一存储帐户中进行复制时是同步的。即使您在存储帐户或存储帐户中复制blob，但是在同一存储帐户中执行此操作时，即使您获得相同的状态，它也几乎立即发生。
因此，当您重命名blob时，您将在同一存储帐户（甚至同一容器）中创建blob的副本，该副本是即时的。我不是100％确定内部实现，但如果我在同一存储帐户中复制blob时没有弄错，它不会在某个单独的位置复制字节。它只是创建指向相同存储数据的2个指针（新blob和旧blob）。一旦你开始对blob进行更改，我认为那时它会改变那些字节。
对于Azure存储的内部理解，我强烈建议您阅读几年前团队发布的文章。请查看我的答案，其中包含本文的链接：Azure storage underlying technology。