cluster nodes命令

集群中的每個節點都有當前集群配置的一個視圖（快照），視圖的信息由該節點所有已知節點提供，包括與每個節點的連接狀態，每個節點的標記位（flags)，屬性和已經分配的哈希槽等等。

CLUSTER NODES提供了當前連接節點所屬集群的配置信息，信息格式和Redis集群在磁盤上存儲使用的序列化格式完全一樣（在磁盤存儲信息的結尾還存儲了一些額外信息）.

通常，如果你想知道哈希槽與節點的關聯關系，你應該使用CLUSTER SLOTS 命令。CLUSTER NODES主要是用於管理任務，調試和配置監控。redis-trib也會使用該命令管理集群.

序列化格式

（該命令的）輸出是空格分割的CSV字符串，每行代表集群中的一個節點。下面是一個示例:

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> <ip:port> <flags> <master> <ping-sent> <pong-recv> <config-epoch> <link-state> <slot> <slot> ... <slot>

每項的含義如下:

1. id: 節點ID,是一個40字節的隨機字符串，這個值在節點啟動的時候創建，並且永遠不會改變（除非使用CLUSTER RESET HARD命令）。
2. ip:port: 客戶端與節點通信使用的地址.
3. flags: 逗號分割的標記位，可能的值有: myself, master, slave, fail?, fail, handshake, noaddr, noflags. 下一部分將詳細介紹這些標記.
4. master: 如果節點是slave，並且已知master節點，則這里列出master節點ID,否則的話這里列出”-“。
5. ping-sent: 最近一次發送ping的時間，這個時間是一個unix毫秒時間戳，0代表沒有發送過.
6. pong-recv: 最近一次收到pong的時間，使用unix時間戳表示.
7. config-epoch: 節點的epoch值（or of the current master if the node is a slave）。每當節點發生失敗切換時，都會創建一個新的，獨特的，遞增的epoch。如果多個節點競爭同一個哈希槽時，epoch值更高的節點會搶奪到。
8. link-state: node-to-node集群總線使用的鏈接的狀態，我們使用這個鏈接與集群中其他節點進行通信.值可以是 connected 和 disconnected.
9. 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值。

特殊的哈希槽條目格式

通常情況下每個節點分配的哈希槽形式如下:

1. 單哈希槽，如: 3894
2. 范圍，如: 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，即便是特殊狀態的節點也遵循這個規律。.

備注:

1. 只有節點為myself的節點才會才會被遷出和遷入，相對於節點的哈希槽，這是哈希槽所屬節點的本地局部變量(Migration and importing slots are only added to the node flagged as myself. This information is local to a node, for its own slots)。
2. 如果一個節點正在遷出或者遷入哈希槽，則這些信息只會在額外信息有所反映。如果哈希槽被分配到一個節點，並且正在遷出時，哈希槽的狀態跟沒有發生遷移時的狀態一樣，不會有什么特殊提示給客戶端。