redis运维：监控指标体系与性能问题分析

前言

redis 用起来简单，出问题时排查难。这篇从监控指标体系和性能问题分析两个维度整理运维要点，指标是日常巡检的眼睛，排查手段是出事时的手术刀。

一、监控指标体系

redis 的监控指标可以分为五大类。

1. 性能指标（Performance）

Name	Description
latency	Redis 响应一个请求的时间
instantaneous_ops_per_sec	平均每秒处理请求总数
hit rate (calculated)	缓存命中率（计算出来的）

2. 内存指标（Memory）

Name	Description
used_memory	已使用内存
mem_fragmentation_ratio	内存碎片率
evicted_keys	由于最大内存限制被移除的 key 的数量
blocked_clients	由于 BLPOP、BRPOP 或 BRPOPLPUPUSH 而被阻塞的客户端

3. 基本活动指标（Basic activity）

Name	Description
connected_clients	客户端连接数
connected_slaves	slave 数量
master_last_io_seconds_ago	最近一次主从交互之后的秒数
keyspace	数据库中的 key 值总数

4. 持久性指标（Persistence）

Name	Description
rdb_last_save_time	最后一次持久化保存磁盘的时间戳
rdb_changes_since_last_save	自最后一次持久化以来数据库的更改数

5. 错误指标（Error）

Name	Description
rejected_connections	由于达到 maxclient 限制而被拒绝的连接数
keyspace_misses	key 值查找失败（没有命中）次数
master_link_down_since_seconds	主从断开的持续时间（以秒为单位）

二、监控方式与工具

常用工具：redis-benchmark、redis-stat、redis-faina、redislive、redis-cli、monitor、slowlog。

慢日志相关配置：

1
2


slowlog-log-slower-than 1000   # 设置慢查询的时间下限，单位：微秒
slowlog-max-len 100            # 慢查询日志保留的条数，单位：命令数

slowlog 子命令：get 获取慢查询日志、len 获取慢查询日志条目数、reset 重置慢查询日志。

info 命令（可一次性获取所有信息，也可按块获取）：

server：服务器运行的环境参数
clients：客户端相关信息
memory：服务器运行内存统计数据
persistence：持久化信息
stats：通用统计数据
replication：主从复制相关信息
cpu：CPU 使用情况
cluster：集群信息
keyspace：键值对统计数量信息

终端使用：

1
2


./redis-cli info | grep <参数>          # 按块获取并过滤
./redis-cli info stats | grep ops

交互式使用：

1
2


# ./redis-cli
> info server

三、常用监控命令实战

性能监控（每秒操作数）：

1

redis-cli info | grep ops

redis-cli 查看 ops

redis-benchmark 的基准测试输出（各命令延迟分布与吞吐）：

redis-benchmark 基准测试输出

内存监控：

1

./redis-cli info | grep used | grep human

1
2
3
4


used_memory_human:2.99M       # 内存分配器从操作系统分配的内存总量
used_memory_rss_human:8.04M   # 操作系统看到的内存占用，top 命令看到的内存
used_memory_peak_human:7.77M  # redis 内存消耗的峰值
used_memory_lua_human:37.00K  # lua 脚本引擎占用的内存大小

阻塞客户端与淘汰 key：

1
2


./redis-cli info | grep blocked_clients    # 被 BLPOP 等阻塞的客户端数
./redis-cli info | grep evicted_keys       # 因最大内存限制被移除的 key 数

四、性能问题分析三板斧

1. 测试 redis 响应延迟

为了避免业务服务器到 Redis 服务器之间的网络延迟，需要直接在 Redis 服务器上测试实例的响应延迟。以下命令测试实例 60 秒内的最大响应延迟：

1
2
3
4
5
6
7
8


$ redis-cli -h 127.0.0.1 -p 6379 --intrinsic-latency 60
Max latency so far: 1 microseconds.
Max latency so far: 15 microseconds.
...
Max latency so far: 72 microseconds.

1428669267 total runs (avg latency: 0.0420 microseconds / 42.00 nanoseconds per run).
Worst run took 1429x longer than the average latency.

这 60 秒内的最大响应延迟为 72 微秒（0.072 毫秒）。

还可以查看一段时间内 Redis 的最小、最大、平均访问延迟：

1
2
3
4


$ redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 1
min: 0, max: 1, avg: 0.13 (100 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.12 (99 samples) -- 1.01 seconds range
...

每间隔 1 秒采样 Redis 的平均操作耗时，上面结果分布在 0.08 ~ 0.13 毫秒之间。

2. 查看慢日志

查看慢日志前先设置阈值。例如设置慢日志阈值为 5 毫秒、保留最近 500 条：

1
2
3
4


# 命令执行耗时超过 5 毫秒，记录慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近 500 条慢日志
CONFIG SET slowlog-max-len 500

之后所有耗时超过 5 毫秒的命令都会被记录，查询最近记录的慢日志：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer) 32693       # 慢日志ID
   2) (integer) 1593763337  # 执行时间戳
   3) (integer) 5299        # 执行耗时(微秒)
   4) 1) "LRANGE"           # 具体执行的命令和参数
      2) "user_list:2000"
      3) "0"
      4) "-1"
2) 1) (integer) 32692
   2) (integer) 1593763337
   3) (integer) 5044
   4) 1) "GET"
      2) "user_info:1000"
...

通过慢日志可以知道在什么时间点、执行了哪些命令比较耗时。

3. bigkey 扫描

Redis 提供了扫描 bigkey 的命令，扫描出一个实例中 bigkey 的分布情况，输出结果按类型维度展示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


$ redis-cli -h 127.0.0.1 -p 6379 --bigkeys -i 0.01

...
-------- summary -------

Sampled 829675 keys in the keyspace!
Total key length in bytes is 10059825 (avg len 12.13)

Biggest string found 'key:291880' has 10 bytes
Biggest   list found 'mylist:004' has 40 items
Biggest    set found 'myset:2386' has 38 members
Biggest   hash found 'myhash:3574' has 37 fields
Biggest   zset found 'myzset:2704' has 42 members

36313 strings with 363130 bytes (04.38% of keys, avg size 10.00)
787393 lists with 896540 items (94.90% of keys, avg size 1.14)
1994 sets with 40052 members (00.24% of keys, avg size 20.09)
1990 hashs with 39632 fields (00.24% of keys, avg size 19.92)
1985 zsets with 39750 members (00.24% of keys, avg size 20.03)

从输出可以清晰地看到每种数据类型中占用最大内存 / 拥有最多元素的 key 是哪一个，以及各类型在整个实例中的占比和平均大小。

注意：--bigkeys 只能给出每种类型最大的 key，生产环境定位具体业务大 key 时，还需要结合业务 key 命名规则分析，必要时用 MEMORY USAGE <key> 精确度量。

总结

日常巡检盯五类指标（延迟/QPS/内存/主从/错误），出现性能问题时按「延迟测试 → 慢日志 → bigkey」的顺序推进，基本能覆盖 redis 大部分性能场景。

文章目录