Azure Storage Blob上传遇UUID文件名冲突报错，请求排查原因

可能的原因分析 #

1. Azure SDK默认重试机制触发（最可能） #

你代码里没显式设置重试，但Azure Storage Java SDK（azure-storage-blob）默认自带重试策略，比如指数退避重试，针对网络超时、服务端5xx等可重试错误会自动发起重试。

如果第一次上传请求已经成功写入Blob，但客户端因为网络波动没收到响应，SDK会认为请求失败并触发重试，此时重试请求会因为Blob已存在而返回409错误。这种场景在性能测试的高并发/网络不稳定环境下很容易出现，也是你1-2小时内多次遇到报错的核心原因。

2. UUID生成异常（概率极低） #

UUID.randomUUID()理论上冲突概率可以忽略，但如果JVM的随机数生成器出现异常（比如依赖的系统熵源不足，导致生成的随机数重复），也可能出现重复UUID。可以通过打印每次生成的blobName到日志，确认报错时的Blob名称是否重复来验证。

3. 测试环境Blob残留 #

如果测试前没有清空存储容器，旧测试生成的Blob可能和新生成的UUID重复，但短时间内多次出现的概率极低，可查看容器内Blob的创建时间做验证。

4. 前缀拼接问题 #

确认BLOB_PREFIX是否为固定值，有没有可能在运行中被修改或注入重复内容？从你给出的代码看这种可能性不大，但可以快速排查确认。

关于重试机制的疑问 #

• 你代码没设置重试，但Azure Storage SDK确实有默认重试策略：默认会对可重试错误（如网络超时、500/503等）进行指数退避重试，默认重试次数为3次（不同SDK版本可能有细微差异）。
• 本次的409报错大概率就是默认重试导致的：第一次上传成功，客户端没收到响应，SDK重试时触发重复上传。

解决建议 #

1. 显式控制重试行为：

   • 自定义重试策略，排除409错误的重试：

     RetryPolicy retryPolicy = new RetryPolicyBuilder()
         .retryOnStatusCodes(408, 500, 502, 503, 504) // 只针对指定状态码重试，排除409
         .build();
     BlobContainerClient blobContainerClient = new BlobContainerClientBuilder()
         .connectionString(connectStr)
         .containerName(containerName)
         .retryPolicy(retryPolicy)
         .buildClient();
     

   • 或者直接禁用重试：

     .retryPolicy(RetryPolicy.noRetry())
     

2. 上传时允许覆盖：
   使用upload的重载方法，设置overwrite参数为true，即使Blob已存在也会覆盖，避免409错误：

   blobClient.upload(BinaryData.fromObject(quote), true);
   

3. 排查UUID生成问题：
   若日志显示报错时Blob名称重复，需检查JVM随机数生成配置（比如是否使用/dev/urandom替代/dev/random避免熵源不足）。

内容的提问来源于stack exchange，提问作者Viktor