.NET下实现大量小Azure Blobs高效并行上传的方案求助

针对你1000个2KB小Blob的上传需求，结合你遇到的并发利用率低、随机异常问题，下面是针对性的优化方案，可实现50并发下4秒左右完成，且仅处理限流异常：

1. 解决连接池限制核心问题 #

默认.NET的HttpClient连接数限制为10，这会直接导致你即使开50并发，实际能发出去的请求也只有10个左右——这就是SemaphoreSlim令牌没被充分利用的核心原因。在应用启动时配置：

// 调整全局连接限制，数值需大于你的目标并发数
ServicePointManager.DefaultConnectionLimit = 60;
// 禁用Nagle算法，减少小数据包传输延迟
ServicePointManager.UseNagleAlgorithm = false;
// 关闭Expect100Continue，加速小请求的响应速度
ServicePointManager.Expect100Continue = false;

2. 重构精准限流重试的上传方法 #

用Polly实现仅针对429限流异常的重试逻辑，避免自定义重试的阻塞问题，同时确保资源正确释放：

using Polly;
using Polly.Retry;
using Azure.Storage.Blobs;
using Azure.Core;

// 初始化重试策略：仅处理429限流异常，最多重试3次，间隔指数退避
var retryPolicy = Policy.Handle<RequestFailedException>(ex => ex.Status == 429)
    .WaitAndRetryAsync(3, retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)));

// 复用BlobServiceClient和ContainerClient，避免重复初始化开销
var blobServiceClient = new BlobServiceClient("your_connection_string");
var containerClient = blobServiceClient.GetBlobContainerClient("your_container");

async Task UploadBlobAsync(string blobName, byte[] content, AsyncRetryPolicy retryPolicy, SemaphoreSlim semaphore)
{
    await semaphore.WaitAsync();
    try
    {
        var blobClient = containerClient.GetBlobClient(blobName);
        // 直接传字节数组，小文件自动使用Put Blob接口（无需块上传）
        await retryPolicy.ExecuteAsync(async () =>
        {
            await blobClient.UploadAsync(new MemoryStream(content), overwrite: true);
        });
    }
    finally
    {
        // 确保无论成功失败都释放并发令牌
        semaphore.Release();
    }
}

3. 优化并发调度逻辑 #

确保所有任务均为纯异步操作，避免任何同步阻塞，同时正确初始化SemaphoreSlim：

var semaphore = new SemaphoreSlim(50); // 设定50并发上限
var tasks = new List<Task>();
var random = new Random();

// 模拟1000个2KB的Blob内容
for (int i = 0; i < 1000; i++)
{
    var blobName = $"small-blob-{i}.dat";
    var content = new byte[2048];
    random.NextBytes(content);
    
    tasks.Add(UploadBlobAsync(blobName, content, retryPolicy, semaphore));
}

await Task.WhenAll(tasks);

关键问题解释 #

• 并发利用率低：核心是默认连接池限制了实际并发请求数，拿到令牌的任务卡在网络IO环节无法快速释放令牌，FakeTask无网络操作所以能耗尽令牌。
• 随机Socket异常：多因未正确复用客户端资源、连接池配置不合理导致连接被意外关闭，复用Blob客户端+正确的try/finally释放令牌可解决。
• 性能达标：调整连接池后50并发可真正跑满，小文件用Put Blob接口配合精准重试，1000个2KB Blob可控制在4秒左右完成。

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