Azure Cache for Redis读取峰值超时问题排查优化求助

1 客户端线程池配置优先排查 #

你给出的WORKER线程初始Min值为2，峰值时Busy冲到250，属于典型的线程池饥饿问题。.NET线程池默认在现有线程不足时，每秒仅新增2个工作线程，峰值请求上来时线程供给速度远跟不上请求增长速度，请求会在客户端排队最终触发超时。

• 调整WORKER和IOCP线程的最小阈值，建议将Min值设置为略高于峰值Busy数值的水平，例如设置为300，可在应用启动时执行以下代码：

ThreadPool.SetMinThreads(300, 300);

• 排查客户端代码中是否存在Wait()、Result()这类同步阻塞等待异步Redis操作的逻辑，这类调用会额外占用工作线程，加重线程池压力，需全部替换为await异步调用。

2 单键返回值大小优化 #

当前单键值在100-400KB区间，已经超过Redis单请求最优阈值（行业通用建议单值不超过10KB），大值传输会占用单连接的带宽时长，单个请求处理周期被拉长，峰值下更容易出现请求堆积。

• 对大于100KB的缓存值做拆分，可按业务维度拆分为多个子键分别读取，或者启用数据压缩逻辑，比如用gzip压缩缓存值后再存储，通常可降低70%以上的体积，大幅减少传输耗时。
• 关闭客户端不必要的结果缓冲逻辑，降低客户端内存拷贝开销。

3 客户端连接池配置优化 #

服务端负载仅为4%、内存占用仅350MB，说明瓶颈完全在客户端侧，每分钟3000次的请求量级本身很低，不会触发服务端限流。

• 检查Redis客户端是否为单例复用，比如StackExchange.Redis的ConnectionMultiplexer实例要全局单例，不要每次请求都新建连接，新建连接的开销会在峰值时被放大。
• 调整连接池最大连接数，默认配置的连接数可能不足以支撑峰值并发请求，建议调整到50-100区间。
• 检查超时参数配置，默认syncTimeout、asyncTimeout多为1s，大值传输场景下可适当调整到3-5s，避免误判超时。

4 峰值请求削峰处理 #

• 排查是否存在缓存击穿场景，比如热点key同时过期，导致大量请求同时访问Redis，这类情况可给热点key的过期时间增加随机偏移量，避免批量同时过期。
• 新增应用本地二级缓存，比如用内存缓存给热点key设置10s左右的短过期缓存，大幅降低Redis的访问量，从源头减少请求压力。

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