cluster nodes 输出是实时带版本语义的集群拓扑快照，共9+列空格分隔：id、ip:port、flags、master、ping-sent、pong-recv、config-epoch、link-state及slot范围；需交叉验证config-epoch、ping-sent与slot分布判断主从状态、失联节点、无槽master及脑裂风险。
CLUSTER NODES 输出不是日志，也不是状态快照，它是一份实时、带版本语义的集群拓扑快照。直接 human-readable 解析容易误判主从关系或忽略故障传播风险。
怎么看懂每行字段的含义和顺序
输出是空格分隔的 CSV 格式，每行 9+ 列（末尾可能追加多个 slot 范围），顺序固定：
-
id：40 字符节点唯一 ID，启动即生成，永不变更（除非CLUSTER RESET HARD） -
ip:port：客户端可连地址，注意@后是集群内部通信端口（如32521@42521） -
flags：逗号分隔标记，myself表示当前连接的节点，slave和master不互斥（比如myself,slave） -
master：若为 slave，则此处是 master 的id；否则为- -
ping-sent和pong-recv：毫秒级时间戳，值为0表示从未通信过，不是“正常”而是“未建立” -
config-epoch：关键字段，master 自增，slave 继承其 master 的 epoch；冲突时 epoch 大者胜出 -
link-state：仅两个值 ——connected或disconnected，不反映网络延迟 - 最后若干列是 slot 范围，如
0-5460、5461-10922，无 slot 的 master 会显示为空（但仍有connected）
为什么不能只靠 flags 判断主从角色
常见错误是看到 slave 就认为它是健康从节点 —— 实际上它可能已失联、未同步、甚至被降级为 fail? 状态。
-
fail?表示 PFAIL（可能失败），仅当前节点无法连通它；fail表示多数节点共识失败，已触发故障转移逻辑 - 一个节点同时带
slave和fail?，说明它仍是逻辑从节点，但数据已不可靠，config-epoch停滞不前 - 如果
master列是-，但flags含slave，说明该节点尚未完成握手，处于handshake过渡态，不能用于读
如何快速定位异常节点和槽分配问题
生产中真正要盯的是三类信号，不是“有没有 slave”，而是“谁在掉队、谁没槽、谁 epoch 卡住”：
- 查失联节点：
grep -v connected$或匹配disconnected，再结合ping-sent/pong-recv时间戳判断是否超时（例如 >30s 未收 pong） - 查无槽 master：
awk '$3 ~ /master/ && NF==8' | grep -v connected（8 列表示无 slot 分配） - 查 epoch 异常：
awk '$7 != "0" {print $1, $7}' | sort -k2,2n，观察是否有节点config-epoch明显落后（差值 ≥2 通常意味切换卡住） - 注意 slot 重叠：同一 slot 范围出现在多个 master 行，说明 rehash 未完成或出现脑裂，必须立刻干预
真正难的不是解析字段，而是把 config-epoch、ping-sent、slot 分布三者交叉验证 —— 比如一个节点 config-epoch 滞后但 pong-recv 很新，大概率是它刚被选为新 master 但尚未广播成功；反之，pong-recv 陈旧但 config-epoch 高，说明它已脱离集群但仍被部分节点引用。
