redis阻塞命令监控应避免monitor，改用slowlog、client list和info clients；禁用flushall/flushdb推荐acl而非重命名；blpop/brpop需限制timeout并标记连接；acl配置必须显式限制default用户权限。

Redis 阻塞命令监控：靠 MONITOR 不现实，主线程会被卡死

直接在生产环境跑 MONITOR 是危险操作——它会阻塞 Redis 主线程，所有命令排队等待输出，QPS 断崖式下跌。你看到的“实时命令流”是以牺牲服务为代价换来的，连 INFO 都可能延迟返回。

真正可用的监控路径是组合使用：

• slowlog get 10 查最近 10 条耗时超阈值的命令（默认 10ms，建议调成 config set slowlog-log-slower-than 1000 即 1ms）
• client list 看 flags 字段含 b 的客户端（如 flags=b 表示正在执行阻塞命令）
• info clients 中的 blocked_clients 值突增，就是最直接的阻塞信号

拦截 FLUSHALL 和 FLUSHDB：重命名不如 ACL 精准可控

旧版 Redis 用 rename-command FLUSHALL "" 确实能禁用，但有硬伤：配置 reload 后失效；且一旦写错成 rename-command FLUSHALL FLUSHALL_BACKUP，反而暴露了新入口。

Redis 6.0+ 推荐用 ACL（Access Control List）：

• 给运维账号分配 ~* +@all，保留全部权限
• 给应用账号只给 ~cache:* +get +set +del +expire 这类白名单指令
• 关键点：FLUSHALL 和 FLUSHDB 属于 @dangerous 类别，ACL 默认不包含，不显式加就无法执行

验证方式：acl whoami 查当前用户权限，acl list 看所有规则。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

如何阻止 BLPOP/BRPOP 类阻塞命令被滥用

这类命令本身合法，问题出在超长 timeout 或无 key 监听导致连接长期挂起。不能一刀禁用，得控场景：

• 在客户端侧强制设置 timeout 参数上限（如 Python 的 redis.blpop(keys, timeout=5)，绝不用 timeout=0）
• 用 client setname 给连接打标（如 client setname app:order:worker），再配合 client list 定期扫描 name 含 :worker 且 flags 为 b 的连接，超时未响应则 client kill
• Redis 7.0+ 支持 client unblock <id> TIMEOUT</id> 主动中断挂起连接，比杀进程更安全

ACL 配置后仍执行失败？检查 default 用户是否被覆盖

很多人配完 ACL 规则却还是能执行 FLUSHALL，原因是没动 default 用户——它默认拥有 +@all 权限。只要没显式限制，任何未认证连接都走 default 账号。

修复动作只有两步：

• acl setuser default -@dangerous（移除危险指令）
• acl save 持久化到 aclfile（否则重启即失效）

做完立刻测试：redis-cli flushall 应返回 (error) NOPERM this user has no permissions to run the 'flushall' command。漏掉 default 是线上 ACL 失效最常见的原因。