redis-cli info可以查看 Redis 缓存命中率，但不是直接显示“命中率%”，而是通过keyspace_hits和keyspace_misses两个计数器计算得出。
一、关键指标说明
运行以下命令：
redis-cli info Stats你会看到类似输出：
# Stats keyspace_hits:12345678 keyspace_misses:987654 ...keyspace_hits：命中缓存的请求数（GET 成功找到 key）；keyspace_misses：未命中缓存的请求数（GET 未找到 key）；
⚠️ 注意：
- 这两个指标只统计
GET、EXISTS等读操作；- 写操作（如
SET） 不计入。
二、计算缓存命中率
公式：
命中率 = keyspace_hits / (keyspace_hits + keyspace_misses)✅ 示例：
keyspace_hits = 9000keyspace_misses = 1000- 命中率 = 9000 / (9000 + 1000) = 90%
🔧 一行命令计算（Linux/macOS）：
redis-cli info Stats|awk-F:' /keyspace_hits/ { hits=$2 } /keyspace_misses/ { misses=$2 } END { if (hits+misses > 0) printf "命中率: %.2f%%\n", hits/(hits+misses)*100; else print "无读请求" }'输出：
命中率: 90.00%三、工程实践：命中率监控阈值
| 命中率 | 状态 | 建议 |
|---|---|---|
| ≥ 95% | ✅ 健康 | 无需干预 |
| 90% – 95% | ⚠️ 警告 | 检查热点 key 是否过期过快 |
| < 90% | ❌ 危险 | 可能存在缓存穿透/设计缺陷 |
💡高并发系统通常要求 ≥ 99%（如电商商品缓存）。
四、高危误区
🚫 误区 1：“info默认输出包含命中率”
- 真相：
redis-cli info输出所有 section，需关注# Stats部分；- 直接
info可能因输出太长漏看； - 推荐
redis-cli info Stats精准获取。
🚫 误区 2：“命中率低 = Redis 配置问题”
- 真相：
- 根本原因通常在应用层：
- 缓存 key 设计不合理；
- TTL 过短；
- 存在大量随机查询（如
user:timestamp）；
- 应先分析业务逻辑，再调 Redis。
- 根本原因通常在应用层：
🚫 误区 3：“命中率 100% 最好”
- 真相：
- 100% 可能因无缓存未命中请求（如只读热点数据）；
- 但若存在写操作，命中率 < 100% 是正常现象；
- 盲目追求 100% 可能掩盖缓存穿透风险。
五、扩展：监控命中率变化趋势
✅ 用--stat实时监控（每秒刷新）：
redis-cli--stat输出：
------- data ------ --------------------- load -------------------- - child - 9000 (90.00%) 1000 (10.00%) 0.00 0- 第一列：
keyspace_hits（括号内为命中率）； - 第二列：
keyspace_misses（括号内为未命中率）；
✅适合压测时实时观察命中率变化。
六、终极建议：将命中率纳入告警体系
在 Prometheus + Grafana 中：
- 采集指标：
# redis-exporter 暴露的指标redis_keyspace_hits_total redis_keyspace_misses_total - 计算命中率 PromQL：
rate(redis_keyspace_hits_total[5m]) / (rate(redis_keyspace_hits_total[5m]) + rate(redis_keyspace_misses_total[5m])) - 告警规则：
-alert:LowRedisHitRateexpr:redis_hit_rate < 0.95for:5mlabels:severity:warningannotations:summary:"Redis 缓存命中率低于 95%"
✅总结：
redis-cli info Stats提供keyspace_hits和keyspace_misses；- 命中率 = hits / (hits + misses)；
- ≥ 95% 为健康，< 90% 需紧急排查；
- 务必结合业务逻辑分析，而非仅看数字。
