Redis叢集以及自動故障轉移測試
在Redis中，與相比Sentinel（哨兵）實現的高可用，叢集（cluster）更多的是強調資料的分片或者是節點的伸縮性，如果在叢集的主節點上加入對應的從節點，叢集還可以自動故障轉移，因此相比Sentinel（哨兵）還是有不少優勢的。
以下簡單測試Redis的叢集（單機多例項的模式），來體驗一下叢集的自動故障轉移功能，同時結合Python，來觀察自動故障轉移過程中應用程式端的表現。
redis叢集例項安裝
啟動6個redis叢集例項，叢集模式，除了正常的配置專案之外，需要在每個主節點中增加叢集配置
cluster-enabled yes # 開啟叢集模 cluster-node-timeout 1000# 節點超時時間，單位毫秒，設定一個較小的超時時間，目的是為了後面測試自動故障轉移的效果
分配slot & 主節點握手
主節點分配slot給主節點，三個主節點分配16383個slot
8001主----->8004從
8002主----->8005從
8003主----->8006從
#!/bin/bash for ((i=0;i<=16383;i++)) do if [ $i -le 5461 ]; then /usr/local/redis5_1/bin/redis-cli -h 127.0.0.1 -p 8001 -a root CLUSTER ADDSLOTS $i elif [ $i -gt 5461 ]&&[ $i -le 10922 ]; then /usr/local/redis5_1/bin/redis-cli -h 127.0.0.1 -p 8002 -a root CLUSTER ADDSLOTS $i elif [ $i -gt 10922 ]; then /usr/local/redis5_1/bin/redis-cli -h 127.0.0.1 -p 8003 -a root CLUSTER ADDSLOTS $i fi done
分配完slot之後，在第一個主節點上執行cluster meet 127.0.0.1 8002，cluster meet 127.0.0.1 8003
無須在其他兩個主節點上meet另外兩個主節點，隨後三個主節點之間關係確定會自動確定，目前叢集中是三個主節點
新增主節點對應的從節點，需要登入到每個主節點的例項上，執行
三個從節點分別加入到主節點之後，此時6個節點全部加入到叢集中
Python連線至叢集測試
這裡需要安裝redis-py-cluster依賴包
#!/usr/bin/env python3
import time
from time import ctime,sleep
from rediscluster import StrictRedisCluster
startup_nodes = [
{"host":"111.231.253.***", "port":8001},
{"host":"111.231.253.***", "port":8002},
{"host":"111.231.253.***", "port":8003},
{"host":"111.231.253.***", "port":8004},
{"host":"111.231.253.***", "port":8005},
{"host":"111.231.253.***", "port":8006}
]
redis_conn= StrictRedisCluster(startup_nodes=startup_nodes, decode_responses=True,password="root")
for i in range(0, 100000):
try:
redis_conn.set('name' + str(i), str(i))
print('setting name' + str(i) +"--->" + time.strftime('%Y-%m-%d %H:%M:%S',time.localtime(time.time())))
except:
print("connect to redis cluster error")
time.sleep(2)
執行上述寫入測試指令碼之後，資料基本上均勻地落在三個節點上
自動故障轉移測試
修改Python指令碼，每隔1s寫入一條資料，目的是便於觀察在主節點宕機，叢集自動故障轉移這個時間段之之內（1s鐘左右），對於應用程式的影響，或者說應用程式在自動故障轉移前後的表現。
如下指令碼迴圈往Redis叢集中寫入資料，執行期間，強制殺掉一個主節點，觀察應用程式連線情況。
同時，如果發生異常，暫停應用程式2s，因為上面一開始配置的叢集故障轉移時間是1s，如果應用程式暫停2s，完全可以跳過故障轉移的過程，
當故障轉移完成之後，應用程式又恢復成正常狀態，雖然8001節點宕機，應用程式繼續連線8001節點，但是應用程式完全無感知。
import time
from time import ctime,sleep
from rediscluster import StrictRedisCluster
startup_nodes = [
{"host":"111.231.253.***", "port":8001},
{"host":"111.231.253.***", "port":8002},
{"host":"111.231.253.***", "port":8003},
{"host":"111.231.253.***", "port":8004},
{"host":"111.231.253.***", "port":8005},
{"host":"111.231.253.***", "port":8006}
]
redis_conn= StrictRedisCluster(startup_nodes=startup_nodes, decode_responses=True,password="root")
for i in range(0, 100000):
try:
redis_conn.set('name' + str(i), str(i))
print('setting name' + str(i) +"--->" + time.strftime('%Y-%m-%d %H:%M:%S',time.localtime(time.time())))
time.sleep(1)
except:
print("connect to redis cluster error")
time.sleep(2)
發現在殺掉主節點之後，僅發生了一次連線錯誤，隨後因為Redis叢集的自動故障轉移成功，對應於程式來說是透明的，因此應用程式隨後正常工作，不受其中一個主節點宕機的影響。
叢集此時的狀態，8001節點宕機，明顯，8001對應的從節點8004接管主節點，升級為master，對外提供服務
觀察升級為主節點的8004例項日誌，會發現在強制殺掉原8001主節點之後，1秒鐘之內，成功替代8001升級為master節點
如果在故障轉移的過程中，沒有應用程式訪問Redis，應用程式甚至完全不知道Redis叢集發生了故障轉移，只要不發生叢集中某一個節點的主從節點同時宕機，整個叢集就沒有問題，且對應用程式完全透明。
隨後重啟宕機的8001節點，會發現8001節點自動變為其原從節點（8004）的從節點
整體上來看，Redis叢集的配置和使用以及自動故障轉移還是比較簡單易容的，這裡沒有用redis-trib.rb 而是採用手動分配slot和建立叢集的方式，目的是瞭解完整的配置流程。
需要注意的是：
1，如果開啟了密碼驗證模式，所有的主從節點必須配置masterauth，因為某一個節點宕機重啟之後，會自動變為從節點，此時如果想要從master複製資料，就必須需要主節點的密碼
2，StrictRedisCluster決定了所有主從節點的密碼必須要是一樣的。
表面上看Redis叢集簡單易用，自動故障轉移是沒有問題的，保證了高可用，看似沒有問題。
如果細想，這個過程還是有問題的，有沒有發現，雖然故障轉移保證了高可用，但是當從節點升級為主節點之後，如果保證升級為主節點的從節點（8004）一定能夠完全複製原主節點（8001）上的資料？
這個就類似於MySQL的半同步複製，主節點上的資料，一定要同步（雖然是relaylog）到從節點，主節點才會提交。
不過回頭想想，取決於如何去對待Redis或者怎麼使用Redis，Redis更多的時候是作為一個快取使用，而不是落地的資料庫，既然是快取，就應該更多地去考慮效能。