.NET8迁移后Azure应用出现StackExchange.Redis EXISTS超时异常求助

核心问题定位：客户端线程池阻塞 #

从错误日志和Redis服务端监控可以明确：Redis服务端完全正常（负载<10%、内存占用极低、slowlog最大耗时仅30ms），所有超时均由Azure App Service侧的资源瓶颈导致，关键线索在日志的线程池指标：

WORKER: (Busy=37,Free=32730,Min=2,Max=32767), 
POOL: (Threads=37,QueuedItems=64,CompletedItems=315273,Timers=29)

• WORKER线程最小阈值（Min=2）设置过低，.NET线程池默认采用懒加载策略，当需要的线程数超过Min值时，新线程每500ms才会创建一个，远跟不上业务需求，导致Redis同步调用因等待线程资源而超时。
• 迁移到.NET8后，线程池默认配置与旧版本（如.NET6）存在差异，加上App Service的默认资源限制，进一步放大了这个问题。

其他诱因 #

1. 同步调用加剧线程消耗
   错误显示调用的是ConnectionMultiplexer.ExecuteSyncImpl——同步Redis操作会持续占用WORKER线程直到响应返回，哪怕是EXISTS这类轻量命令，也会因线程池排队出现超时。

2. StackExchange.Redis版本兼容性
   当前使用的2.8.0.27420版本发布于2022年，未针对.NET8的线程池优化做适配，可能存在潜在的异步IO、连接池管理问题。

排查与修复步骤 #

1. 调整线程池最小线程数 #

• 代码层面：在应用启动时（Program.cs）手动设置线程池阈值，数值根据App Service实例规格调整（B1实例建议50-100，B2/B3实例建议100-200）：

  ThreadPool.SetMinThreads(workerThreads: 100, completionPortThreads: 100);
  

• 环境变量层面：在App Service的「应用设置」中添加：
  • DOTNET_THREADPOOL_MIN_WORKER_THREADS：设置为100
  • DOTNET_THREADPOOL_MIN_IOCP_THREADS：设置为100

2. 替换同步调用为异步调用 #

将所有Redis同步操作（如ExecuteSync、Exists）替换为异步版本（ExecuteAsync、ExistsAsync），异步调用不会占用WORKER线程，能彻底解决线程池阻塞问题。

3. 升级StackExchange.Redis版本 #

升级至最新兼容.NET8的稳定版，修复旧版本与.NET8的兼容性问题，同时获得连接池、线程管理等方面的优化。

4. 优化App Service资源配置 #

• 检查实例CPU/内存使用率，若CPU持续超过70%，升级实例规格（如从B1到B2）；
• 开启「Always On」配置，避免应用因 idle 被回收导致连接池重建；
• 确认WEBSITE_LOAD_BALANCER_MODE设置为WeightedRoundRobin，避免请求分配不均导致单实例压力过大。

5. 验证Redis连接配置 #

• 确保ConnectionMultiplexer全局单例，避免频繁创建新连接；
• 调整连接字符串的超时配置，如syncTimeout=10000（按需调整，但核心还是解决线程池问题）。

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