工具 & 效率15 分钟阅读
Redis 运维命令 100 条
Redis 的运维并不只是执行 GET、SET 和 DEL。真正到了生产环境，DBA 和运维人员面对的往往是内存突然暴涨、CPU 持续升高、连接数打满、大 Key 阻塞、热 Key 集中、慢命令堆积、RDB 失败、AOF 膨胀、主从延迟、Sentinel 误切换或者 Cluster 槽位异常。
2026年7月27日阅读—点赞—收藏—
dba100redis墨力计划
内容阅读
在知识库中专注阅读，并随时返回相关工具与课程
在知识库中专注阅读，并随时返回相关工具与课程
Redis 的运维并不只是执行 GET、SET 和 DEL。真正到了生产环境，DBA 和运维人员面对的往往是内存突然暴涨、CPU 持续升高、连接数打满、大 Key 阻塞、热 Key 集中、慢命令堆积、RDB 失败、AOF 膨胀、主从延迟、Sentinel 误切换或者 Cluster 槽位异常。
Redis 的运维并不只是执行 GET、SET 和 DEL。真正到了生产环境，DBA 和运维人员面对的往往是内存突然暴涨、CPU 持续升高、连接数打满、大 Key 阻塞、热 Key 集中、慢命令堆积、RDB 失败、AOF 膨胀、主从延迟、Sentinel 误切换或者 Cluster 槽位异常。
Redis 的很多问题并不会直接表现为传统关系型数据库里的“慢 SQL”。一个复杂度为 O(N) 的命令、一次几百 MB 的 Key 删除、一次耗时过长的 Fork，甚至一个没有设置过期时间的业务前缀，都可能让实例延迟突然升高。
下面整理 100 条 Redis 生产运维中使用频率较高的命令，覆盖连接与实例信息、Key 检查、内存分析、客户端连接、慢命令、延迟诊断、参数配置、ACL、RDB、AOF、主从复制、Sentinel、Redis Cluster 和常用诊断工具等场景。
本文主要面向 Redis Open Source 6.2—8.x。不同版本和托管云服务可能会禁用部分管理命令，Redis 8 新增命令会单独说明。文中的 IP、端口、用户、Key、节点 ID 和集群名称均为示例。涉及删除 Key、修改配置、重写持久化文件、主从切换和集群槽位迁移的操作，执行前必须确认影响范围。
1redis-cli -h 192.168.10.10 -p 6379如果启用了 ACL：
1redis-cli -h 192.168.10.10 -p 6379 --user dba根据提示输入密码，避免使用 -a 将密码直接暴露在 Shell 历史和进程列表中。
1redis-cli --tls \2 -h redis.example.com \3 -p 6380 \4 --cacert /etc/redis/ca.crt \5 --user dba实际证书、私钥和认证方式应以服务端 TLS 配置为准。
1PING正常情况下返回：
1PONG1INFO server重点关注：
1redis_version2redis_mode3os4arch_bits5process_id6tcp_port7uptime_in_seconds8config_file1redis-cli INFO server | grep -E 'uptime_in_seconds|uptime_in_days'可用于确认实例近期是否重启过。
1INFO生产排查时通常建议按模块查询，避免输出过多：
1INFO memory2INFO clients3INFO stats4INFO persistence5INFO replication6INFO keyspace1TIME返回 Unix 时间戳和微秒部分，适合排查日志时间、过期时间和节点时钟差异。
1ROLE可以快速判断当前节点是 master、slave/replica，还是 Sentinel。
1DBSIZE该命令返回当前逻辑数据库中的 Key 数量，时间复杂度为 O(1)。
1INFO keyspace返回各 DB 的 Key 数量、设置过期时间的 Key 数量和平均 TTL。
1SELECT 1Redis Cluster 只支持 DB 0，不支持通过 SELECT 使用其他逻辑数据库。
1EXISTS app:user:100011TYPE app:user:10001可能返回 string、list、set、zset、hash、stream 等类型。
1TTL app:user:10001毫秒级查询：
1PTTL app:user:10001返回 -1 表示 Key 存在但没有设置过期时间，返回 -2 表示 Key 不存在。
1EXPIRE app:user:10001 3600毫秒级设置：
1PEXPIRE app:user:10001 36000001EXPIRETIME app:user:10001毫秒级时间戳：
1PEXPIRETIME app:user:10001这两个命令从 Redis 7.0 开始提供。
1SCAN 0 MATCH app:user:* COUNT 1000必须使用返回的新游标继续扫描，直到游标重新变为 0。COUNT 只是每次迭代的数量提示，不保证严格返回指定数量。
1redis-cli -h 192.168.10.10 -p 6379 \2 --scan --pattern 'app:user:*'生产环境不要使用 KEYS * 扫描全库，它可能长时间阻塞 Redis 主线程。
1UNLINK app:cache:bigkeyUNLINK 会先从 Key 空间移除 Key，再由后台线程异步释放内存，通常比直接 DEL 更适合删除大 Key。
1OBJECT ENCODING app:user:10001不同编码会影响内存占用和访问性能。
1MEMORY USAGE app:user:10001对复杂类型增加采样数量：
1MEMORY USAGE app:user:10001 SAMPLES 101INFO memory重点关注：
1used_memory2used_memory_rss3used_memory_peak4used_memory_dataset5mem_fragmentation_ratio6allocator_frag_ratio7maxmemory8maxmemory_policy1MEMORY STATS该命令可以查看数据集、主字典、过期字典、复制缓冲区、客户端缓冲区和内存碎片等信息。
1MEMORY DOCTOR当实例样本不足或内存使用很低时，命令可能无法给出有效诊断。
1CONFIG GET maxmemory返回 0 通常表示未设置 Redis 级别的最大内存限制。
1CONFIG GET maxmemory-policy常见策略包括：
1noeviction2allkeys-lru3allkeys-lfu4volatile-lru5volatile-ttl6allkeys-random1CONFIG SET maxmemory 8gb动态修改后还需要结合 CONFIG REWRITE 或配置管理系统持久化，否则重启后可能恢复原配置。
1CONFIG SET maxmemory-policy allkeys-lru修改前必须确认 Redis 是纯缓存还是数据存储，错误的淘汰策略可能造成业务数据丢失或写入失败。
1redis-cli -h 192.168.10.10 -p 6379 --bigkeys--bigkeys 主要按元素数量或字符串长度寻找各数据类型中的大 Key，并不等同于精确的内存排行榜。
1redis-cli -h 192.168.10.10 -p 6379 \2 --memkeys --memkeys-samples 10该功能依赖 MEMORY USAGE，适合进一步寻找占用内存较大的 Key。
1INFO clients重点关注：
1connected_clients2cluster_connections3maxclients4blocked_clients5tracking_clients6clients_in_timeout_table1CLIENT LIST重点检查客户端地址、连接空闲时间、当前命令、订阅状态、输出缓冲区和连接名称。
1CLIENT INFO1CLIENT ID客户端 ID 可以用于精确终止目标连接。
1CLIENT SETNAME order-service应用设置连接名称后，DBA 可以通过 CLIENT LIST 更容易识别连接来源。
1CLIENT GETNAME1CLIENT KILL ID 12345也可以按照地址、用户、类型等条件筛选。生产执行前必须确认目标客户端，避免批量断开正常业务连接。
1INFO stats重点关注：
1total_connections_received2total_commands_processed3instantaneous_ops_per_sec4total_net_input_bytes5total_net_output_bytes6rejected_connections7expired_keys8evicted_keys9keyspace_hits10keyspace_misses1INFO commandstats可以查看各命令调用次数、累计耗时、每次平均耗时和失败次数。
1INFO errorstats适合排查认证失败、参数错误、只读写入和达到内存上限等异常。
1CONFIG GET slowlog-log-slower-than2CONFIG GET slowlog-max-lenslowlog-log-slower-than 的单位是微秒。慢日志只统计命令在 Redis 内部执行的时间，不包含网络传输时间。
1SLOWLOG GET 201SLOWLOG LEN1SLOWLOG RESET清空前应确认监控平台或故障分析是否仍需要这些记录。
1LATENCY DOCTOR延迟监控需要配置 latency-monitor-threshold。该命令会根据已记录的延迟事件给出诊断建议。
1CONFIG GET '*'生产环境建议查询具体参数，避免一次输出过多敏感配置：
1CONFIG GET timeout2CONFIG GET maxclients3CONFIG GET tcp-keepalive1CONFIG SET timeout 300并不是所有参数都支持动态修改，托管云服务也可能禁用 CONFIG 命令。
1CONFIG REWRITE该命令会重写 Redis 当前使用的配置文件。执行前应备份配置，并确认文件权限和自动化配置管理方式。
1COMMAND INFO GET SET KEYS可查看命令参数数量、标志、Key 定位规则和复杂度相关元数据。
1COMMAND LIST FILTERBY ACLCAT dangerous可以用于审计 CONFIG、SHUTDOWN、FLUSHALL 等高风险命令是否需要限制。
1ACL WHOAMI1ACL USERS查看完整 ACL 规则：
1ACL LIST1ACL GETUSER app_user1ACL SETUSER report_user \2 on '>Replace_With_Strong_Password' \3 '~report:*' '+@read' '-@dangerous'真实密码不要直接保存在 Shell 历史中，生产环境应通过安全的配置和密钥管理方式下发。
1ACL LOG 20清空 ACL 日志：
1ACL LOG RESET1INFO persistence重点关注：
1loading2rdb_bgsave_in_progress3rdb_last_bgsave_status4rdb_last_bgsave_time_sec5aof_enabled6aof_rewrite_in_progress7aof_last_bgrewrite_status8aof_last_write_status1CONFIG GET save1BGSAVE如果 AOF 重写正在进行，可以使用：
1BGSAVE SCHEDULEBGSAVE 会触发 Fork，大内存实例需要重点关注 Fork 耗时、Copy-on-Write 和系统可用内存。
1LASTSAVE返回 Unix 时间戳。还应结合 INFO persistence 判断最后一次后台保存是否成功。
1CONFIG GET dir2CONFIG GET dbfilename1CONFIG GET appendonly1CONFIG SET appendonly yes启用前应评估磁盘空间、写入延迟、AOF 策略和现有 RDB 数据，不能只修改一个参数就结束变更。
1CONFIG GET appendfsync常见值：
1always2everysec3no1BGREWRITEAOF重写会产生新的 AOF 文件并带来额外磁盘和内存压力，执行前应确认空间充足。
1redis-check-rdb /var/lib/redis/dump.rdb2redis-check-aof /var/lib/redis/appendonlydir/appendonly.aof.manifest修复 AOF 前必须先备份原文件，不要直接对唯一副本执行破坏性修复。
1INFO replication主节点重点关注已连接副本数量和复制偏移量，副本节点重点关注主从链路状态、延迟和最后一次 I/O 时间。
1ROLE主节点会返回副本列表，副本节点会返回主节点地址、复制状态和复制偏移量。
1REPLICAOF 192.168.10.10 6379该操作可能触发全量同步并覆盖当前节点数据，执行前必须确认实例角色和数据影响。
1REPLICAOF NO ONE手工提升不会自动修改客户端连接地址，也不会自动协调其他副本，生产切换应配合 Sentinel、Cluster 或完整的切换流程。
1WAIT 1 5000表示等待最多 5000 毫秒，直到此前写入被至少 1 个副本确认。WAIT 提高数据安全性，但不等同于强一致事务。
1WAITAOF 1 1 5000该命令从 Redis 7.2 开始提供，用于等待本地和副本 AOF 落盘确认。
1CLIENT LIST TYPE replica旧版本可能使用 slave 类型名称。
1CONFIG GET repl-backlog-size2CONFIG GET repl-backlog-ttl积压缓冲区过小会增加断线重连后触发全量同步的概率。
1CONFIG GET replica-read-only副本允许读取并不代表读取一定是最新数据，业务应能接受复制延迟。
1CONFIG GET repl-diskless-sync2CONFIG GET repl-diskless-sync-delay无盘复制是否合适，需要结合网络带宽、磁盘性能、内存和副本数量评估。
1redis-cli -h 192.168.10.20 -p 26379Sentinel 默认端口为 26379。
1SENTINEL MASTERS1SENTINEL MASTER mymaster1SENTINEL REPLICAS mymaster旧版本也支持 SENTINEL SLAVES，新脚本建议使用 REPLICAS。
1SENTINEL SENTINELS mymaster1SENTINEL GET-MASTER-ADDR-BY-NAME mymaster应用或运维脚本可以通过该命令获取 Sentinel 当前认定的主节点。
1SENTINEL CKQUORUM mymaster该命令用于判断当前可用 Sentinel 数量是否足以完成故障转移。
1SENTINEL FAILOVER mymaster这是高风险操作。执行前必须确认主从状态、客户端切换能力、Sentinel 仲裁和数据差异。
1CLUSTER INFO重点关注：
1cluster_state2cluster_slots_assigned3cluster_slots_ok4cluster_slots_fail5cluster_known_nodes6cluster_size1CLUSTER NODES可以查看节点 ID、地址、角色、连接状态、配置纪元和负责的槽位。
1CLUSTER SHARDS该命令从 Redis 7.0 开始提供，用于替代结构相对固定的 CLUSTER SLOTS。
1CLUSTER MYID1CLUSTER MYSHARDID该命令适用于较新的 Redis 版本，旧环境执行前应先查询命令是否存在。
1CLUSTER REPLICAS <master-node-id>1CLUSTER KEYSLOT app:user:10001使用 Hash Tag 可以让多个 Key 落在同一槽位：
1app:{user:10001}:profile2app:{user:10001}:orders1CLUSTER COUNTKEYSINSLOT 10001CLUSTER GETKEYSINSLOT 1000 20主要用于槽位迁移和故障排查，不建议作为常规业务查询方式。
1redis-cli --cluster check 192.168.10.11:7000增加槽位覆盖检查：
1redis-cli --cluster check 192.168.10.11:7000 \2 --cluster-search-multiple-owners1redis-cli --cluster info 192.168.10.11:70001redis-cli --cluster rebalance 192.168.10.11:7000 \2 --cluster-use-empty-masters槽位迁移会产生网络和节点负载，生产执行前应先检查集群健康、容量差异和业务高峰。
1redis-cli -h 192.168.10.10 -p 6379 --stat可以持续观察 Key 数量、内存、客户端数、阻塞客户端、请求量、网络流量和命中率变化。
1redis-cli -h 192.168.10.10 -p 6379 --latency查看延迟随时间变化：
1redis-cli -h 192.168.10.10 -p 6379 --latency-history1redis-cli --intrinsic-latency 60该命令应在 Redis 所在服务器本地执行，并会在测试期间持续占用一个 CPU 核心，不要在繁忙生产节点随意运行。
1redis-cli -h 192.168.10.10 -p 6379 --hotkeys该功能依赖 LFU 频率计数，通常要求淘汰策略使用 LFU。输出结果只能作为热点排查线索。
1redis-benchmark \2 -h 192.168.10.10 \3 -p 6379 \4 -c 50 \5 -n 100000 \6 -t get,set \7 -qredis-benchmark 只能反映指定模型下的基准性能，不能代表真实业务。严禁在未评估影响的生产实例上直接执行高并发压测。
这 100 条命令基本覆盖了 Redis 日常巡检和故障排查中最常用的入口，但 Redis 运维最重要的并不是背命令，而是理解每条命令是否会阻塞主线程、扫描多少 Key、消耗多少内存、触发多少网络流量，以及是否会改变复制和集群状态。
排查 Redis 问题时，可以按照“确认实例角色和拓扑、查看 INFO 指标、检查客户端和慢日志、定位大 Key 与热 Key、分析持久化和复制、最后检查操作系统”的顺序进行。对于 KEYS、MONITOR、FLUSHALL、大 Key 的 DEL、CONFIG SET、REPLICAOF、SENTINEL FAILOVER 和集群槽位迁移等操作，必须先评估风险，不能直接在生产环境照搬执行。
另外，Redis Open Source 8 已经整合了原 Redis Stack 的搜索、JSON、时间序列和概率数据结构等能力，但很多生产环境仍在运行 Redis 6.2、7.2 或 7.4。现场执行时，应先通过 INFO server 确认版本，并以当前版本官方文档和命令帮助为准。