c# – Redis缓存在同步请求中获得超时,并且仅在异步方法中使用异步请求缓慢响应

首先,我使用Azure Redis缓存服务和StackExchange.Redis(1.0.371)客户端与我的MVC 5和Web Api 2应用程序.我的行为非常有趣.当我使用异步转换同步调用时,使用同步请求获得超时并且响应速度慢.让我给你举个例子.这是我的RedisCacheService,

public class RedisCacheService : ICacheService
{
    private readonly IDatabase _cache;
    private static readonly ConnectionMultiplexer ConnectionMultiplexer;

    static RedisCacheService()
    {

        var connection = ConfigurationManager.AppSettings["RedisConnection"];
        ConnectionMultiplexer = ConnectionMultiplexer.Connect(connection);
    }

    public RedisCacheService(ISettings settings)
    {            
        _cache = ConnectionMultiplexer.GetDatabase();
    }

    public bool Exists(string key)
    {
        return _cache.KeyExists(key);
    }

    public Task<bool> ExistsAsync(string key)
    {
        return _cache.KeyExistsAsync(key);
    }


    public void Save(string key, string value, int timeOutInMinutes)
    {
        var ts = TimeSpan.FromMinutes(timeOutInMinutes);
        _cache.StringSet(key, value, ts);
    }

    public Task SaveAsync(string key, string value, int timeOutInMinutes)
    {
        var ts = TimeSpan.FromMinutes(timeOutInMinutes);
        return _cache.StringSetAsync(key, value, ts);
    }

    public string Get(string key)
    {
        return _cache.StringGet(key);
    }

    public async Task<string> GetAsync(string key)
    {
        string result = null;
        var val = await _cache.StringGetAsync(key);
        if(val.HasValue) 
        {
            result = val;
        }
        return result;
    }

    ......................................................................
}

这是我调用缓存的方法.

public async Task<IList<XX>> GetXXXXX(XXXX)
{
    var key = string.Format("{0}/XX{1}_{2}", XXXX, XX, XX);
    var xxx = _cacheService.Get(key);
    if (xxx != null)
    {
        return JsonConvert.DeserializeObject<IList<XX>>(xxx);
    }
    var x = await _repository.GetXXXXX(XXXXX);
    var contents = JsonConvert.SerializeObject(x);
    _cacheService.Save(key, JsonConvert.SerializeObject(x));
    return x;
}

上面的方法总是给我,

System.TimeoutException
Timeout performing GET XXX, inst: 0, mgr: Inactive, queue: 3, qu=2, qs=1, qc=0, wr=1/1, in=0/0

要么

System.TimeoutException
Timeout performing SETEX XXX, inst: 0, mgr: Inactive, queue: 2, qu=1, qs=1, qc=0, wr=1/1, in=0/0

让它改为异步,

public async Task<IList<XX>> GetXXXXX(XXXX)
{
    var key = string.Format("{0}/XX{1}_{2}", XXXX, XX, XX);
    var xxx = await _cacheService.GetAsync(key);
    if (xxx != null)
    {
        return JsonConvert.DeserializeObject<IList<XX>>(xxx);
    }
    var x = await _repository.GetXXXXX(XXXXX);
    var contents = JsonConvert.SerializeObject(x);
    await  _cacheService.SaveAsync(key, JsonConvert.SerializeObject(x));
    return x;
}

上述方法有效但至少需要5-10秒.如果没有可用的缓存,则表示10秒;如果缓存可用,则表示5秒.

现在让我的方法完全同步,

public async Task<IList<XX>> GetXXXXX(XXXX)
{
    var key = string.Format("{0}/XX{1}_{2}", XXXX, XX, XX);
    var xxx = _cacheService.Get(key);
    if (xxx != null)
    {
        return Task.FromResult(JsonConvert.DeserializeObject<IList<XX>>(xxx));
    }
    //var x = await _repository.GetXXXXX(XXXXX);
    var x = (IList<XX>)new List<XX>();
    var contents = JsonConvert.SerializeObject(x);
    _cacheService.Save(key, JsonConvert.SerializeObject(x));
    return Task.FromResult(x);
}

请注意调用存储库方法的注释.上述方法立即起作用,意味着我在不到1秒的时间内得到结果.显然Azure或StackExcahge.Redis客户端有问题.

更新：我的上一个方法(异步)也像魅力(快速,没有错误),

public async Task<IList<XX>> GetXXXXX(XXXX)
{
    var key = string.Format("{0}/XX{1}_{2}", XXXX, XX, XX);
    var xxx = await _cacheService.GetAsync(key);
    if (xxx != null)
    {
        return JsonConvert.DeserializeObject<IList<XX>>(xxx);
    }
    //var x = await _repository.GetXXXXX(XXXXX);
    var x = (IList<XX>)new List<XX>();
    var contents = JsonConvert.SerializeObject(x);
    await _cacheService.SaveAsync(key, JsonConvert.SerializeObject(x));
    return x;
}

请注意,我仍然评论了存储库代码.

解决方法:

看起来Azure中的这些超时可能是open issue ..您是否尝试过针对本地(非Azure)服务器的此代码？你得到相同的结果吗？

标签：c,asynchronous,asp-net-mvc,azure,stackexchange-redis
来源： https://codeday.me/bug/20190708/1402416.html