集群中的每个节点都有当前集群配置的一个视图（快照），视图的信息由该节点所有已知节点提供，包括与每个节点的连接状态，每个节点的标记位（flags)，属性和已经分配的哈希槽等等。
CLUSTER NODES提供了当前连接节点所属集群的配置信息，信息格式和Redis集群在磁盘上存储使用的序列化格式完全一样（在磁盘存储信息的结尾还存储了一些额外信息）.
通常，如果你想知道哈希槽与节点的关联关系，你应该使用CLUSTER SLOTS 命令。CLUSTER NODES主要是用于管理任务，调试和配置监控。redis-trib也会使用该命令管理集群.
*序列化格式
（该命令的）输出是空格分割的CSV字符串，每行代表集群中的一个节点。下面是一个示例:
07c37dfeb235213a872192d90877d0cd55635b91 127.0.0.1:30004@31004 slave e7d1eecce10fd6bb5eb35b9f99a514335d9ba9ca 0 1426238317239 4 connected
67ed2db8d677e59ec4a4cefb06858cf2a1a89fa1 127.0.0.1:30002@31002 master - 0 1426238316232 2 connected 5461-10922
292f8b365bb7edb5e285caf0b7e6ddc7265d2f4f 127.0.0.1:30003@31003 master - 0 1426238318243 3 connected 10923-16383
6ec23923021cf3ffec47632106199cb7f496ce01 127.0.0.1:30005@31005 slave 67ed2db8d677e59ec4a4cefb06858cf2a1a89fa1 0 1426238316232 5 connected
824fe116063bc5fcf9f4ffd895bc17aee7731ac3 127.0.0.1:30006@31006 slave 292f8b365bb7edb5e285caf0b7e6ddc7265d2f4f 0 1426238317741 6 connected
e7d1eecce10fd6bb5eb35b9f99a514335d9ba9ca 127.0.0.1:30001@31001 myself,master - 0 0 1 connected 0-5460
每行的组成结构如下:
<id> <ip:port@cport> <flags> <master> <ping-sent> <pong-recv> <config-epoch> <link-state> <slot> <slot> ... <slot>
每项的含义如下::
id: 节点ID,是一个40字节的随机字符串，这个值在节点启动的时候创建，并且永远不会改变（除非使用CLUSTER RESET HARD命令）。ip:port: 客户端与节点通信使用的地址.flags: 逗号分割的标记位，可能的值有:myself,master,slave,fail?,fail,handshake,noaddr,noflags. 下一部分将详细介绍这些标记.master: 如果节点是slave，并且已知master节点，则这里列出master节点ID,否则的话这里列出”-“。ping-sent: 最近一次发送ping的时间，这个时间是一个unix毫秒时间戳，0代表没有发送过.pong-recv: 最近一次收到pong的时间，使用unix时间戳表示.config-epoch: 节点的epoch值（or of the current master if the node is a slave）。每当节点发生失败切换时，都会创建一个新的，独特的，递增的epoch。如果多个节点竞争同一个哈希槽时，epoch值更高的节点会抢夺到。link-state: node-to-node集群总线使用的链接的状态，我们使用这个链接与集群中其他节点进行通信.值可以是connected和disconnected.slot: 哈希槽值或者一个哈希槽范围. 从第9个参数开始，后面最多可能有16384个 数(limit never reached)。代表当前节点可以提供服务的所有哈希槽值。如果只是一个值,那就是只有一个槽会被使用。如果是一个范围，这个值表示为起始槽-结束槽，节点将处理包括起始槽和结束槽在内的所有哈希槽。
各flags的含义 (上面所说数据项3):
myself: 当前连接的节点.master: 节点是master.slave: 节点是slave.fail?: 节点处于PFAIL状态。 当前节点无法联系，但逻辑上是可达的 (非FAIL状态).fail: 节点处于FAIL状态. 大部分节点都无法与其取得联系将会将改节点由PFAIL状态升级至FAIL状态。handshake: 还未取得信任的节点，当前正在与其进行握手.noaddr: 没有地址的节点（No address known for this node）.noflags: 连个标记都没有（No flags at all）.
*发布的config epochs的说明
slave节点在广播时，总是使用其所属master节点的config epochs值（主要是让master节点判断一下，其所持有的数据是否已经过期），所以如果你想知道slave节点本身真实的config epochs值（虽然没有什么意义，因为slave节点本身不处理哈希槽），你必须直连到该slave节点，然后执行CLUSTER NODE命令。除了直连的节点之前，命令打印出的epochs值仅仅是其他节点在心跳包中发出的值，这个值是其所属master节点的config epochs值。
*特殊的哈希槽条目格式
通常情况下每个节点分配的哈希槽形式如下:
- 单哈希槽，如: 3894
- 范围，如: 3900-4000
但是还有两个特殊状态，是在节点被重启后，需要与其他节点确认错误的信息时（从AOF/RDB文件恢复时，发现keys的分布与节点哈希槽配置不匹配），或者当前节点正在重新分片时的需要的状态，分别是迁入（importing）和迁出（migrating）。
这两个状态的含义在Redis集群规范中也有解释，下面再详细介绍一下:
- Importing 槽位还没有被分配给该节点,但是正在被迁入至当前节点。只有使用
ASK命令时，才能查询这些正在迁入的槽位。 - Migrating 槽位属于当前节点，但是正在被迁移至其他节点。只有当请求的所有key都在当前节点时，请求才会被正确响应，否则的话将使用ASK redirection强制客户端重定向至迁入节点。
状态为importing和migrating的节点在收到CLUSTER NODES命令后，输出如下:
- 迁入节点输出:
[slot_number-<-importing_from_node_id] - 迁出节点输出:
[slot_number->-migrating_to_node_id]
下面是一个简单示例:
[93-<-292f8b365bb7edb5e285caf0b7e6ddc7265d2f4f][1002-<-67ed2db8d677e59ec4a4cefb06858cf2a1a89fa1][77->-e7d1eecce10fd6bb5eb35b9f99a514335d9ba9ca][16311->-292f8b365bb7edb5e285caf0b7e6ddc7265d2f4f]
请注意，输出的字符串不包含任何空格，所以CLUSTER NODES的输出仅仅是一个空格分割的CSV，即便是特殊状态的节点也遵循这个规律。.
备注:
- 只有节点为
myself的节点才会才会被迁出和迁入，相对于节点的哈希槽，这是哈希槽所属节点的本地局部变量(Migration and importing slots are only added to the node flagged asmyself. This information is local to a node, for its own slots)。 - 如果一个节点正在迁出或者迁入哈希槽，则这些信息只会在额外信息有所反映。如果哈希槽被分配到一个节点，并且正在迁出时，哈希槽的状态跟没有发生迁移时的状态一样，不会有什么特殊提示给客户端。
*返回值
多行字符串: 序列化的集群配置信息
A note about the word slave used in this man page and command name: Starting with Redis 5, if not for backward compatibility, the Redis project no longer uses the word slave. Unfortunately in this command the word slave is part of the protocol, so we'll be able to remove such occurrences only when this API will be naturally deprecated.