Redis3.0以降のバージョンはクラスター機能を備えており、以前のバージョンのセンチネルモードよりも高いパフォーマンスと可用性を提供しますが、クラスターの水平方向の拡張はより面倒です。今日は、redisの高可用性クラスターがどのように機能するかを示します。拡張、元のクラスター（下の図を参照）は、3つのマスターと3つのスレーブモデルを使用して、3つのマシンに分散された6つのノードで構成されます。
1.クラスターを開始します
＃クラスター全体を開始します
cd /usr/local/redis-cluster
bin/redis-server 9001/redis.conf
bin/redis-server 9002/redis.conf
bin/redis-server 9003/redis.conf
bin/redis-server 9004/redis.conf
bin/redis-server 9005/redis.conf
bin/redis-server 9006/redis.conf＃クライアントはポート9001のredisインスタンスに接続します
bin / redis-cli -a smsp -c -h 10.18.4.25 -p 9001
上の図からわかるように、クラスター全体が正常に動作しており、3つのマスターノードと3つのスレーブノードがあります。ポート9001のインスタンスノードはハッシュスロット0〜5460を格納し、ポート9002のインスタンスノードはハッシュスロット5461-を格納します。 10922およびポート9003。インスタンスノードはハッシュスロット10923-16383を格納します。3つのマスターノードによって格納されたすべてのハッシュスロットは、redisクラスターのストレージスロットを形成します。スレーブポイントは、各マスターノードのバックアップスレーブノードであり、ストレージスロットは表示されません。
2.クラスター操作
元のクラスターに基づいてマスター（9007）とスレーブ（9008）を追加します。ノードを追加した後のクラスターを次の図に示します。新しいノードは破線のボックスで表されます。
redisインスタンスを増やす
2つのノード9007と9008は10.18.4.28マシンに配置され、作成プロセスは最初の3つのグループとまったく同じで、作成後に開始します。
redisクラスターのコマンドヘルプを表示する
cd /usr/local/redis-5.0.0
src / redis-cli--clusterヘルプ
- create：クラスター環境を作成しますhost1：port1 ... hostN：portN
- 呼び出し：redisコマンドを実行できます
- add-node：ノードをクラスターに追加します。最初のパラメーターは新しいノードのip：portであり、2番目のパラメーターはクラスター内の既存のノードのip：portです。
- del-node：ノードを削除します
- リシャード：リシャード
- チェック：クラスターのステータスを確認します
9007をクラスターマスターノードとして構成します
＃add-nodeコマンドを使用してマスターノード9007（マスター）を追加します。緑は新しいノード、赤は既知のノードです。ログの最後に「[OK]新しいノードが正しく追加されました」と表示されます。新しいノードが正しく追加されたことを示します
bin / redis-cli -a smsp --cluster add-node 10.18.4.28:9007 10.18.4.25:9001
＃クラスターステータスの表示
注：ノードが正常に追加されると、新しいノードにはデータがありません。スロット（ハッシュスロット）が割り当てられていないため、新しいノードにハッシュスロットを手動で割り当てる必要があります。
＃redis-cliコマンドを使用して9007にハッシュスロットを割り当て、クラスター内のマスターノードを見つけ（赤い位置はクラスター内のマスターノードを示します）、それを再シャーディングします。
[root @ smsp-dev001-10 redis-cluster] ＃bin / redis-cli -a smsp --cluster reshard 10.18.4.25:9001
出力は次のとおりです。
.....。
いくつのスロットを移動しますか（1から16384）？600
（ps：600ハッシュスロットなど、自分で設定した、新しいノードに移動するために必要なスロットの数）
受信ノードIDは何ですか？ 7430f93681e95eb176ce036d171bf126ae67697d
（ps：これらの600個のハッシュスロットを移動するノード。ノードIDを指定する必要があります。これが9007ノードのIDです）
すべての送信元ノードIDを入力してください。
ハッシュスロットのソースノードとしてすべてのノードを使用するには、「all」と入力します。
すべてのソースノードIDを入力したら、「done」と入力します。
ソースノード1：すべて
（ps：allを入力して、すべてのマスターノード（9001、9002、9003）から対応する数のスロットを抽出し、それらを新しいノードに割り当てます。抽出されるスロットの総数は600です）
.....。
提案されたリシャードプランを続行しますか（はい/いいえ）？はい
（ps：シャーディングタスクの開始を確認するには、yesと入力します）
＃最新のクラスターステータスを表示する
上の図に示すように、9007にはハッシュスロットがあります。これは、9007でデータの読み取りと書き込みができることを意味します。これまでのところ、9007がクラスターに追加されており、マスターノード（マスター）です。
9008は9007のスレーブノードです
＃スレーブノード9008をクラスターに追加し、クラスターのステータスを表示します
[root @ smsp-dev001-10 redis-cluster] ＃bin / redis-cli -a smsp --cluster add-node 10.18.4.28:9008 10.18.4.25:9001
図に示すように、それはまだマスターノードであり、ハッシュスロットは割り当てられていません。
＃レプリケートコマンドを実行して、現在のノード（スレーブノード）のマスターノードIDを指定する必要があります。最初に、新しく追加された9008ノードのクライアントに接続し、次にclusterコマンドを使用して操作し、割り当てます。現在の9008（スレーブ）ノードからマスターノードの下へ（ここでは以前に作成された9007マスターノードが使用され、赤はノードIDを示します）
bin / redis-cli -a smsp -c -h 10.18.4.28 -p 9008
10.18.4.28:9008>クラスターレプリケート7430f93681e95eb176ce036d171bf126ae67697d
＃クラスターステータスを表示します。9008ノードが9007ノードのスレーブノードとして正常に追加されました
9008スレーブノードを 削除します
＃del-nodeを使用してスレーブノード9008を削除し、削除ノードのIPとポート、およびノードIDを指定します（赤は9008ノードID）
bin / redis-cli -a smsp --cluster del-node 10.18.4.28:9008 8ff4bb628a9c22828ca434674bfd60cc1c52fd25
＃下の図に示すように、クラスターのステータスを再度確認します。スレーブノード9008が削除され、このノードのredisサービスも停止されています。
9007マスターノードを削除します
最後に、以前に追加したマスターノード9007を削除しようとします。この手順は比較的面倒です。マスターノードにはハッシュスロットが割り当てられているため、最初に9007のハッシュスロットを他の使用可能なマスターに配置する必要があります。ノードに移動し、次に、ノード操作を削除します。そうしないと、データ損失の問題が発生します（現在、マスターのデータのみを1つのノードに移行でき、平均分散機能を一時的に実行できません）。次のようにコマンドを実行します。
bin / redis-cli -a smsp --cluster reshard 10.18.4.28:9007
出力は次のとおりです。
.....。
いくつのスロットを移動しますか（1から16384）？ 600
受信ノードIDは何ですか？ 2349fa527eebba23a4c2749c56c9ee5a8b0d1812
（ps：ここに移動するデータはどこにありますか？9001のマスターノードのID）
すべての送信元ノードIDを入力してください。
ハッシュスロットのソースノードとしてすべてのノードを使用するには、「all」と入力します。
すべてのソースノードIDを入力したら、「done」と入力します。
ソースノード1：7430f93681e95eb176ce036d171bf126ae67697d
（ps：これがデータソースです。これは9007ノードIDです）
ソースノード2：完了
（ps：移行計画の生成を開始するには、ここで「done」と直接入力してください）
.....。
提案されたリシャードプランを続行しますか（はい/いいえ）？はい
（ps：ここにyesと入力して、移行を開始します）
この時点で、9007マスターノードのデータを8001に正常に移行しました。次の図に示すように、現在のクラスターステータスを確認できます。9007の下にハッシュスロットがないことがわかります。これは、移行は成功しました！
＃最後に、del-nodeコマンドを直接使用して9007マスターノードを削除できます（赤は9007のノードIDを示します）。
bin / redis-cli -a smsp --cluster del-node 10.18.4.28:9007 7430f93681e95eb176ce036d171bf126ae67697d
＃クラスターのステータスを確認すると、すべてが初期状態に復元されます。それでおしまい！
＃このとき、9001、9002、9003のスロットが等しくないことがわかり、リバランス操作を実行してスロットの負荷を分散することができます。（赤は存続しているノードです）
bin / redis-cli -a smsp --cluster rebalance 10.18.4.25:9001
9007が削除されたばかりのときに、その上の600スロットが9001に移動されたため（現在、複数のターゲットノードへの移動はサポートされていません）、9001のスロットの一部が9002および9003に移動されたことがわかります。
スロットの分布をもう一度確認してください。均等に分布しています。
3.Redisクラスター選挙の原則の分析
スレーブは、マスターがFAILステータスになることを検出すると、新しいマスターになるためにフェイルオーバーを試みます。ハングしたマスターには複数のスレーブがある可能性があるため、複数のスレーブが競合してマスターノードになるプロセスがあります。プロセスは次のとおりです。
1.スレーブは、マスターがFAILになることを検出します
2.自分で記録したクラスターcurrentEpoch に1を追加し、FAILOVER_AUTH_REQUEST 情報をブロードキャストします
3.他のノードが情報を受信すると、マスターのみが応答し（マスターノードのみが投票権を持ちます）、リクエスターの正当性を判断し、FAILOVER_AUTH_ACKを送信し、エポックごとに1回だけackを送信します。
4.スレーブをフェイルオーバーしてFAILOVER_AUTH_ACKを収集してみます
5.半分以上後に新しいマスターになる
6. Pongをブロードキャストして、他のクラスターノードに通知します。
クラスター情報はクラスターの選出サイクルをチェックできます！
スレーブノードは、マスターノードがFAIL状態に入るとすぐに選択を開始しようとはしませんが、特定の遅延があります。特定の遅延により、クラスター内でFAIL状態が伝播するのを確実に待機します。すぐに選出すると、他のマスターはFAIL状態に気付かない可能性があります。、投票を拒否する可能性があります
•遅延計算式：
DELAY = 500ms +ランダム（0〜500ms）+ SLAVE_RANK * 1000ms
•SLAVE_RANKは、このスレーブがマスターからコピーしたデータの合計量のランクを表します。ランクが小さいほど、コピーされたデータは新しくなります。ランクが小さいほど、遅延は小さくなります。このようにして、最新のデータを保持しているスレーブが最初に選択を開始します（理論上）。