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
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
添加主節點對應的從節點，需要登錄到每個主節點的實例上，執行
三個從節點分別加入到主節點之後，此時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更多的時候是作為一個緩存使用，而不是落地的數據庫，既然是緩存，就應該更多地去考慮性能。
Redis集群以及自動故障轉移測試