redis-cli --cluster check 更可靠，因其主动模拟槽位映射、逐节点握手并验证主从关系与槽覆盖完整性，而 cluster info 仅读取本地缓存易漏“幽灵槽”或跨节点不一致。
redis-cli --cluster check 为什么比 cluster info 更可靠
redis-cli --cluster check 不是简单查状态，而是主动模拟槽位映射、逐节点握手、验证主从关系和槽覆盖完整性。它会真正连接所有节点（包括从节点），检查每个 slot 是否有且仅有一个主节点负责，并确认从节点是否在正确复制对应主节点的数据。而 cluster info 只读取本地节点视角的元数据缓存，容易漏掉跨节点不一致或“幽灵槽”（slot 被标记为 assigned，但无节点实际服务）。
常见错误现象：集群 cluster_state: ok，但客户端频繁报 CLUSTERDOWN；cluster_slots_ok 显示 16384，但部分 key 写入失败——这往往是因为某个主节点宕机后，其从节点未成功 failover，但元数据还没来得及更新。
- 必须用集群中任意一个节点的地址 + 端口执行，不能加
-c（--cluster模式自带集群发现逻辑） - 若集群启用了密码，需显式传
-a <password></password>，否则部分节点握手会失败并静默跳过 - 输出末尾的
[OK]行才是最终结论；中间出现*** Notice:或*** Warning:都代表潜在风险，不能忽略
如何识别 check 输出里的关键异常信号
运行 redis-cli --cluster check 127.0.0.1:7001 -a mypass 后，重点盯以下几类行：
-
Slots coverage: 16383/16384→ 槽覆盖不全，立刻查缺失 slot 归属（看下一行 “The following slots are not covered”） -
M: xxxxxx ... 0-5460后面跟着-> 0或-> FAIL→ 该主节点声称负责这些 slot，但实际没被任何节点承认，说明它已失联或配置错乱 -
S: yyyyyy ... 0-5460出现在 slave 行但没有对应M:主节点 → 从节点悬空，无法接管 -
WARNING: The node has a non-zero ping_sent value→ 节点长时间未响应心跳，可能网络分区或进程卡住
注意：cluster nodes 输出里 ping-sent 和 pong-recv 时间戳差值超过 5 秒，就值得警惕；--cluster check 会把这类延迟直接转成 warning。
定期巡检脚本里必须校验的退出码和关键词
redis-cli --cluster check 的退出码不是 0/1 二元判断：它成功完成全部检查且无 warning 是 0；有 warning 是 1；遇到致命错误（如无法连接任一节点）是 124。只靠 $? 判断不够，必须 grep 关键词：
- 必须包含
"Slots coverage: 16384/16384"—— 这是健康底线 - 不能包含
"FAIL"（大写，排除正常日志里的单词）或"Warning"（首字母大写） - 建议同时检查
"M:"行数是否等于cluster_size值，防止节点元数据残留
示例片段（Bash）：
output=$(/usr/local/bin/redis-cli --cluster check $HOST:$PORT -a "$PASS" 2>&1)<br> if ! echo "$output" | grep -q "Slots coverage: 16384/16384"; then<br> echo "CRITICAL: slot coverage incomplete" >&2<br> exit 2<br> fi<br> if echo "$output" | grep -q -E "(FAIL|Warning)"; then<br> echo "WARNING: check reported anomalies" >&2<br> exit 1<br> fi
什么时候不能只依赖 --cluster check
--cluster check 是强一致性快照，但它不反映实时负载或慢请求堆积。比如所有 slot 都 ok，但某个主节点 CPU 持续 100%、latency latest 超过 500ms，--cluster check 完全不会报警。
真正线上可用的监控必须组合使用：
- 每分钟跑一次
--cluster check（低频，避免压测式扫描） - 每 10 秒采集一次各节点的
INFO replication和INFO stats，关注master_last_io_seconds_ago和rejected_connections - 对 client 端错误率做聚合（如
CLUSTERDOWN出现频率突增），这是最真实的业务视角
最容易被忽略的一点：检查脚本本身运行在哪个网络环境。如果监控机和 Redis 集群不在同一内网，DNS 解析延迟或防火墙策略可能导致 --cluster check 连接部分节点超时，误报为节点不可达——务必先用 telnet 或 nc 验证所有 host:port 可达。
