Redis 监控运维与内存优化

开发完功能只是开始，生产环境还要回答三个问题：现在状态如何、哪里慢了、内存够不够。Redis 单线程处理命令，任何“慢操作”都会拖累全体请求，所以监控指标、慢查询排查、内存治理和安全加固，是运维 Redis 的基本功。

INFO 看关键指标

INFO 按 section 输出统计，最常用 memory、stats、clients 三组，先看内存：

127.0.0.1:6379> INFO memory
# 输出节选：# Memory
#          used_memory_human:1.02G       # 数据+开销总内存
#          used_memory_rss:1.25G         # 进程实际占用物理内存
#          mem_fragmentation_ratio:1.22  # RSS/used，过大说明碎片多

stats 段看吞吐 instantaneous_ops_per_sec、命中 keyspace_hits/misses（命中率=hits/(hits+misses)）与 evicted_keys（淘汰数飙升要警惕）；clients 段看 connected_clients 与 rejected_connections（接近 maxclients 会拒新连接）；持久化状态看 rdb_last_bgsave_status 与 AOF 相关字段。

实时统计与大 key 扫描

redis-cli --stat 每秒刷新总览，适合现场观察；--bigkeys 用 SCAN 渐进找出大 key，不阻塞主流程，高峰期建议连从库跑：

redis-cli --stat
# 输出节选：keys       mem      clients blocked requests        connections
#          5823       1.05G    45      0       2124301 (+3120)  47
redis-cli --bigkeys
# 输出节选：[20.05%] Biggest string found so far 'user:10001' with 2.00 MB

慢查询定位

慢查询阈值 slowlog-log-slower-than 单位微秒，默认 10000 即 10ms；记入的日志用 SLOWLOG 查看，排查完 SLOWLOG RESET 清零。KEYS 这类全库匹配命令会阻塞主流程，应换成 SCAN：

127.0.0.1:6379> SLOWLOG GET 1
# 输出：1) 1) (integer) 12          # 第几条
#       2) (integer) 1750000000     # 发生时间
#       3) (integer) 45231          # 耗时 45ms
#       4) 1) "KEYS"                # 命令，KEYS 是典型慢命令
#          2) "user:*"

内存优化要点

元素少、值短的小 hash/list/zset 默认用 listpack 紧凑编码（7.x 对旧版 ziplist 的演进），超阈值自动转普通结构，无需干预；内存大头往往来自“没设过期”的垃圾数据，务必给缓存 key 配 TTL，并用 maxmemory 与淘汰策略兜底：

hash-max-listpack-entries 128    # 字段≤128 且值≤64 字节用 listpack
hash-max-listpack-value 64
maxmemory 2gb
maxmemory-policy allkeys-lru     # 常用 allkeys-lru / volatile-lru

大 key 与热 key

• 大 key：单 key 过大（几 MB 字符串、百万字段 hash）拖慢网络与序列化，DEL 删除还会阻塞主线程。先定位再拆分成多个小 key、压缩或按业务拆分；删除改用 UNLINK 异步删：

127.0.0.1:6379> MEMORY USAGE user:10001
# 输出：(integer) 2097152       # 约 2MB
127.0.0.1:6379> UNLINK user:10001
# 输出：(integer) 1             # 后台删，不阻塞主流程

• 热 key：单个 key 访问极高会打满单实例 CPU 与带宽。处理：前面加一层本地缓存，或拆成 hot:1、hot:2 多份分散读压力，并在监控中提前识别。

安全基线

bind 只监听内网/管理网段并保留 protected-mode yes，防火墙仅放行可信来源访问 6379（集群另放行 16379 总线端口）。6.0 起的 ACL 比 requirepass 更细，可按业务限定可访问的 key 前缀与命令：

requirepass 强随机密码
rename-command FLUSHALL ""      # 空串=禁用危险命令
rename-command CONFIG "r3d1sc0nfig"

127.0.0.1:6379> ACL SETUSER app on '>App@2024' ~cache:* +get +set +expire
# 输出：OK
127.0.0.1:6379> AUTH app 'App@2024'
# 输出：OK

主从部署时从库连接主库还需配置 masterauth，与 requirepass/ACL 保持一致。

例行备份与故障恢复

redis-cli -a 'YourPass' BGSAVE     # 后台 RDB 快照
# 输出：Background saving started

• 备份纪律：每天定时 BGSAVE 并把 dump.rdb 拷贝异地；开 AOF 则定期归档日志，恢复前先演练。
• 恢复流程：停实例 → 用备份覆盖数据目录（AOF 的 base/incr 文件要一起放）→ 启动 → INFO 校验 key 数与数据完整性。
• 故障速查：内存告警看淘汰数与最大 key；连接打满调 maxclients 与连接池；变慢查 SLOWLOG；主从延迟查网络与大 key 全量同步；宕机由哨兵/集群自动切换后第一时间校验新主数据。

小结：运维 Redis 就是“看 INFO、扫大 key、查慢日志”三板斧，配合紧凑编码与合理 TTL 控制内存，按安全基线收紧访问，并把备份恢复练成例行动作而非事故现场才想起。