StackExchange.Redis 在 Azure Redis 重认证时随机超时问题解析

问题背景

在使用 Azure Redis 缓存服务时，开发团队遇到了一个棘手的随机超时问题。具体表现为应用程序在与 Azure Redis 服务进行重认证时出现连接超时，错误信息显示消息在积压队列中等待发送时超时，因为没有任何连接变为可用状态。这个问题会持续存在，直到重启应用服务后才能暂时解决。

错误现象分析

从错误日志中可以提取出几个关键信息点：

1. 连接重认证失败，提示连接超时（60000ms）
2. 工作线程繁忙状态显示为 Busy=84
3. 连接管理器显示 9/10 可用
4. 底层使用的是 StackExchange.Redis 2.7.4 版本

根本原因

经过深入排查，发现问题源于服务生命周期管理不当。Redis 连接服务本应设计为单例模式，但在某次代码变更中被错误地配置为了作用域(Scoped)服务。这种配置导致：

1. 每个请求都会创建新的 Redis 连接
2. 连接数迅速达到 Azure Redis 的最大连接限制（2000个）
3. 连接创建/关闭的高频率操作导致服务器负载达到100%
4. 重认证时无法获取可用连接

解决方案

正确的服务注册方式

将 Redis 服务明确注册为单例模式：

services.AddSingleton<RedisService>();

连接管理最佳实践

1. 复用长生命周期连接：ConnectionMultiplexer 设计为在应用程序生命周期内长期存在
2. 合理配置超时参数：根据业务需求设置适当的超时时间
3. 异常处理：完善连接建立过程中的异常捕获和处理逻辑

连接创建示例代码

private async Task<ConnectionMultiplexer> CreateConnection(string option)
{
    if (_connectionMultiplexer == null)
    {
        var configurationOptions = await ConfigurationOptions
            .Parse($"{_connectionString}:6380")
            .ConfigureForAzureWithTokenCredentialAsync(_principalId, new DefaultAzureCredential());
        
        configurationOptions.AbortOnConnectFail = false;
        configurationOptions.AsyncTimeout = 60000;
        configurationOptions.SyncTimeout = 60000;
        
        _connectionMultiplexer = await ConnectionMultiplexer.ConnectAsync(configurationOptions);
    }
    return _connectionMultiplexer;
}

性能监控建议

1. 监控连接数：密切关注 Azure Redis 的"Connected Clients"指标
2. 观察服务器负载：定期检查 Redis 服务器负载情况
3. 设置警报：为关键指标配置适当的警报阈值

总结

在使用 StackExchange.Redis 连接 Azure Redis 服务时，正确的连接生命周期管理至关重要。ConnectionMultiplexer 应该作为单例在整个应用生命周期内共享使用，而非为每个请求创建新实例。通过遵循这一原则，可以避免连接泄漏、减少连接创建/关闭的频率，从而保证 Redis 服务的稳定性和性能。

对于生产环境应用，建议定期审查服务注册方式和连接管理策略，确保它们符合最佳实践要求。同时，建立完善的监控机制，以便及时发现和解决潜在的性能问题。