当想监控redis的热点key时,可以使用redis的monitor及faina来监控及分析。monitor是redis的监控命令,faina是一个python脚本,需要额外下载。
faina下载方式:
https://github.com/facebookarchive/redis-faina 在该git上直接将redis-faina.py下载下来上传到服务器即可。
使用方式如下:
1、先使用monitor实时监控redis的指令(打码部分为redis的密码):
![]()
注意:因开启该监控后,会监控所有的redis收到的指令,并将指令复制到监控的客户端,所以会严重影响redis的性能(影响超过50%的性能),所以这个尽可能是在测试环境监测,不到万不得已别在生产上使用,即使使用也需要尽快关闭。关闭方式为ctrl+C键进行中断。如上截图,关闭后会生成一个monitor0324.log的文件,该文件中即为监控期间监控到的所有命令。
monitor0324.log文件内容格式如下:

2、有了监控到的命令文件后,再使用redis-faina.py脚本进行分析


统计分析结果说明:
1、整体统计(Overall Stats)
Lines Processed 1075
共处理了 1075 条 Redis 命令日志。
Commands/Sec 13.82
平均每秒处理 13.82 条命令,说明 Redis 负载较低(通常生产环境每秒数千到数万条为高负载)。
2、前缀统计(Top Prefixes)
统计了键名中常见的前缀(按 : 或 _ 分割):
_sentinel (38次, 3.53%)
Sentinel 相关的键,可能用于 Redis 哨兵监控。
Lock (9次, 0.84%)
分布式锁相关的键,可能是业务代码中的锁操作。
spring (4次, 0.37%)
可能来自 Spring 框架的 Redis 操作(如 Spring Session)。
3、高频键(Top Keys)
列出被访问最频繁的键:
_sentinel _hello
Sentinel 的心跳检测键。
CHANNEL_DING_MSC_REDIS_KEY
发布订阅(Pub/Sub)频道的键。
4、高频命令(Top Commands)
PING (486次, 45.21%)
客户端频繁发送 PING,可能是连接池保活或健康检查,但比例过高需检查是否合理。
EXISTS (117次, 10.88%)
检查键是否存在,可能是缓存穿透的征兆(大量查询不存在的键)。
HGETALL (89次, 8.28%)
获取哈希表所有字段,若哈希表较大可能影响性能。
AUTH (66次, 6.14%)
认证操作频繁,可能是客户端频繁重建连接。
EVAL (49次, 4.56%)
Lua 脚本执行,需检查脚本复杂度。
PUBLISH (38次, 3.53%)
发布消息到频道,属于发布订阅模式。
5、命令耗时(Command Time)
Median 1095.0μs (中位数)
50% 的命令执行时间 ≤ 1.095ms,性能较好。
75% 55608.25μs (55.6ms)
25% 的命令耗时较高(超过 55ms),可能存在慢查询。
90% 270649.0μs (270.6ms)
10% 的命令耗时非常高(超过 270ms),需要重点关注。
6、Heaviest Commands (最耗时的命令)
表格显示的是 每个命令的总耗时(微秒),反映的是该命令在所有调用中累计消耗的 CPU 时间:
PING - 31,005,614μs (31秒)
总耗时最高,远超其他命令,说明系统中有大量 PING 请求且部分请求处理极慢。
PUBLISH - 8,397,782.75μs (8.4秒)
发布订阅操作耗时较高,可能是频道消息过多或订阅者处理慢。
INFO - 2,050,982.75μs (2秒)
INFO 命令通常用于监控,但频繁执行或返回数据过大时会影响性能。
AUTH - 1,664,152.5μs (1.66秒)
认证操作耗时异常,可能是客户端频繁重建连接导致。
HGETALL - 1,577,498μs (1.58秒)
哈希表全字段查询,若哈希表较大(如存储大量字段)会显著拖慢性能。
EVAL - 829,838.5μs (0.83秒)
Lua 脚本执行耗时,需检查脚本复杂度。
SET/HSET
写入操作耗时相对正常,但需结合 QPS 判断是否合理。
7、Slowest Calls (最慢的单次调用)
表格列出了 单次命令调用的最高耗时(微秒),全部来自 PING:
所有最慢调用均为 PING,且耗时均在 1,000,000μs (1秒) 以上。
注:faina脚本统计命令的耗时时间是根据命令的上一条时间戳与当前的命令的时间戳相减来获得的,这样的话就会有误差,比如上面的截图,是在测试环境下进行监控及分析的,redis是在一个低负载的情况,命令与命令之间相隔有时间差,比如客户端每1s发送一个ping命令,但是ping命令执行只需0.1ms,这样统计出来的时间与真实的时间就会有误差。这就是为什么上面的最耗时的命令看到的都是ping命令。
看下faina脚本中统计时间的关键代码就知道指令的统计时间是根据前后2条指令的时间戳的差值得出来的:

若想要命令精确的耗时时间,可以使用slowlog命令(不过默认命令超过10ms才会记录到慢日志)。



2213

被折叠的 条评论
为什么被折叠?



