如何限制返回FileResult的MVC方法的并发下载数至3个？

这个需求其实挺常见的，我给你几个可行的实现思路，都是在ASP.NET MVC环境下能直接落地的方案：

方法一：用SemaphoreSlim（最直接的方案） #

.NET里的SemaphoreSlim就是专门用来控制并发访问量的轻量级工具，完全适配你的场景。你只需要在控制器里声明一个静态的信号量实例，初始允许3个并发，然后在下载方法里用它来包裹文件下载逻辑就行。

示例代码如下：

public class DownloadController : Controller
{
    // 静态信号量：初始允许3个并发，最大也限制为3
    private static readonly SemaphoreSlim _downloadSemaphore = new SemaphoreSlim(3, 3);

    public async Task<IActionResult> DownloadFile(int fileId)
    {
        // 等待获取信号量，如果当前并发满了，就阻塞直到有空闲位置
        await _downloadSemaphore.WaitAsync();
        try
        {
            // 替换成你自己的文件获取逻辑：比如从磁盘、数据库或云存储读取
            var fileBytes = await GetTargetFileBytes(fileId);
            var fileName = $"Document_{fileId}.pdf";
            
            return File(fileBytes, "application/pdf", fileName);
        }
        finally
        {
            // 不管下载成功还是失败，必须释放信号量，避免死锁
            _downloadSemaphore.Release();
        }
    }

    // 模拟文件读取的方法，你可以替换成实际业务逻辑
    private async Task<byte[]> GetTargetFileBytes(int fileId)
    {
        // 模拟IO耗时（比如读取大文件的过程）
        await Task.Delay(1500);
        // 返回测试用的字节数组，实际中替换为真实文件内容
        return new byte[1024 * 1024 * 5];
    }
}

⚠️ 注意：

• 信号量必须是静态的，不然每个控制器实例都会生成独立的信号量，起不到全局限制并发的作用
• 一定要在finally块里释放信号量，哪怕下载过程抛出异常，也能保证信号量不会被永久占用

方法二：用自定义Action Filter（更优雅的解耦方案） #

如果不想把并发控制逻辑和业务代码混在一起，可以封装一个自定义的Action Filter，把信号量逻辑藏在过滤器里，这样所有需要限制并发的下载接口都能直接复用。

先写过滤器代码：

public class ConcurrentDownloadLimitAttribute : ActionFilterAttribute
{
    // 全局共享的信号量
    private static readonly SemaphoreSlim _concurrentSemaphore = new SemaphoreSlim(3, 3);

    public override async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        await _concurrentSemaphore.WaitAsync();
        try
        {
            // 执行后续的Action业务逻辑
            await next();
        }
        finally
        {
            _concurrentSemaphore.Release();
        }
    }
}

然后在你的下载接口上标注这个特性就行：

[ConcurrentDownloadLimit]
public async Task<IActionResult> DownloadFile(int fileId)
{
    // 这里只需要写纯粹的文件下载逻辑，不用管并发控制
    var fileBytes = await GetTargetFileBytes(fileId);
    return File(fileBytes, "application/pdf", $"Document_{fileId}.pdf");
}

这种方式的好处是代码解耦，以后要调整并发数或者修改控制逻辑，只需要改动过滤器即可，不用逐个修改接口。

额外建议 #

• 如果你的应用是多服务器部署的，上面的方案只能限制单服务器的并发数。如果需要全局跨服务器限制，就得用分布式锁（比如基于Redis的实现），不过单服务器限制已经能满足大部分中小规模场景了。
• 可以给信号量等待加个超时时间，比如await _downloadSemaphore.WaitAsync(TimeSpan.FromSeconds(10))，如果超时就返回“当前下载人数过多，请稍后再试”的提示，避免用户无限制等待。

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