Redis 命令与日常运维
排障时先收集状态，再改配置；不要上来就重启或清空数据。密码通过 REDISCLI_AUTH 传递，避免 -a 出现在 shell 历史中。
本章使用上一章保留的实验实例。完成后你会得到一套可复用的日常巡检顺序，并能解释每个指标为什么重要。
export REDISCLI_AUTH='<密码>'
redis-cli --user ops info memory
redis-cli --user ops info stats
redis-cli --user ops info replication
redis-cli --user ops info persistence
1. 先建立一次健康基线
“现在高不高”必须和正常值比较。新实例上线后应记录一份基线：
mkdir -p /tmp/redis-baseline
redis-cli --user ops INFO server > /tmp/redis-baseline/server.txt
redis-cli --user ops INFO clients > /tmp/redis-baseline/clients.txt
redis-cli --user ops INFO memory > /tmp/redis-baseline/memory.txt
redis-cli --user ops INFO stats > /tmp/redis-baseline/stats.txt
redis-cli --user ops INFO persistence > /tmp/redis-baseline/persistence.txt
生产巡检应记录时间、实例地址、角色和版本。不要把包含用户名、地址或业务 key 的完整输出公开上传。
2. INFO 输出怎么读
| 分区 | 先看什么 | 说明 |
|---|---|---|
memory | used_memory、碎片率、maxmemory | 判断是否接近容量边界。 |
stats | ops/sec、hits/misses、evicted_keys | 判断负载、命中率与淘汰。 |
clients | connected_clients、blocked_clients | 连接池或阻塞命令问题。 |
replication | role、link status、offset | 主从是否断链或延迟。 |
persistence | 最近保存状态、AOF rewrite | 判断能否恢复。 |
2.1 手工计算缓存命中率
redis-cli --user ops INFO stats | grep -E 'keyspace_(hits|misses)'
公式为：
命中率 = hits / (hits + misses) × 100%
命中率降低不一定是 Redis 故障，也可能是新业务上线、TTL 变短、缓存 key 设计改变或大量冷数据访问。必须结合请求量和数据库负载判断。
2.2 查看连接来源
redis-cli --user ops CLIENT LIST
redis-cli --user ops CLIENT INFO
重点关注 addr、name、age、idle、cmd 和输出缓冲。应用应执行 CLIENT SETNAME 标识连接池，便于按服务定位连接泄漏。不要看到连接多就直接提高 maxclients；先检查客户端是否每次请求都新建连接。
3. 慢查询和延迟
redis-cli slowlog get 128
redis-cli slowlog len
redis-cli latency latest
redis-cli latency doctor
慢日志记录的是 Redis 内部执行时间，不包括网络排队。看到慢命令后，结合参数大小、调用频率、业务来源和 CPU/I/O 监控判断，不要只靠一次采样下结论。
可以在实验实例设置较低阈值并制造一条慢操作：
# 单位是微秒；1000 表示超过 1 毫秒记录
redis-cli --user ops CONFIG SET slowlog-log-slower-than 1000
redis-cli --user ops CONFIG SET slowlog-max-len 128
# 只在实验实例运行，创建较多 key 后执行 SORT 等操作观察慢日志
for i in $(seq 1 5000); do redis-cli LPUSH lab:slow-list "$RANDOM" >/dev/null; done
redis-cli SORT lab:slow-list LIMIT 0 5000 >/dev/null
redis-cli --user ops SLOWLOG GET 10
实验后恢复阈值或重启加载配置文件，避免临时 CONFIG SET 被误当成永久配置。是否执行 CONFIG REWRITE 必须经过配置管理流程。
4. Key 的安全查看方式
# 禁止生产使用 KEYS *；SCAN 每次只返回一部分结果
redis-cli --scan --pattern 'app:*' --count 1000 | head -n 100
redis-cli TYPE 'app:session:42'
redis-cli TTL 'app:session:42'
redis-cli MEMORY USAGE 'app:session:42'
COUNT 只是提示值，遍历会有重复，不能把 SCAN 当作一致性快照。删除确认无用的大 key 优先 UNLINK key，它会异步回收内存；清理前先产出审计清单。
4.1 找 BigKey 的正确过程
# 会遍历 keyspace，仅在低峰或副本上执行
redis-cli --user ops --bigkeys
# 对候选 key 精确确认类型、长度和内存
redis-cli --user ops TYPE 'candidate:key'
redis-cli --user ops MEMORY USAGE 'candidate:key' SAMPLES 10
redis-cli --user ops LLEN 'candidate:key'
redis-cli --user ops HLEN 'candidate:key'
redis-cli --user ops SCARD 'candidate:key'
redis-cli --user ops ZCARD 'candidate:key'
BigKey 不只指 value 字节大，也包括成员数量巨大。删除百万成员集合即使用 UNLINK，后台释放仍可能带来 CPU 压力，应限速、分批并监控延迟。
5. 在线修改配置的边界
# 先读取并记录旧值
redis-cli --user ops CONFIG GET maxclients
# 实验示例：临时调整，不代表生产推荐值
redis-cli --user ops CONFIG SET maxclients 2000
# 再读取确认
redis-cli --user ops CONFIG GET maxclients
CONFIG SET 立即生效，但重启后可能丢失；CONFIG REWRITE 会修改配置文件。生产应先改配置管理来源，再滚动重启验证，避免运行值和文件值长期漂移。
6. 一份每日巡检顺序
PING与端口连通；INFO server确认版本、运行时间和角色；INFO clients查看连接与阻塞；INFO memory检查上限、碎片和峰值；INFO stats查看 QPS、命中率、淘汰和错误；INFO replication检查复制链路；INFO persistence检查 RDB/AOF；SLOWLOG GET与LATENCY LATEST检查性能异常；- 对比昨天和过去一周基线，而不是只看一次快照。
7. 实验清理
redis-cli --user ops UNLINK lab:slow-list
redis-cli --user ops SLOWLOG RESET
MONITOR 会输出所有命令并可能泄漏数据，且本身有开销；只能短时间、受控使用。CLIENT KILL 先按来源过滤，避免误断业务连接。