redis：cluster nodes

亦凉 2022-09-17 03:11 182阅读 0赞

# 作用 #

cluster nodes ：列出集群当前已知的所有节点（ node），以及这些节点的相关信息

*  集群中的每个节点都有当前集群配置的一个视图（快照），视图的信息由该节点所有已知节点提供，包括与每个节点的连接状态，每个节点的标记为(flags)、属性和已经分配的哈希槽等等
 *  cluster nodes提供了当前连接节点所属集群的配置信息，信息格式和redis集群在磁盘上存储使用的序列化格式完全一样（在磁盘存储信息的结尾还存储了一些额外信息）
 *  通常，如果你想知道哈希槽与节点的管理关系，你应该使用CLUSTER SLOTS命令
 *  cluster nodes主要是用于管理任务、调试和配置监控。

序列化格式：

*  该命令输出的是空格分隔的CSV字符串，每行代表集群中的一个节点
 *  如果重启服务器，只要nodes.conf没有被删除，那么就会复用这个，也就是节点ID不会变

# 实例 #

// 只有一个节点而且没有分配槽位
    127.0.0.1:6380> cluster nodes
    447c827edc4fd98e49633bab1ece5ad705b48ac4 :6380@16380 myself,master - 0 0 0 connected 5368 5798 6257 7142 9670 10918 12539
    127.0.0.1:6380> 
    
    
    //-----所有槽位都分配到当前节点之后
    127.0.0.1:6380> cluster nodes
    447c827edc4fd98e49633bab1ece5ad705b48ac4 :6380@16380 myself,master - 0 0 0 connected 0-16383
    
    > cluster nodes
    07c37dfeb235213a872192d90877d0cd55635b91 127.0.0.1:30004 slave e7d1eecce10fd6bb5eb35b9f99a514335d9ba9ca 0 1426238317239 4 connected
    67ed2db8d677e59ec4a4cefb06858cf2a1a89fa1 127.0.0.1:30002 master - 0 1426238316232 2 connected 5461-10922
    292f8b365bb7edb5e285caf0b7e6ddc7265d2f4f 127.0.0.1:30003 master - 0 1426238318243 3 connected 10923-16383
    6ec23923021cf3ffec47632106199cb7f496ce01 127.0.0.1:30005 slave 67ed2db8d677e59ec4a4cefb06858cf2a1a89fa1 0 1426238316232 5 connected
    824fe116063bc5fcf9f4ffd895bc17aee7731ac3 127.0.0.1:30006 slave 292f8b365bb7edb5e285caf0b7e6ddc7265d2f4f 0 1426238317741 6 connected
    e7d1eecce10fd6bb5eb35b9f99a514335d9ba9ca 127.0.0.1:30001 myself,master - 0 0 1 connected 0-5460

# 返回值 #

格式：

*  id：节点ID，是一个40字节的随机字符串，这个值在节点启用的时候创建，并且永远不会改变（除非`CLUSTER RESET HARD`被使用/配置文件被删除）
 *  ip:port：客户端与节点通信使用的地址
 *  `flags`：逗号列表分隔的标志：`myself`，`master`，`slave`，`fail?`，`fail`，`handshake`，`noaddr`，`noflags`
    
     *  myself：当前连接的节点
     *  master：节点是master
     *  `slave`：节点是从属的。
     *  `fail?`：节点处于`PFAIL`状态。当前节点无法连续，但逻辑上是可达的（非FAIL状态）
     *  `fail`：节点处于`FAIL`状态。大部分节点都无法与其取得联系将会改节点由PFAIL状态升级为FAIL状态
     *  handshake：还未取得信任的节点，当前正在与其进行握手
     *  `noaddr`：此节点没有已知的地址。（no address know for this node）
     *  `noflags`：根本没有标志。（no flags at all）
 *  ping-sent：最近一次发送ping的时间，这个时间是一个unix毫秒时间戳，0代表没有发送过
 *  ping-recv：最近一次收到pong的时间，这个时间是一个unix毫秒时间戳，0代表没有发送过
 *  config-epoch：节点（或者当前节点的主节点）的epoch值。
    
     *  每当节点发生切换失败时，都会创建一个新的、独特的、递增的epoch
     *  如果多个节点竞争同一个哈希槽时，epoch值更高的节点会抢夺到
 *  link-state：用于节点到节点集群总线的链路状态。我们使用这个链接与集群中其他节点进行通信。值可以是`connected`或`disconnected`。
 *  slot：哈希槽值或者一个哈希槽范围。从第9个参数开始，后面最多可能有16384个（从来不会达到）
    
     *  代表当前节点可以提供服务的所有哈希槽值
     *  如果只是一个值，那就是只有一个槽会被使用
     *  如果是一个范围，这个值表示【起始槽-结束槽】，节点将处理包括起始槽和结束槽在内的所有哈希槽

### 发布的config epochs的说明 ###

*  slave节点在广播时，总是使用其所属master节点的config epochs（主要是让master节点判断一下，其所持有的数据是否已经过期）
 *  所以如果你想知道slave节点本身真实的config epochs（虽然没有什么意义，因为slaves节点本身不处理哈希槽），你必须直连到该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命令后，输出如下：

*  Importing**插槽：** `[slot_number-<-importing_from_node_id]`
 *  migrating**插槽：** `[slot_number->-migrating_to_node_id]`

以下是导入和迁移插槽的几个示例：

*  `[93-<-292f8b365bb7edb5e285caf0b7e6ddc7265d2f4f]`
 *  `[1002-<-67ed2db8d677e59ec4a4cefb06858cf2a1a89fa1]`
 *  `[77->-e7d1eecce10fd6bb5eb35b9f99a514335d9ba9ca]`
 *  `[16311->-292f8b365bb7edb5e285caf0b7e6ddc7265d2f4f]`

请注意，输出的字符串不包含任何空间，所以CLUSTER\_NODES的输出仅仅是一个空格分隔的CSV，即使是特殊状态的节点也遵循这个规律

备注：

*  只有节点为mysql的节点才会被迁入和迁出，相对于节点的哈希槽，这是哈希槽所属节点的本地局部变量
 *  如果一个节点正在迁入或者迁出哈希槽，则这些信息只会在额外信息有所反映，如果哈希槽被分配到一个节点，并且正在迁出时，哈希槽的状态跟没有发生迁移时的状态一样，不会有什么特殊提示给客户端