替代BlobContainerClient.CreateIfNotExistsAsync规避409错误的高并发风险问询

前提条件 #

• WindowsAzure.Storage V 9.3.3
• Azure.Storage.Blobs V 12.6.0
• Datadog APM监控

背景 #

1. 使用Blob客户端的CreateIfNotExists(Async)方法时，若容器已存在会返回409错误
2. 当前实现中该检查逻辑会在每个请求中执行，调用频次极高
3. 导致日志和Datadog监控中出现大量409错误日志
4. 无法将该检查逻辑迁移至应用启动/根目录以减少调用

拟修复方案 #

计划替换原有CreateIfNotExistsAsync调用为以下代码：

if (!await blobClient.ExistsAsync().ConfigureAwait(false))
{
   await containerClient.CreateAsync().ConfigureAwait(false);
}

核心疑问 #

在高并发工作流中，上述替换方案是否会引发问题？

补充说明 #

已查看Azure.Storage.Blobs NuGet包中CreateIfNotExistsAsync的实现，个人认为其没有特殊的并发处理机制，但不确定该判断是否正确，希望获取相关实践经验。

你的替换方案在高并发场景下确实会存在竞态条件问题，具体分析如下：

1. 竞态条件的触发场景 #

当多个请求同时进入代码分支时：

• 请求A执行blobClient.ExistsAsync()，返回false（容器不存在）
• 请求B几乎同时执行blobClient.ExistsAsync()，同样返回false
• 随后请求A和请求B都会执行containerClient.CreateAsync()
• 此时先执行的请求A会成功创建容器，后执行的请求B会收到409错误（容器已存在）

这和你原本想避免的问题本质上没有区别，只是把CreateIfNotExistsAsync内置的409换成了自己代码逻辑产生的409。

2. 关于CreateIfNotExistsAsync的实现逻辑 #

你对CreateIfNotExistsAsync的判断是正确的：它的底层逻辑其实就是先检查容器是否存在，不存在则创建，整个过程没有加锁或分布式事务保护，本质上和你自己写的ExistsAsync+CreateAsync逻辑是一致的，同样会在高并发下出现409。

3. 可行的优化方向 #

如果无法将容器创建逻辑迁移到应用启动阶段，建议采取以下方案：

• 直接捕获409错误并忽略：无论是用CreateIfNotExistsAsync还是自己的逻辑，都在代码中捕获容器已存在的409异常，不记录错误日志，只记录调试级别的信息。这样既保证逻辑正确性，又不会污染监控和日志。
• 引入本地缓存+过期机制：在应用内存中维护一个容器存在性的缓存标记，设置较短的过期时间（比如1分钟）。每次请求先检查缓存，缓存命中则跳过创建逻辑；缓存未命中时再执行ExistsAsync+CreateAsync逻辑，更新缓存。这种方式能大幅减少存储服务的调用次数，降低409出现的概率。
• 使用命名约定或预创建容器：如果业务允许，提前通过Azure Portal、ARM模板或CI/CD流程预创建所需容器，彻底避免运行时的容器创建逻辑。

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