深入理解tusd项目中Azure存储Blob版本化问题

在tusd项目中实现Azure Blob存储版本化功能时，开发者可能会遇到一个关键的技术挑战：当尝试更新已存在的Blob文件时，系统仍然返回原始版本而非最新上传的版本。本文将深入分析这一问题的根源，并提供解决方案。

问题背景

Azure Blob存储提供了版本控制功能，允许用户维护同一Blob的多个版本。当开发者使用tusd（一个基于tus协议的分片上传服务）上传文件到Azure Blob存储时，期望通过相同路径上传新文件能够创建新版本。然而在实践中发现，即使上传成功，下载时仍然获取到原始版本而非更新后的内容。

技术分析

问题的核心在于tusd的Azure存储服务实现中获取块列表的方式。在azureservice.go文件中，getOffset函数使用BlockListAll参数来获取块列表，这会导致返回已提交和未提交的所有块。

关键代码段如下：

getBlock, err := blockBlob.Blob.GetBlockList(ctx, azblob.BlockListAll, azblob.LeaseAccessConditions{})

使用BlockListAll会返回两个版本文件的块信息（更新版和原始版），而实际上我们只需要关注未提交的块（即当前正在上传的版本）。

解决方案

经过实践验证，将BlockListAll改为BlockListUncommitted可以解决此问题：

getBlock, err := blockBlob.Blob.GetBlockList(ctx, azblob.BlockListUncommitted, azblob.LeaseAccessConditions{})

这一修改确保系统仅处理当前上传会话中的未提交块，而不会混淆不同版本的文件块。测试表明，这种修改不会影响tusd的正常功能，同时能正确支持Azure Blob的版本控制特性。

实现建议

对于需要在tusd中实现Azure Blob版本化的开发者，建议：

1. 修改azureservice.go中的块列表获取逻辑，使用BlockListUncommitted替代BlockListAll
2. 确保Azure存储账户已启用Blob版本化功能
3. 在上传新版本时使用相同的Blob路径
4. 测试上传和下载流程，验证版本控制功能是否正常工作

这一修改已被证实能够有效支持Azure Blob存储的版本控制功能，同时保持tusd原有的分片上传特性。开发者可以放心地在生产环境中应用此解决方案。