故障案例：模型推理响应慢，排查 Redis 缓存集群问题

核心提要：在 AI 模型推理服务中，Redis 缓存常被用于存储热点输入数据、模型中间结果、特征向量等，以降低重复计算和数据库查询延迟。本案例基于金融智能风控模型推理场景，针对"推理响应延迟飙升"故障，从业务现象切入，逐步定位到 Redis 缓存集群的核心问题，完整演示"现象确认→指标监控→日志分析→根因定位→解决方案→验证复盘"的全流程，为同类缓存相关的推理延迟问题提供可复用的排查思路。

一、故障背景与现象

1. 业务场景

某银行智能风控模型推理服务，部署在 K8s 集群，采用"GPU 推理 + Redis 缓存"架构支撑信贷审批核心业务：

核心流程：用户提交信贷申请后，推理服务先从 Redis 缓存集群查询用户历史信贷特征向量（热点数据，约 80% 申请用户存在历史记录），缓存命中则直接输入 GPU 推理模型计算风险评分；缓存未命中时，从 MySQL 特征库查询数据，存入 Redis 后再执行推理；
Redis 集群配置：3 主 3 从架构，采用一致性哈希分片，每个主节点负责 1/3 槽位；特征向量以字符串类型存储，key 格式为"feature:user_id"，缓存过期时间 1 小时，避免特征数据过时；
业务 SLA 要求：单用户信贷推理响应延迟 ≤ 500ms，服务可用性 ≥ 99.99%，缓存命中率 ≥ 85%。

2. 故障现象

2026年01月11日14:00（信贷申请高峰时段），运维团队接业务侧投诉，同步收到监控告警，核心现象如下：

业务侧：信贷申请页面提交后加载缓慢，部分用户反馈"等待 3-5 秒才显示审批结果"，少量用户遇到"申请超时"提示，超时率约 3%；
监控侧：Prometheus 监控面板显示，推理服务平均响应延迟从正常的 320ms 飙升至 2800ms，其中"Redis 缓存查询"环节耗时占比达 85%；缓存命中率从 92% 骤降至 45%，未命中请求需额外查询 MySQL，进一步拉长延迟；
服务侧：推理服务 Pod 无重启、无报错日志，GPU 使用率稳定在 35%（正常负载区间），CPU/内存资源使用率均低于 50%；Redis 集群 6 个节点均处于"Running"状态，无节点宕机或重启记录。

二、故障排查流程（从现象到根因）

步骤 1：确认故障核心环节------锁定缓存查询

复制代码

# 推理服务日志示例（拆分后）
2026-01-11 14:30:02.123 - [INFO] - 数据预处理耗时：35ms
2026-01-11 14:30:04.567 - [INFO] - Redis 缓存查询耗时：2412ms  # 核心延迟环节
2026-01-11 14:30:04.689 - [INFO] - 模型推理耗时：102ms
2026-01-11 14:30:04.701 - [INFO] - 后处理耗时：12ms
2026-01-11 14:30:04.702 - [INFO] - 全链路总耗时：2661ms

步骤 2：排查 Redis 集群基础状态------排除节点宕机与资源不足

复制代码

# 进入 Redis 集群客户端（容器化部署）
kubectl exec -it redis-cluster-0 -n ai-service -- redis-cli -c -h redis-cluster-0.redis-cluster

# 查看集群状态
cluster info
# 输出关键信息：
# cluster_state:ok  # 集群状态正常
# cluster_slots_assigned:16384  # 所有槽位已分配
# cluster_nodes:6  # 6 个节点正常（3主3从）

# 查看各节点状态
cluster nodes
# 输出显示所有节点均为"connected"状态，无"fail"节点

# 查看 Redis 节点 Pod 资源使用
kubectl top pods -n ai-service | grep redis-cluster
# 输出示例：
# redis-cluster-0   180m/1Gi   320Mi/2Gi  # CPU 使用率 18%，内存使用率 16%，资源充足
# redis-cluster-1   165m/1Gi   305Mi/2Gi
# ... 其他节点资源使用均正常

# 从推理服务 Pod 测试 Redis 集群网络连通性
kubectl exec -it mnist-infer-deploy-7f98d76c89-2xq87 -n ai-service -- ping redis-cluster:6379 -c 5
# 输出显示网络延迟 < 1ms，无丢包

# 测试 Redis 命令响应时间
kubectl exec -it mnist-infer-deploy-7f98d76c89-2xq87 -n ai-service -- redis-cli -h redis-cluster -p 6379 ping
# 输出：PONG（响应时间 280ms，正常应 < 10ms）

步骤 3：深入排查 Redis 集群核心问题------定位槽位迁移与主从同步

复制代码

# 查看 Redis 集群槽位迁移状态（在 Redis 客户端执行）
cluster slots
# 输出显示：存在 2 个槽位（5461-5462）处于"migrating"状态，正在从节点 redis-cluster-0 迁移到 redis-cluster-3

# 查看迁移进度
info migration
# 输出：migrate_cursor:123456，说明迁移正在进行，未完成

# 查看主节点同步状态（在主节点客户端执行）
info replication
# 输出关键信息：
# master_repl_offset:12345678
# slave0:ip=10.0.0.11,port=6379,state=online,offset=12345678,lag=0  # 从节点同步无延迟
# 所有主从节点同步均正常，无延迟

# 查看 Redis 节点键值数量分布
for pod in $(kubectl get pods -n ai-service -l app=redis-cluster -o jsonpath="{.items[*].metadata.name}"); do
  echo "Pod: $pod，键值数量：$(kubectl exec -it $pod -n ai-service -- redis-cli dbsize)"
done
# 输出显示：redis-cluster-0 键值数量 12 万，其他节点均为 8-9 万，分布较均匀

# 排查热点 Key（使用 Redis 自带命令）
kubectl exec -it redis-cluster-0 -n ai-service -- redis-cli info stats | grep keyspace_hits
kubectl exec -it redis-cluster-0 -n ai-service -- redis-cli info stats | grep keyspace_misses
# 结合监控发现：无明显热点 Key，缓存命中率下降是因槽位迁移导致部分键暂时无法命中

步骤 4：验证根因------暂停槽位迁移后观察延迟变化

复制代码

# 在 Redis 迁移源节点（redis-cluster-0）执行，暂停槽位迁移
cluster setslot 5461 stable
cluster setslot 5462 stable

# 再次查看迁移状态
cluster slots
# 输出显示槽位状态变为"stable"，迁移暂停

# 观察推理服务延迟
# 1. 查看 Prometheus 监控：缓存查询延迟从 2400ms 快速下降至 180ms，缓存命中率回升至 88%；
# 2. 查看推理服务日志：单条请求缓存查询耗时稳定在 150-200ms，全链路延迟降至 420ms（符合业务要求）。

三、解决方案与实施

1. 紧急解决方案：暂停迁移，保障业务稳定

复制代码

# 1. 暂停所有正在迁移的槽位（在各迁移源节点执行）
cluster setslot 5461 stable
cluster setslot 5462 stable

# 2. 验证槽位状态，确保所有槽位稳定
cluster slots | grep -i migrating  # 无输出说明无迁移中的槽位

# 3. 清理迁移残留状态（若有）
cluster reset  # 仅在非生产环境或确认无影响时执行，生产环境建议咨询 Redis 运维专家

2. 根本解决方案：优化槽位迁移策略，避开业务高峰

复制代码

# 调整迁移批次大小（默认 10 个键/批次，改为 5 个）
redis-cli config set cluster-migration-batch-size 5

# 调整迁移超时时间（避免迁移超时重试）
redis-cli config set cluster-migration-timeout 60000

3. 长效优化：缓存架构升级，提升容错能力

复制代码

# 推理服务 Redis 查询超时设置示例（Python）
import redis
from redis.exceptions import TimeoutError

# 初始化 Redis 客户端，设置超时时间
redis_client = redis.Redis(
    host="redis-cluster",
    port=6379,
    socket_timeout=0.3,  # 300ms 超时
    decode_responses=True
)

def get_feature_from_redis(user_id):
    try:
        # 缓存查询，超时抛出 TimeoutError
        return redis_client.get(f"feature:{user_id}")
    except TimeoutError:
        # 超时处理：记录告警，直接查询数据库
        logger.warning(f"Redis query timeout for user {user_id}")
        return get_feature_from_mysql(user_id)

四、故障验证与复盘

1. 故障验证

针对不同阶段的解决方案，分三次验证效果，确保故障彻底解决且无次生问题：

紧急修复验证（暂停槽位迁移后）：观察 30 分钟内监控数据，推理服务平均响应延迟从 2800ms 降至 420ms，符合 ≤ 500ms 的 SLA 要求；Redis 缓存查询延迟稳定在 150-200ms，缓存命中率回升至 88%；业务侧无新的超时投诉，超时率恢复至 0%；
根本方案验证（低峰期迁移后）：选择 2026年01月12日02:00-03:00（业务低峰，请求量仅为高峰的 5%）完成槽位迁移，迁移过程中推理服务平均延迟稳定在 310-330ms，缓存命中率 93%，无业务感知；迁移完成后持续观察 24 小时，各项指标均正常；
长效优化验证（架构升级后）：模拟 Redis 集群槽位迁移、单个节点故障两种异常场景，本地缓存均能正常兜底，推理延迟最高 480ms（未超阈值）；Redis 命令响应延迟 > 100ms 时，Alertmanager 10 秒内触发告警，运维团队及时响应。

2. 故障复盘与经验总结

（1）核心故障原因总结

本次故障的直接原因是 Redis 集群槽位迁移操作在业务高峰时段执行，迁移过程中对 5461-5462 槽位对应的键值查询产生阻塞，导致缓存查询延迟飙升；间接原因是运维规范缺失，未明确缓存集群运维操作的时间窗口，且推理服务与 Redis 对接时无超时兜底机制，导致缓存问题直接传导至业务层。

（2）关键经验教训

运维操作需绑定业务窗口：Redis 集群迁移、扩容、参数调整等影响性能的操作，必须在业务低峰期执行，且执行前需报备业务团队，制定应急预案；
依赖组件需设置容错机制：推理服务对接 Redis、MySQL 等依赖组件时，必须配置超时时间、降级策略（如本地缓存兜底），避免单一组件故障导致整个业务链路不可用；
监控告警需覆盖全链路：除监控推理服务本身指标外，还需细化依赖组件的核心指标（如 Redis 槽位状态、命令响应延迟、主从同步 lag），做到问题早发现、早定位。

（3）后续优化计划

完善运维规范：制定《Redis 集群运维操作手册》，明确低峰期操作窗口（每日 02:00-04:00），要求迁移、扩容等操作需提前 1 天申请，审批通过后方可执行；
优化监控体系：新增 Redis 槽位迁移状态、大 Key 数量、缓存过期率等指标的监控，设置分级告警阈值，提升问题发现效率；
架构持续升级：计划引入 Redis Cluster Proxy 组件，简化客户端对接逻辑，同时实现迁移、故障切换时的透明化，进一步降低对业务的影响。

五、同类问题排查速查表

故障现象	可能原因	排查命令/方法	解决方案
缓存查询延迟高，Redis 节点正常	槽位迁移中、主从同步延迟高	cluster slots、info replication、info migration	暂停迁移（紧急）、低峰期迁移（根本）、优化同步参数
缓存命中率骤降	槽位迁移、缓存过期策略不合理、热点 Key 未缓存	info stats、redis-cli keys * 排查键分布	迁移后预热缓存、调整过期策略、添加热点 Key 专项缓存
Redis 命令响应慢，资源充足	网络拥堵、键值过大、频繁大 Key 操作	ping 测试网络、redis-cli --bigkeys 排查大 Key	优化网络、拆分大 Key、限制大 Key 操作频率
缓存查询超时，影响推理服务	Redis 节点压力大、网络中断、迁移中	top 查看节点资源、ping 测试网络、cluster info	设置查询超时、本地缓存兜底、紧急修复 Redis 集群