基于Azure Blob Storage的分布式文件同步服务原子性上传方案咨询

首先明确：Azure Blob Storage没有原生支持生成能批量获取前缀下所有Blob租约、并实现批量上传原子提交的预签名URL——因为预签名URL是绑定单个Blob的特定操作，而租约也是针对单个Blob的资源锁。但可以通过以下几种方案实现类似的原子性效果：

方案1：临时存储区 + 服务器端批量原子复制 #

• 客户端通过预签名URL，先将所有待同步文件上传到临时前缀路径（比如temp/{user-id}/{sync-session}/），每个临时Blob可单独设置短租约（服务器生成预签名URL时附带租约ID，确保只有该客户端能修改）。
• 所有Blob上传完成后，客户端通知服务器触发批量操作：服务器将临时路径下的Blob原子复制到目标前缀（单个Blob的复制操作是原子的），并逐一验证复制状态。
• 确认所有复制成功后，删除临时Blob；若有失败，直接丢弃临时数据，目标前缀的现有Blob不受影响。

方案2：版本控制 + 软删除实现回滚式原子性 #

• 给目标容器开启Blob版本控制和软删除功能。
• 客户端用预签名URL直接上传到目标前缀，覆盖现有Blob（新版本会自动生成，旧版本保留）。
• 所有上传完成后，服务器校验所有Blob的上传状态：
  • 全部成功：保留新版本，可按需清理旧版本；
  • 存在失败：通过版本控制API回滚到旧版本，恢复同步前的状态。
• 这种方式无需租约，靠版本机制实现“要么全成功，要么回滚”的原子性效果。

方案3：服务器端预获取租约 + 带租约的预签名URL #

• 服务器先通过List Blobs API枚举目标前缀下的所有现有Blob，逐个获取排他租约，记录每个Blob的租约ID。
• 为每个目标Blob生成带x-ms-lease-id参数的预签名上传URL（限制只有持有该租约的客户端才能覆盖Blob），分发给客户端。
• 客户端完成所有Blob上传后，通知服务器：
  • 全部成功：服务器逐个释放租约，完成同步；
  • 存在失败：服务器直接释放所有租约，现有Blob的锁被解除，状态不会被修改。

注意：方案3需要服务器处理租约的批量获取和释放逻辑，若服务器崩溃，需设置租约的过期时间（比如30分钟），避免Blob被永久锁定。

内容的提问来源于stack exchange，提问作者Chris O'Brien