1つのスタンドアロンモード
redisをインストールして起動し、ビジネスに電話するだけです
何が問題ですか？
- 単一のマシンの障害
- 容量のボトルネック
- QPSのボトルネック
これは、パフォーマンスと信頼性が低い一部のビジネスシステムにのみ適しています。
2つ、マスタースレーブレプリケーションモード
スタンドアロンモードでの単一マシンの障害の問題を解決することに加えて、次のような利点もあります。
- 読み取りと書き込みの分離
- 災害復旧バックアップ
ポート6379、6380、6381である1つのマスターと2つのスレーブを構築するとします。
6379マスターノードredis.conf構成ファイルを移動する必要はありません。2つのスレーブノード6380および6381のredis.conf構成ファイルに1行追加するだけです（マスターノードのIPポートを構成します）。
slaveof 127.0.0.1 6379
或
replicaof 127.0.0.1 6379(redis5.0之后)または、SLAVEOF host portコマンドを使用して、現在のサーバーを指定されたサーバーのスレーブサーバーに動的に変換します。SLAVEOF NO ONEコマンドを使用して、コピー機能をオフにします。
起動シーケンス：最初に6379マスターノードを起動し、次にスレーブノードを起動します。開始コマンド：./ redis-server ../conf/redis.conf
マスターノードを起動した後、スレーブノードを起動すると、図に示すように、6380が6379マスターノードのデータに接続して同期したことがログからわかります。
書き込み機能を再度テストします
マスターノードは書き込み可能ですが、スレーブノードは書き込みできません。ただし、スレーブノードはマスターノードによって書き込まれたデータを読み取ることができます。
マスターノードがダウンすると、redis全体が書き込み不能になります。
redisマスタースレーブレプリケーションモードのマスターノードを確認するにはどうすればよいですか？
図に示すように、redis-cli情報を実行します。
120.0.0.1:6381がマスターノードであることに注意してください。他のredisはスレーブノードです
3、センチネルモード
主に、マスタースレーブレプリケーションモードでマスターノードに障害が発生した後の書き込み不能の問題を改善するために使用されます。（マスターノードとスレーブノードにいくつかのセンチネルノードを追加するだけです）
（画像がありません。センチネルはそれ自体を除くすべてのノード（マスター、スレーブ、その他のセンチネルノード）を監視するはずです）
マスタースレーブレプリケーションに基づいて、センチネルモード（Redis 2.8以降）は自動障害回復を実現します。欠点は、書き込み操作の負荷を分散できず、ストレージ容量が1台のマシンによって制限されることです。
仕組み：各Sentinelは、 PINGコマンドを送信するすべての マスターサーバー、スレーブサーバ、 および他のセンチネルのインスタンス秒に一回の頻度で。
インスタンスが指定された時間（ミリ秒後のダウン）内に応答しない場合、そのインスタンスは主観的なオフラインとしてマークされます。十分な数の歩哨が指定された時間枠内に判断に同意した場合、それらはオフラインの客観的としてマークされます。
歩哨は、客観的にオフラインになっているマスターノードのすべてのスレーブノードに毎秒INFOコマンドを送信します。歩哨と他の歩哨は新しいマスターノードを選択するために投票し、残りのスレーブノードはデータ複製のために新しいマスターノードを指します。
短所：フェイルオーバー期間中、redisサービスは利用できません（数秒から10秒）
上記のマスタースレーブレプリケーションモードに基づいて、さらに3つの歩哨ノード、つまりポート26379、26380、および26381を構築します。
各センチネルのsentinel.conf構成ファイルに、次のコードを追加します（ポートとログは繰り返されないことに注意してください）
port 26379
#表示监控的主节点ip、端口 和判断下线需要2个哨兵都同意
sentinel monitor mymaster 127.0.0.1 6379 2
logfile "/root/redis6379/logs/sentinel.log"起動コマンド：./ redis-sentinel ../ conf / sentinel.conf（起動シーケンスは必要ありません）
3つの歩哨が開始された後、26379歩哨ログを確認し、図に示すように、6379マスターノード、2つのスレーブノード、および他の2つの歩哨ノードが監視されていることを確認します。
これは、1つのマスター、2つのスレーブ、3つのセンチネルノードを含むすべてのredisノードです。
マスターノードの障害のテスト
6379マスターノードを停止した後、26379センチネルログを確認します。図に示すように、新しいマスターノードが6381ノードとして選択されています。
6381ノードが書き込み可能になりました。
6379の元のマスターノードがオンラインになると、スレーブノードになります。
障害の移行が完了しました。
4、クラスターモード
クラスターモードredisは、書き込みを負荷分散できず、ストレージ容量が1台のマシンによって制限されるという問題を解決します。（センチネルモードのアップグレードバージョンは、フェイルオーバー中にredis全体を使用できないという問題を解決します）
クラスターの原則：データ共有は、データの断片化によって実行されます。
データシャーディング方法：クラスターのキースペースは16,384個のハッシュスロットに分割され、データは次のアルゴリズムによって異なるシャードに分割されます。
HASH_SLOT = CRC16(key) & 16384 CRC16は巡回チェックアルゴリズムです。ビット演算＆を使用して、モジュロ結果を取得します。
なぜ16384（2 ^ 14）スロットなのですか？
CRC16アルゴリズムによって生成されるハッシュ値は16ビットであり、2 ^ 16 = 65536値を生成できます。65536の代わりに16384を使用するのはなぜですか？
- redisクラスターは毎秒pingメッセージを送信しているため、スロットが多すぎると、ハートビートメッセージのヘッダーが大きくなりすぎて、帯域幅が無駄になります。
- redisマスターノードの数を1,000を超えることはお勧めしません。これにより、ハートビートメッセージが多すぎてネットワークが輻輳します。
マスターノードが3つある場合、ハッシュスロットは0-5461、5462-10922、および10923-16383の3つのセグメントに分割されます。
新しいマスターノードが追加された場合、スロットを再割り当てし、データを再移行する必要がありますが、サービスをオフラインにする必要はありません。再シャーディングにはredis-tribソフトウェアが必要です
redis-trib.rbの使用：https：//blog.csdn.net/huwei2003/article/details/50973967
クラスター：https：//www.cnblogs.com/cqming/p/11191079.html