關於master/slave的failover，redis cluster通過cluster-node-timeout設置節點間狀態檢測超時。 如果在redis中執行命令比較耗時，比如超過cluster-node-timeout時長，集羣master和slave很容易觸發failover，頻繁的failover容易導致集羣狀態的變化。
爲了驗證集羣的變化，可以通過如下加負載lua腳本來模擬一些測試場景：
[root@zhannk create-cluster]# ../../src/redis-cli -h 192.168.100.70 -p 30003
192.168.100.70:30003> eval "local key=KEYS[1] ;local s=tonumber(ARGV[1]); local e=tonumber(ARGV[2]); while s<e do redis.call('zadd',key,tostring(s),tostring(s));s=s+1;end;return redis.call('zrangebyscore',key,'-inf','+inf','withscores','limit',ARGV[3],ARGV[4])" 1 {thekey}.50 10 10000000 0 100
該腳本往{thekey}.50的zset裏寫入10000000條數據，並返回前100條( 腳本源自對用戶現場一個可疑zrangebyscore的操作驗證)。在默認cluster-node-timeout爲2s的情況下，可以明顯觀察到master/slave的不斷failover；同時數據的操作也容易失敗。
需要注意的是，類似上面的lua腳本會導致master和slave下的aof文件並不是完全一樣。redis在做master/slave同步時，並不是把master的aof文件簡單同步……特別是使用lua腳本的時候，在同步發生時，需關注slave節點aof文件大小問題。
master節點aof文件：
slave節點aof文件
redis cluster集羣維護工具redis-trib.rb簡單使用：
創建集羣：
redis-trib.rb create 192.168.100.254:30001 192.168.100.254:30002 192.168.100.70:30001
添加slave，trib腳本會自動調整合適master：
redis-trib.rb add-node --slave 192.168.100.254:30003 192.168.100.70:30001
再平衡數據：
redis-trib.rb rebalance 192.168.100.254:30001
slot異常修復：
redis-trib.rb fix 192.168.100.254:30001
cluster狀態檢查：
redis-trib.rb check 192.168.100.254:30001