【Redis从入门到精通】第62篇：Redis监视器——MONITOR命令的原理与实战

上一篇【第61篇】慢查询日志——找出Redis性能瓶颈的利器
下一篇【第63篇】分布式锁——用Redis实现高可靠锁的正确姿势

运维老王：“客户端A说我没写过那个Key，客户端B也说没有，那到底是谁写的？”
程序员小李：“开启MONITOR，看看到底谁在搞鬼。”
运维老王：“打开了……卧槽，这刷屏速度，根本看不过来啊！”
程序员小李：“所以说MONITOR是双刃剑，用好了抓鬼，用不好伤己。”

在Redis的调试工具箱中，MONITOR命令是一个极其强大的"偷窥神器"——它能让你实时看到Redis服务器接收到的每一条命令。无论哪个客户端发送的、什么时候发的、发了什么，统统无所遁形。

但就像X光一样，用多了对身体（服务器性能）是有伤害的。本文将带你深入理解MONITOR的原理、正确用法以及何时该用、何时绝对不该用。

一、MONITOR命令的基本使用

1.1 命令简介

# 开启监视器模式127.0.0.1:6379>MONITOR OK# 之后，所有客户端发送的命令都会实时显示在这个连接上1716278400.123456[0127.0.0.1:54321]"SET""user:1001""Alice"1716278400.123789[0127.0.0.1:54322]"GET""user:1001"1716278400.124012[0127.0.0.1:54321]"LPUSH""queue:tasks""task_001"1716278400.124345[1192.168.1.100:63790]"HSET""order:5001""status""paid"

1.2 输出格式解析

每行MONITOR输出的格式如下：

1716278400.123456 [0 127.0.0.1:54321] "SET" "user:1001" "Alice" │ │ │ │ │ │ │ │ │ │ │ └── 参数 │ │ │ │ └── 命令名 │ │ │ └── 数据库编号（默认为0） │ │ └── 客户端IP:端口 │ └── 客户端ID（可以 CLIENT LIST 查看） └── UNIX时间戳（秒.微秒）

通过这些信息，你可以精确地知道：

• 谁（哪个客户端IP和端口）
• 什么时候（精确到微秒的时间戳）
• 做了什么（执行的完整命令和参数）

1.3 redis-cli --monitor 方式

除了在redis-cli里手动输入MONITOR，还可以直接用命令行参数：

# 方式1：先连接再MONITORredis-cli127.0.0.1:6379>MONITOR# 方式2：直接启动时就开启监视redis-cli--monitor# 方式3：监视指定数据库redis-cli-n1--monitor# 方式4：将输出重定向到文件（方便后续分析）redis-cli--monitor>/tmp/redis_monitor.log&# 方式5：管道模式读取已有的MONITOR输出做分析redis-cli--monitor|grep"user:"

二、MONITOR的实现原理

2.1 客户端标志位

当一个客户端执行MONITOR命令后，Redis会在该客户端的flags中设置CLIENT_MONITOR标志位：

redisClient 结构体中的 flags 字段： ┌──────────────────────────────────────────────────────┐ │ flags │ │ ┌──────┐ ┌──────────┐ ┌──────┐ ┌───────────────────┐│ │ │MASTER│ │SLAVE │ │PUBSUB│ │CLIENT_MONITOR ← 新增││ │ └──────┘ └──────────┘ └──────┘ └───────────────────┘│ └──────────────────────────────────────────────────────┘

2.2 monitors链表

Redis服务器内部维护了一个monitors链表，所有处于MONITOR状态的客户端都会被加入这个链表：

Redis服务器内存结构： ┌─────────────────────────────────────────────────────┐ │ redisServer │ │ │ │ monitors ──> [client_A] ──> [client_B] ──> NULL │ │ │ │ │ │ MONITOR状态的客户端 │ │ │ 都会被挂到这个链表上 │ │ │ └─────────────────────────────────────────────────────┘ 当客户端执行 MONITOR 命令时： ┌─────────┐ │ MONITOR │──> flags |= CLIENT_MONITOR │ │──> listAddNodeTail(server.monitors, client) └─────────┘

2.3 命令执行的"窃听"流程

MONITOR的核心机制是在命令执行前"窃听"命令信息。具体流程如下：

命令执行流程（简化版）： 客户端发送命令 │ ▼ ┌───────────────┐ │ 查询缓存/解析 │ └───────┬───────┘ │ ▼ ┌───────────────────────────────────────┐ │ ★ 检查 monitors 链表是否为空 │ │ 如果不为空： │ │ 1. 构建命令信息的字符串 │ │ 2. 遍历 monitors 链表 │ │ 3. 将命令信息发送给每个监视器客户端 │ └───────────────┬───────────────────────┘ │ ▼ ┌───────────────┐ │ 执行命令本身 │ └───────────────┘ │ ▼ ┌───────────────┐ │ 返回结果给客户端│ └───────────────┘

关键代码逻辑（伪代码）：

// call() 函数 - 命令执行的入口voidcall(redisClient*c,intflags){// ... 前置检查 ...// ★ 如果有监视器，把命令信息发给它们if(listLength(server.monitors)>0){// 构建监视器输出字符串// 格式: "timestamp [db_id client_addr] \"cmd\" \"arg1\" \"arg2\" ..."char*monitor_cmd=createMonitorOutput(c);// 遍历所有监视器客户端，逐个发送listNode*ln;listIter li;listRewind(server.monitors,&li);while((ln=listNext(&li))){redisClient*monitor=ln->value;// 将命令信息追加到监视器客户端的输出缓冲区addReply(monitor,monitor_cmd);}}// 执行真正的命令c->cmd->proc(c);// ... 后续处理 ...}

这里有一个重要的细节：MONITOR是在命令执行前发送信息的，这意味着即使命令执行失败或被拒绝，监视器依然能看到它。

三、MONITOR的性能影响

这是使用MONITOR之前必须了解的最重要的事情。

3.1 性能损耗有多大？

根据Redis官方的benchmark测试，开启MONITOR后，Redis的吞吐量大约下降50%：

MONITOR 对性能的影响： 不开启 MONITOR： ┌─────────────────────────────────────────┐ │ QPS: ████████████████████████████ 100000│ └─────────────────────────────────────────┘ 开启 1 个 MONITOR 客户端： ┌─────────────────────────────────────────┐ │ QPS: ██████████████████ ~50000 │ └─────────────────────────────────────────┘ 吞吐量下降约 50%！ 开启 2 个 MONITOR 客户端： ┌─────────────────────────────────────────┐ │ QPS: ████████████ ~33000 │ └─────────────────────────────────────────┘ 下降更多！

3.2 性能损耗的原因

每条命令的额外开销： 原始流程： 接收命令 ──> 执行命令 ──> 返回结果 MONITOR流程：接收命令 ──> 格式化命令信息 ──> 发送给监视器1 ──> 发送给监视器2 ──> 发送给监视器N ──> 执行命令 ──> 返回结果 额外开销 = 格式化 + N次网络发送 + 输出缓冲区占用

具体影响：

1. CPU增加：每条命令都需要额外的字符串格式化操作
2. 网络带宽翻倍：每条命令至少多发送一份数据给监视器
3. 内存增加：监视器客户端的输出缓冲区可能堆积大量数据
4. 客户端延迟增加：MONITOR的输出可能挤占网络带宽

踩坑提示：绝对不要在生产环境的Redis主节点上长时间开启MONITOR。如果确实需要，请在从节点上开启，且时间尽量短。曾经有运维同学在高峰期对主节点MONITOR了10分钟，结果导致整个服务雪崩——这不是段子，是真事。

四、MONITOR的实际使用场景

虽然性能影响大，但MONITOR在正确的场景下是无价之宝。

4.1 排查未知写入

场景：某个Key的值突然变了，但所有开发都说没碰过。

# 步骤1：在redis-cli中开启MONITOR，过滤特定Keyredis-cli--monitor|grep"mystery_key"# 输出：# 1716278400.123456 [0 192.168.1.50:34567] "SET" "mystery_key" "谁改了我"

一目了然，是192.168.1.50:34567这个客户端干的。顺藤摸瓜，找到对应的业务服务。

4.2 调试客户端行为

场景：怀疑某个客户端发了多余的命令，或者命令格式不对。

# 监控特定IP的所有命令redis-cli--monitor|grep"192.168.1.50"# 监控特定命令redis-cli--monitor|grep"HSET"

4.3 配合DEBUG命令使用

# 在一个终端开启MONITORredis-cli--monitor# 在另一个终端模拟慢操作redis-cli DEBUG SLEEP1# 让Redis暂停1秒# MONITOR输出：# 1716278400.123456 [0 127.0.0.1:54321] "DEBUG" "SLEEP" "1"# 模拟服务器重载（测试环境使用！）redis-cli DEBUG RELOAD

踩坑提示：DEBUG SLEEP和DEBUG RELOAD是调试命令，千万不要在生产环境使用！它们会阻塞整个Redis进程。

4.4 性能分析

结合DEBUG SLEEP可以精确测试延迟的影响：

# 终端1：MONITORredis-cli--monitor# 终端2：模拟阻塞redis-cli DEBUG SLEEP0.5# 终端3：同时发送请求，观察延迟redis-cli--latency

五、集群模式下的限制

在Redis Cluster模式下，MONITOR的行为有一些限制：

Redis Cluster 集群： ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ 节点A (主) │ │ 节点B (主) │ │ 节点C (主) │ │ slot 0-5460 │ │ slot 5461- │ │ slot 10923- │ │ │ │ 10922 │ │ 16383 │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ MONITOR在这里 MONITOR在这里 MONITOR在这里 只能看到 只能看到 只能看到 这里的命令 这里的命令 这里的命令 ✗ 无法在一个节点上看到所有命令

在集群模式下，你需要在每个节点上都开启MONITOR才能看到完整的命令流：

# 需要对每个节点分别开启MONITORredis-cli-p7000--monitor>node_7000.log&redis-cli-p7001--monitor>node_7001.log&redis-cli-p7002--monitor>node_7002.log&redis-cli-p7003--monitor>node_7003.log&redis-cli-p7004--monitor>node_7004.log&redis-cli-p7005--monitor>node_7005.log&

六、更好的替代方案

鉴于MONITOR的性能开销较大，Redis提供了更轻量的替代方案：

6.1 对比表格

6.2 LATENCY MONITOR

# 开启延迟监控（默认关闭）127.0.0.1:6379>CONFIG SET latency-monitor-threshold100OK# 查看延迟事件127.0.0.1:6379>LATENCY LATEST# 查看延迟历史127.0.0.1:6379>LATENCY HISTORYcommand# 自动诊断延迟原因127.0.0.1:6379>LATENCY DOCTOR

6.3 redis-faina：MONITOR的"数据分析助手"

redis-faina是Instagram（没错，就是那个Instagram）开源的MONITOR输出分析工具。它的思路很巧妙——不直接在Redis上实时看MONITOR输出，而是把输出保存下来，然后离线分析。

# 安装pipinstallredis-faina# 使用方式1：管道redis-cli--monitor|redis-faina# 使用方式2：分析已保存的日志redis-faina /tmp/redis_monitor.log# 输出示例：# Top K Prefixes: Top Commands:# users: GET 45.2% (45234)# session: SET 30.1% (30123)# cache: LPUSH 15.3% (15345)# HGETALL 9.4% (9456)## Top Keys:# users:1001:profile GET 12345 calls, avg 0.5ms# session:abc123 SET 9876 calls, avg 0.3ms## Overall Stats:# Total Commands: 100,023# Total Latency: 50.123 seconds# Avg Latency: 0.501 ms# Time Range: 1716278300 - 1716278600 (5 minutes)

这种"捕获 + 离线分析"的模式，完美解决了MONITOR实时查看的两大痛点：

1. 数据刷太快看不过来 → 工具自动统计汇总
2. 在Redis上实时分析影响性能 → 只捕获数据，分析在别的机器上进行

七、退出MONITOR模式

退出MONITOR很简单，但有人会因为不知道怎么退而强制关闭终端：

# 方式1：发送QUIT命令（推荐）127.0.0.1:6379>QUIT# 方式2：Ctrl+C# 直接按Ctrl+C中断连接# 方式3：如果是后台运行kill%1# 杀掉后台进程

退出后，该客户端会从monitors链表中移除，Redis恢复正常性能。

小结

MONITOR是Redis调试的"核武器"——威力巨大，但使用需要谨慎。记住以下要点：

1. 生产慎用：性能损耗约50%，只在从节点或低峰期使用
2. 替代优先：优先用SLOWLOG、LATENCY MONITOR、INFO commandstats
3. 短时间用：需要MONITOR时，抓取几秒数据就够了，然后立刻关闭
4. 配合工具：用redis-faina等工具分析MONITOR输出，效率翻倍
5. 集群注意：每个节点只能看到自己的命令

上一篇【第61篇】慢查询日志——找出Redis性能瓶颈的利器
下一篇【第63篇】分布式锁——用Redis实现高可靠锁的正确姿势