Azure Function中StackExchange.Redis.RedisTimeoutException问题求助

错误日志 #

执行函数时出现异常：****Timeout performing SETEX (10000ms), next: GET *****, inst: 140, qu: 0, qs: 0, aw: False, bw: SpinningDown, rs: ReadAsync, ws: Idle, in: 2939, serverEndpoint: *****:6380, mc: 1/1/0, mgr: 10 of 10 available, clientName: 4ad57eb720e9(SE.Redis-v2.6.66.47313), IOCP: (Busy=0,Free=1000,Min=6,Max=1000), WORKER: (Busy=69,Free=32698,Min=6,Max=32767), POOL: (Threads=69,QueuedItems=54,CompletedItems=8674751), v: 2.6.66.47313

可能诱因 #

• 工作线程池资源耗尽：日志显示WORKER线程繁忙数达69，线程池队列等待任务54，说明函数应用的工作线程被大量同步阻塞操作（如密集计算、同步IO调用）占用，导致Redis客户端的异步响应回调无法及时处理，最终触发超时。Azure Function的线程池容量受并发请求、CPU负载限制，高并发场景下易出现此类资源争用。
• Redis服务器端瞬时高负载：尽管客户端队列等待数（qs）为0，但Redis实例可能存在瞬时压力峰值：比如大key的读写操作占用大量CPU/内存、RDB/AOF持久化期间的性能波动、主从同步的带宽开销，这些情况会导致服务器处理请求延迟增加，超出客户端10秒超时阈值。
• Azure内部网络波动：若函数应用与Redis实例不在同一Azure区域，跨区域网络的瞬时延迟抖动、VNet peering临时故障、NSG/防火墙规则变更导致的流量拦截延迟，都可能使SETEX请求无法在超时窗口内完成。
• StackExchange.Redis客户端问题：当前使用的v2.6.66版本存在已知的连接池调度、线程处理bug；此外，若客户端超时配置（默认10秒）未根据实际场景调整，或连接池大小设置不合理，高并发下会加剧超时概率。
• Azure Function资源争用：如果函数运行在消耗计划，冷启动阶段资源分配过程中，大量并发请求会和Redis客户端竞争CPU、内存资源；同一App Service Plan下的其他函数高负载运行，也会抢占资源，影响Redis请求的处理速度。

内容的提问来源于stack exchange，提问作者Yonatan Levin