環境相關：

OS：CentOS release 7.4.1708
IP：192.168.77.101/102/103
MEM：16G
DISK：50G

簡單說明

參照《Redis4.0 三主三備叢集安裝配置》配置三節點主機6個redis例項並啟動
第五步配置叢集使用本博文操作進行

叢集建立

1，在節點一上建立單例項叢集：

cp -av /usr/local/redis/src/redis-trib.rb /usr/local/bin
redis-trib.rb create --replicas 0 192.168.77.101:7000
# 建立一個單例項叢集會報錯，因為redis的叢集需要至少3個master例項
 

# 該報錯可以忽略掉，使用fix命令進行修復

redis-trib.rb fix 192.168.77.101:7000
# 使用fix命令修復叢集，需要互動式輸入yes進行確認

redis-cli -c -h 192.168.77.101 -p 7000 cluster nodes
redis-trib.rb check 192.168.77.101:7000
# 檢視叢集狀態，目前叢集只有一個master例項，所有的資料槽都在該例項上
# 單例項叢集建立就完成了

2，新增兩個主節點：

redis-trib.rb add-node 192.168.77.102:7002 192.168.77
 
.101:7000
redis-trib.rb add-node 192.168.77.103:7004 192.168.77.101:7000
# 使用add-node命令，將102的7002和103的7004新增到叢集裡
redis-trib.rb check 192.168.77.101:7000
# 檢視叢集狀態，發現目前叢集中有三個master例項，但是所有的slot都在第一個master之上
# 此時，新加入的兩個master例項沒有任何的slot，是可以直接刪掉的
redis-trib.rb reshard 192.168.77.101:7000
# 使用reshard命令重新分配slot，需要互動輸入重新分配的slot數量和接收例項以及來源例項
 

# 兩次使用該命令，將新新增的兩個例項都分配一定數量的slot

輸入需要重新分配的slot數量

輸入接收這些slot的例項ID

輸入這些slot的來源例項ID

確認移動

如果是真實的生產環境，在移動資料槽的時候，有可能會超時失敗，如移動1000個數據槽到另外一個主例項
原因是某個或某些資料槽佔用記憶體較大，移動操作超時，就需要使用fix命令進行修復
超時失敗不會對叢集造成影響，已經移動成功的資料槽狀態也是沒問題的
可以修復後再次重新分佈資料槽，減少資料槽的數量，防止再次超時失敗

redis-trib.rb fix 192.168.77.101:7000
redis-trib.rb check 192.168.77.101:7000
# 檢查叢集節點狀態，發現三個master例項都有slot存在，此時就不能直接刪除master例項

3，新增三個從例項：

redis-trib.rb add-node --slave 192.168.77.101:7001 192.168.77.101:7000
redis-trib.rb add-node --slave 192.168.77.102:7003 192.168.77.101:7000
redis-trib.rb add-node --slave 192.168.77.103:7005 192.168.77.101:7000
# 新增三個slave例項，每個slave例項會自動分配到一個master例項之下
redis-cli -c -h 192.168.77.101 -p 7000 cluster nodes|sort -k2
redis-trib.rb check 192.168.77.101:7000
# 檢視叢集節點狀態

4，生成叢集狀態報表：
此時的資訊輸出太多了，可以對cluster nodes命令的輸出結果做一下轉換，生成狀態報表

redis-cli -c -h 192.168.77.101 -p 7000 cluster nodes|\
awk 'BEGIN{print"節點 角色 自身ID 掛接的主例項ID"}
     {if($4=="-") {print $2,$3,$1,$1} 
      else        {print $2,$3,$1,$4}}'|\
sort -rk4|column -t
# 檢視叢集狀態，主備關係# 當自身ID和掛接的主例項ID相同時，代表本例項是一個master例項# 否則代表本例項是一個slave例項

5，手動調整master例項和slave例項之間的關係
當一個節點上存在兩個以上的例項的時候，如果執行期間發生了宕機例項切換
會產生一個節點上執行多個master例項或者一個節點全部都是slave的情況
或者出現一個節點上的兩個例項正好是一對master例項和slave例項
此時就需要手動調整master例項和slvae例項之間的對應關係，以免在節點故障時產生不可用的情況

redis-cli -c -h 192.168.77.101 -p 7001 cluster replicate 45c239f2a6637cb8c5209c7ccd5754acfbaeb6b4
redis-cli -c -h 192.168.77.102 -p 7003 cluster replicate 8af251aab2566469e8742abc80737acc9f7b60a2
redis-cli -c -h 192.168.77.103 -p 7005 cluster replicate 48c93c36580fc7314307ed4eeae6363b15b1be50
# 根據 生成叢集狀態報表 命令檢視叢集狀態，驗證切換操作

6，手動宕機master例項，檢視叢集熱切：

redis-cli -c -h 192.168.77.102 -p 7002 debug segfault
# 將102的7002例項停機
# 根據 生成叢集狀態報表 命令檢視叢集狀態，驗證叢集熱切
# 發現角色一欄102的7002例項 出現 master,fail 資訊
# 該例項原本的slave例項現在變成的master例項，叢集熱切成功

節點2將停掉的例項啟動

/usr/local/bin/redis-server /usr/local/redis/redis_cluster/redis_7002.conf
# 根據 生成叢集狀態報表 命令檢視叢集狀態，檢視叢集狀態
# 發現停掉的例項啟動後變成了slave狀態的例項

叢集刪除

1，刪除slave例項：

redis-trib.rb del-node 192.168.77.101:7000 45c239f2a6637cb8c5209c7ccd5754acfbaeb6b4
redis-trib.rb del-node 192.168.77.101:7000 d65247f83fbe5f3c9bc0b25c8ffbd3aace203bea
redis-trib.rb del-node 192.168.77.101:7000 a1c5ede35007ba6c1bf6d9fad907dbe09f7c6f62
# slave角色的例項可以直接刪除
# 例項從叢集刪除後，例項會關閉

2，刪除master例項：

redis-trib.rb reshard 192.168.77.101:7000
# 需要將即將刪除的master例項上的slot移動到其他master例項上
# 當master例項上有slot存在時，是無法刪除的
redis-trib.rb check 192.168.77.101:7000
# 檢視待刪除的例項上已經沒有slot了
redis-trib.rb del-node 192.168.77.101:7000 f2b7cb07b0f3a16c7c650df205ef269933d5badc
redis-trib.rb del-node 192.168.77.101:7000 8af251aab2566469e8742abc80737acc9f7b60a2
# 根據 生成叢集狀態報表 命令檢視叢集狀態 只剩下一個master例項了
redis-cli -c -h 192.168.77.101 -p 7000 debug segfault
# 將最後一個master例項關閉

3，殘餘資訊刪除：
例項刪除後，存在殘餘資訊，需要刪除才可以做叢集的再次建立新增等操作
這些殘餘資訊是例項執行產生的，因此三個節點主機都要刪除快取資訊

cd /usr/local/redis/run/data
rm -rf nodes*.conf
# 刪除叢集配置資訊
rm -rf dump*.rdb
# 刪除記憶體快照
rm -rf appendonly*.aof
# 刪除aof日誌檔案
cd ..
rm -rf log/redis*.log
# 刪除例項執行日誌
tree

簡單總結

從本次實驗可以看出，redis叢集其實沒有對master數量和slave數量做限制
兩種例項的新增和刪除比較靈活，可以根據記憶體的使用情況增加master，然後遷移資料槽
當然被新增的master的記憶體限額也是沒有限制的，可以根據實際生產負載新增翻倍記憶體限額的master
slave一般要和master記憶體限額一樣大，因為slave在master宕機後會自動切換成master
為了叢集安全，一般一個master至少有一個slave，而且要保證slave不會先於master宕機
如果一個master的所有slave都已經宕機，此時master再宕機的話就會對服務產生影響了

[TOC]