使用MemoryCache缓存Task是否可行？REST API配置缓存优化问询

我通过REST API获取配置，目前用Semaphore实现缓存，但API不可用时会出问题。现有代码如下：

public async Task<Config> Config(CancellationToken ct = default) { 
    using (var releaser = await _asyncSemaphore.EnterAsync(ct))
    {
        if (_serverConfig != null) return _serverConfig;
        _serverConfig = await _restApi.GetConfig(ct).ConfigureAwait(false);
        return _serverConfig;
    }
}

但短时间内多次调用该函数时，若_restApi故障，会因锁导致调用同步超时（比如4次调用要等60秒）。我提出了用MemoryCache的解决方案：

public async Task<Config> Config(CancellationToken ct = default)
{
    if(_memoryCache.TryGetValue("configTask", out Task<Config> configTask))
    {
        return await configTask.ConfigureAwait(false);
    }

    using (var releaser = await _asyncSemaphore.EnterAsync())
    {
        if (_config != null) return _config;
        var task = _memoryCache.Set("configTask", _restApi.Config(ct), TimeSpan.FromSeconds(5));
        _serverConfig = await task.ConfigureAwait(false);
        return _serverConfig;
    }
}

该方案在首次调用5秒内的请求都会复用首个任务，超时则重新调用。请问此方法是否存在问题？使用MemoryCache缓存Task是否可行？

缓存Task的可行性 #

缓存Task<Config>是完全可行的，这是避免重复并发请求的经典方案——当多个请求同时进来时，复用同一个API调用任务，既不会重复发起请求，还能让所有请求共享结果（不管成功还是失败），比缓存最终结果更高效，尤其适合这种批量处理并发请求的场景。

现有方案存在的问题 #

1. 变量名不一致：代码里缓存检查逻辑对应_memoryCache中的任务，但锁内判断用的是_config != null，而后续赋值的是_serverConfig，这明显是笔误，会导致逻辑错误——比如API调用成功后_serverConfig已赋值，但锁内判断的_config始终为null，后续进入锁的请求会重复发起API调用。
2. 失败任务的缓存逻辑不合理：如果_restApi.Config(ct)执行失败（比如API不可用），失败的任务会被缓存5秒，这期间所有请求都会等待这个失败任务并抛出相同异常。虽然这能避免重复发起无效请求，但如果API很快恢复，用户要等5秒才能重试，可能不符合业务预期。
3. CancellationToken的局限性：首次请求传入的ct会绑定到缓存的任务上，但后续请求的ct无法影响这个任务的执行。比如后续请求的ct被取消，只会中断自身的等待，不会终止正在进行的API调用。如果需要API调用响应后续请求的取消信号，当前逻辑无法满足。
4. 锁内校验逻辑不完善：锁内先判断_config（或_serverConfig）是否存在，再设置缓存任务。但如果缓存任务因过期被移除，而_serverConfig还存在，这时候应该直接返回已有配置，而非重新发起API调用，当前逻辑没覆盖这种场景。

优化建议 #

• 修正变量名不一致的问题，统一使用_serverConfig。
• 针对任务失败的场景调整缓存策略：比如任务失败后立即从缓存中移除，或者设置极短的过期时间（如1秒），让后续请求能更快重试；任务成功则保留5秒缓存。
• 锁内先检查缓存是否存在任务，再判断_serverConfig是否有效，避免缓存过期后重复发起请求。
• 若需要让API调用响应后续请求的取消信号，可以考虑合并多个CancellationToken，但实现复杂度较高，需根据业务需求权衡是否必要。

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