Redis 运维实战指南：常用命令解析与场景化操作
一、核心运维场景与命令速览
| 场景 | 核心命令 | 关键作用 |
|---|---|---|
| 实时监控性能指标 | INFO | 获取内存、CPU、客户端等全量数据 |
| 定位内存消耗大户 | MEMORY USAGE + SCAN | 分析大Key内存占用 |
| 排查慢查询 | SLOWLOG | 发现执行缓慢的操作命令 |
| 客户端连接管理 | CLIENT LIST + CLIENT KILL | 管理异常连接与限制资源占用 |
| 持久化与备份 | BGSAVE + LASTSAVE | 手动触发RDB备份与验证备份时间 |
| 主从复制监控 | ROLE + INFO REPLICATION | 检查主从状态与延迟 |
| 集群节点管理 | CLUSTER NODES + CLUSTER INFO | 查看集群拓扑与健康状态 |
二、关键运维场景与命令详解
场景1：服务器性能突降，如何快速定位问题？
步骤1：查看实时资源消耗**
redis-cli INFO | grep -E "(used_memory|connected_clients|instantaneous_ops_per_sec|total_commands_processed)"
输出示例
used_memory:1024000000 # 已用内存 1GB
connected_clients:250 # 当前连接数 250
instantaneous_ops_per_sec:1200 # 每秒操作数 1200
total_commands_processed:12345678 # 历史总命令数
分析：
若 used_memory 接近 maxmemory，可能触发内存淘汰策略，导致性能下降。
connected_clients 突增可能遇到连接泄漏或恶意攻击。
场景2：排查内存消耗大户
步骤1：扫描大Key（生产环境慎用 KEYS *）
#渐进式扫描所有Key，匹配所有模式
redis-cli --bigkeys --memkeys
输出示例：
[00.00%] Biggest string found so far 'user:1001:profile' with 1024 bytes
[12.34%] Biggest hash found so far 'product:2024' with 15 fields
-------- summary -------
Sampled 1000000 keys in the keyspace!
Total key length 1345678 bytes
Biggest string found 'user:1001:profile' has 1024 bytes
Biggest hash found 'product:2024' has 15 fields
分析：
发现 user:1001:profile 占用 1KB，若大量存在需考虑拆分或压缩。
product:2024 包含15个字段，检查是否存储了冗余数据。
步骤2：精确计算单个Key内存
redis-cli MEMORY USAGE user:1001:profile
输出：
(integer) 1024 # 占用1024字节
场景3：分析慢查询日志
步骤1：获取最近的慢查询记录
redis-cli SLOWLOG GET 5 # 查看最近5条慢查询
输出示例：
1) 1) (integer) 14 # 日志ID
2) (integer) 1717220000 # 时间戳
3) (integer) 50000 # 执行耗时（微秒，即50毫秒）
4) 1) "KEYS" # 命令
2) "user:*:orders"
5) "127.0.0.1:12345" # 客户端地址
6) "redis-om-0.4.0" # 客户端名称
分析：
KEYS user:*:orders 执行耗时50ms，若频繁出现需改用 SCAN 分页查询。
通过客户端名称定位到使用了redis-om库，检查代码是否存在不合理查询。
场景4：管理异常客户端连接
步骤1：列出所有客户端连接
redis-cli CLIENT LIST
输出示例：
id=5 addr=127.0.0.1:12345 fd=8 name=redis-om-0.4.0 age=600 idle=600 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=20480 argv-mem=10 obl=0 oll=0 omem=0 tot-mem=22312 events=r cmd=client user=default
id=6 addr=192.168.1.100:54321 fd=9 name= age=0 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 argv-mem=0 obl=0 oll=0 omem=0 tot-mem=20496 events=r cmd=ping user=default
关键字段解析：
idle=600：连接空闲600秒，可能为僵尸连接。
cmd=ping：客户端频繁发送心跳，检查是否合理。
步骤2：终止指定客户端连接
redis-cli CLIENT KILL ADDR 192.168.1.100:54321
输出：
OK # 成功终止
场景5：手动触发RDB持久化备份
步骤1：异步生成RDB快照
redis-cli BGSAVE
输出：
Background saving started # 后台保存已启动
步骤2：验证最近备份时间
redis-cli LASTSAVE
输出：
(integer) 1717220000 # 返回Unix时间戳，转换为可读时间：
date -d @1717220000
2024-07-01 14:53:20
场景6：主从复制状态监控
步骤1：查看主从角色与状态
redis-cli ROLE
主节点输出：
1) "master" # 当前角色为主
2) (integer) 12345 # 当前复制偏移量
3) 1) 1) "192.168.1.101" # 从节点IP
2) "6379" # 从节点端口
3) "12340" # 从节点复制偏移量
步骤2：获取详细复制信息
redis-cli INFO REPLICATION
输出关键字段：
role:master
connected_slaves:1
slave0:ip=192.168.1.101,port=6379,state=online,offset=12345,lag=0
master_replid:a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6
分析：
lag=0 表示从节点实时同步，若 lag>10 需检查网络或从节点负载。
master_replid 为主节点唯一标识，故障切换时需对比。
三、自动化运维技巧
- 指标监控脚本
#!/bin/bash
MEMORY=$(redis-cli INFO MEMORY | grep used_memory_human)
CONNS=$(redis-cli INFO CLIENTS | grep connected_clients)
echo "[$(date)] Memory: $MEMORY, Connections: $CONNS" >> /var/log/redis_monitor.log
2 慢查询定时归档
# 每天凌晨归档慢查询日志
SLOWLOG_COUNT=$(redis-cli SLOWLOG LEN)
redis-cli SLOWLOG GET $SLOWLOG_COUNT > /backup/redis_slowlog_$(date +%F).log
redis-cli SLOWLOG RESET
最后叮嘱：
- 生产环境避免使用 KEYS *、FLUSHALL 等危险命令。
- 定期使用 CONFIG REWRITE 持久化运行中的配置修改。
互动话题：
你在Redis运维中遇到过哪些“惊心动魄”的故障？欢迎留言分享你的解决经验！ 🚀
附录：本文命令测试环境：Redis 7.0，Linux 5.4。部分命令在旧版本中可能略有差异。
