redisの3つのクラスタ方式

redisの3つのクラスタ方式
redisには、主従複製、哨兵モード、クラスタの3つのクラスタ方式があります.
1.マスターコピー
主従レプリケーションの原理:
サーバからプライマリサーバに接続し、SYNCコマンドを送信します.マスターサーバはSYNCネーミングを受信すると、BGSAVEコマンドを実行してRDBファイルの生成を開始し、その後実行されたすべての書き込みコマンドをバッファで記録する.メインサーバBGSAVEの実行が完了すると、サーバからスナップショットファイルをすべて送信し、送信中に実行された書き込みコマンドを記録し続ける.サーバからスナップショットファイルを受信した後、古いデータをすべて破棄し、受信したスナップショットをロードします.プライマリ・サーバのスナップショットの送信が完了すると、バッファからの書き込みコマンドの送信が開始されます.サーバからスナップショットのロードを完了し、コマンドリクエストの受信を開始し、自主的なサーババッファへの書き込みコマンドを実行します.(サーバから初期化完了)プライマリ・サーバは、1つのライト・コマンドを実行するたびに同じライト・コマンドをサーバに送信し、受信したライト・コマンド(サーバから初期化完了後の操作)をサーバから受信して実行するプライマリ・セカンダリ・レプリケーションのメリットとデメリット: :は主従レプリケーションをサポートし、ホストは自動的にデータをスレーブに同期し、読み書き分離を行うことができ、Masterの読み取り操作圧力を分担するために、Slaveサーバはクライアントに読み取り専用操作のサービスを提供することができ、書き込みサービスは依然としてMasterによってSlaveを完了しなければならない.また、他のSlavesの接続と同期要求を受け入れることができ、これによってMasterの同期圧力を効果的に分担することができる.Master ServerはSlavesに非ブロックでサービスを提供しています.したがって、Master-Slave同期中も、クライアントはクエリーまたは変更リクエストを送信することができます.Slave Serverも同様に非ブロックでデータ同期を完了します.同期中にクライアントがクエリ要求を発行すると、Redisは同期前のデータ ：を返す
Redisは自動フォールトトレランスとリカバリ機能を備えておらず、ホストのダウンタイムはフロントエンドの部分的な読み書き要求に失敗し、マシンの再起動または手動でフロントエンドのIPを切り替えるのを待つ必要がある.ホストはダウンタイムして、ダウンタイムの前に一部のデータがタイムリーにスレーブに同期できなかったことがあって、IPを切り替えた後にまたデータの一致しない問題を導入して、システムの可用性を下げました.Redisはオンライン拡張をサポートするのが難しく、クラスタ容量が上限に達するとオンライン拡張が複雑になります.
2.歩哨モード
プライマリ・サーバがサービスを中断した後、プライマリ・サーバにアップグレードしてサービスを継続できますが、このプロセスでは手動で操作する必要があります.このため、Redis 2.8では、自動化されたシステムモニタリングと障害復旧機能を実現するための哨兵ツールが提供されています.
哨兵の役割はRedisシステムの運行状況を監視することである.その機能は以下の2つを含む.

（1）                 。 
（2）                       。

歩哨の働き方:
各Sentinel(歩哨)プロセスは、クラスタ全体のMasterプライマリサーバに毎秒1回の頻度で送信され、Slaveはサーバおよび他のSentinel(歩哨)プロセスからPINGコマンドを送信する.インスタンス(instance)が最後にPINGコマンドを有効に返信するまでの時間がdown-after-millisecondsオプションで指定された値を超える場合、このインスタンスはSentinel(哨兵)プロセスによって主観ダウンライン(SDOWN)としてマークされ、Masterプライマリサーバによって主観ダウンライン(SDOWN)としてマークされる場合、このマスターマスターサーバを監視している全てのSentinel(哨兵)プロセスは、マスターサーバが主観ダウンライン状態に入ったことを毎秒1回の頻度で確認する.十分な数のSentinel(哨兵)プロセス(プロファイル指定値以上)が指定された時間範囲内でマスターマスターサーバが主観ダウンライン状態(SDOWN)に入ったことを確認する.マスターサーバは、客観ダウンライン(ODOWN)としてマークされます.通常、各Sentinal(哨兵)プロセスは、クラスタ内のすべてのマスターサーバ、Slaveに対して、10秒ごとにINFOコマンドを送信します.マスターサーバがSentinel(哨兵)プロセスによって客観ダウンライン(ODOWN)とマークされると、Sentinel(哨兵)プロセスがダウンラインしたマスターマスターサーバへのすべてのSlaveがサーバからINFOコマンドを送信する頻度が10秒から1秒に1回に変更される.十分な数のSentinal(哨兵)プロセスがMasterプライマリサーバのオフラインに同意しなければ、Masterプライマリサーバの客観的なオフライン状態は削除されます.マスターサーバが再びSentinal(歩哨)プロセスにPINGコマンドを送信して有効な返信を返すと、マスターサーバの主観的なダウンライン状態が削除されます.哨兵モードの長所と短所 ：
哨兵モードは主従モードに基づいており、すべての主従の利点は、哨兵モードにある.プライマリ・スレーブは自動的に切り替えることができ、システムはより丈夫で、可用性が高い. ：
Redisはオンライン拡張をサポートするのが難しく、クラスタ容量が上限に達するとオンライン拡張が複雑になります.
3.Redis-CRusterクラスタ
redisの哨兵モードは基本的に高可用性、読み書き分離を実現できるが、このモードでは各redisサーバに同じデータが格納され、メモリが浪費されるためredis 3.0にはclusterモードが組み込まれ,実現されるredisの分散ストレージ,すなわち,各redisノードに異なるコンテンツが格納される.
Redis-CRusterは無中心構造を採用しており、その特徴は以下の通りである.
すべてのredisノードは互いに相互接続し(PING−PONG機構)、内部ではバイナリプロトコルを用いて伝送速度と帯域幅を最適化する.
ノードのfailは,クラスタの半数以上のノードによって失効を検出した場合に有効である.
クライアントはredisノードに直結、中間エージェント層は不要である.クライアントはクラスタのすべてのノードを接続する必要はなく、クラスタ内のいずれかの使用可能なノードを接続すればよい. ：
redisの各ノードには、スロット(slot)という2つのものがあり、その値範囲は0-16383です.もう1つはclusterであり,クラスタ管理プラグインと理解できる.私たちのアクセスのkeyが到着すると、redisはcrc 16のアルゴリズムに基づいて結果を求め、16384に結果を求め、各keyは0-16383の間のハッシュスロットに対応し、この値によって対応するスロットに対応するノードを見つけ、直接自動的にこの対応するノードにジャンプしてアクセス操作を行う.
高可用性を保証するために、redis-clusterクラスタはプライマリ・スレーブ・モードを導入し、1つのプライマリ・ノードは1つ以上のセカンダリ・ノードに対応し、プライマリ・ノードがダウンタイムすると、セカンダリ・ノードが有効になります.他のプライマリノードpingの1つのプライマリノードAの場合、プライマリノードの半数以上がAと通信タイムアウトした場合、プライマリノードAはダウンタイムとみなされる.プライマリノードAとスレーブノードA 1の両方がダウンタイムした場合、クラスタはサービスを提供できなくなります.