关键要从日志错误码定位根因：连接类（如timeout）、认证类（noauth）、命令类（wrongtype）、资源类（oom）等错误码直接指向服务不可达、密码错误、类型误用或内存满等问题，需结合ttl与命令结构化分析。
排查缓存失效问题时，光看“没命中”不够，关键要从日志里揪出错误码——它直接指向底层失败原因。错误码不是噪音，是诊断入口。
错误码集中采集与归类
先确保缓存客户端（如 Redis、Memcached 或 Spring Cache）开启了详细错误日志。重点捕获以下几类错误码：
- 连接类：`ERR_CONNECTION_REFUSED`、`TimeoutException`、`Connection reset by peer` —— 指向服务不可达或网络抖动
- 认证类：`NOAUTH`（Redis）、`ERROR invalid password` —— 密码错、ACL 权限不足或未启用认证
- 命令类：`WRONGTYPE`（对 String 执行 HGET）、`BUSYKEY`（被 Lua 脚本锁住）—— key 类型误用或并发冲突
- 资源类：`OOM command not allowed when used memory > 'maxmemory'`、`MISCONF Redis is configured to save RDB snapshots` —— 内存满、持久化失败导致拒绝写入
日志中错误码的统计分析方法
不要手动翻日志。用结构化方式提取并聚合：
- 用 grep + awk 快速统计（适用于临时排查）：
grep -oE "(ERR_[A-Z_]+|NOAUTH|WRONGTYPE|OOM|Timeout)" app.log | sort | uniq -c | sort -nr - 接入 ELK 或 Loki：给日志打上
cache_error_code字段，用 Kibana 做 TopN 错误码看板，叠加时间趋势图 - 监控告警联动：当 `WRONGTYPE` 出现频次 5 分钟内超 10 次，触发告警——大概率是代码中 key 复用或类型覆盖
错误码与典型场景映射表
看到错误码，马上能定位到根因：
| 错误码 | 高频场景 | 验证方式 |
|---|---|---|
| NOAUTH | PHP/Python 客户端未配置密码；Spring Boot 的 spring.redis.password 配置缺失或为空字符串 |
用 redis-cli -h x.x.x.x -p 6379 AUTH yourpass 手动测试 |
| WRONGTYPE | 同一 key 先存为 String，后被 Hash 命令覆盖；或不同模块混用 key 前缀但未隔离数据结构 |
redis-cli TYPE your:key + redis-cli GET your:key 或 HGETALL your:key 对比 |
| OOM | 缓存写入激增且无淘汰策略；或 maxmemory-policy 设为 noeviction 导致写失败 |
redis-cli INFO memory | grep -E "(used_memory|maxmemory|maxmemory_policy)" |
结合 TTL 和错误码做交叉分析
单独看错误码可能漏掉上下文。例如大量 `NOAUTH` 可能只是配置问题，但如果同时发现 `TTL` 返回 `-2`（key 不存在）或 `-1`（无过期），说明不仅连不上，还可能 key 根本没写进去。建议在日志中统一记录三元组：[key] [cmd] [error_code] [ttl]
这样一条日志就能还原完整失败链路。
