Azure上Node.js+Redis应用缓存请求延迟过高的性能优化咨询

以下是针对该场景的实测有效优化方向：

• 优先排查自动流水线配置
  当前开启了全局enableAutoPipelining: true，该功能会将短时间窗口内的多个Redis请求攒批后一次性发送给服务端，从而提升高并发下的吞吐量，但低峰或流量波动场景下，攒批等待的延迟会直接体现在单请求的耗时上，同一时间批量出现几百毫秒慢请求的特征完全匹配该问题。可以先临时关闭该配置测试，若慢请求消失即可确认根因：如果不需要极致的吞吐量建议直接关闭该配置，若需要保留批量优化收益，可改为手动对明确的批量操作调用pipeline方法，不要开全局自动流水线。
• 优化TLS与连接保活配置
  当前的tls配置为空对象，Azure Redis默认强制使用TLS 1.2及以上版本，未配置TLS会话复用、保活策略会导致频繁的TLS握手开销，或者连接被中间设备断开后重连产生延迟。建议修改客户端配置如下：

const client = new Redis({
  port,
  host: server,
  password: auth,
  maxRetriesPerRequest: 2,
  tls: {
    minVersion: 'TLSv1.2',
    keepAlive: true,
    rejectUnauthorized: true
  },
  enableAutoPipelining: false, // 先关闭测试
  enableOfflineQueue: true,
  connectTimeout: 30000,
  keepAlive: 30000 // 新增TCP保活配置
});

• 解决单连接瓶颈问题
  Node.js单线程环境下，单个Redis客户端对应的单TCP连接吞吐量上限通常在1万QPS左右，若单进程Redis请求量超过该阈值，请求会在客户端排队导致耗时升高。可以引入连接池方案，用generic-pool封装2~4个Redis客户端实例，分摊请求压力，避免单连接排队。
• 排查离线队列与重连逻辑
  已开启enableOfflineQueue: true，当Redis连接临时断开时，所有新请求会堆积在客户端离线队列中，等连接恢复后一次性执行，此时老请求的耗时会包含等待连接恢复的时间。建议添加客户端连接事件日志，监听error、reconnecting事件，确认慢请求出现时是否伴随连接重连动作，若该场景频繁出现，可考虑关闭离线队列，请求失败直接触发上层降级逻辑，避免长尾延迟。
• 排查网络与Azure服务配置
  确认App Service与Redis实例部署在同一区域的同一VNet内，关闭Redis的公网访问权限，走内网通信避免公网网络波动影响。若使用的是共享型Redis实例，即使面板显示负载正常，也可能存在租户间的资源抢占，可临时升级到专属实例测试是否有改善。
• 排除Node.js事件循环阻塞干扰
  统计的端到端请求耗时包含了Node.js事件循环调度的时间，若同一时间进程内有大量CPU密集操作（如大体积JSON序列化/反序列化、复杂计算），会导致Redis回调被延迟执行，看起来就像Redis调用慢。可添加事件循环延迟监控，确认慢请求出现时是否伴随事件循环延迟升高。

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