Redisの達成高い並行性は、主に依存マスタ-スレーブ・アーキテクチャ、マスターマルチスレーブ。可用性へのマスターから、我々は追加する必要が警備員を、下のいずれかのインスタンスで実装することができる、切り替えを行うことができます。並行性の高い可用性た後に、ビッグデータに対応するようにしたいのRedisクラスタ
マスタスレーブアーキテクチャ：マスター・スレーブ・アーキテクチャは
：クラスターRedisのクラスタを
まず、センチネルを導入メカニズム
1.1、センチネル機能/センチネルメカニズム
あなたは、複数のセンチネルアーキテクチャ内のプロセス、オフライン情報かどうかマスターを受け取るためのプロトコルを使用して、これらのプロセス、および自動フェイルオーバーを実行するかどうかを決定するために、投票プロトコルの使用を実行するだけでなく、新しいマスターとしてどのスレーブを選択することができます。
各Sentinelは、定期的に相手が指定した時間内に応答しない場合、相手が生きている、他の当事者は、一時的なタスクを切ったかどうかを決定するために、他の警備員、マスター、スレーブにメッセージを送信します。
大半は、Sentinelシステムを応答しませんでしたマスタが死のマスターを検討する場合には（残りのスレーブは、一定のアルゴリズムでマスターノードに昇進したからいずれかを選択）ことに同意します。
：複数のサーバを管理するためのRedis Sentinelのメカニズム、分散システム（センチネルメカニズム）は、次の3つのタスク（機能）を実行する
（1）クラスタモニタ：Redisのマスターとスレーブのプロセスを監視する責任が正常に動作しています。
（2）メッセージ通知：Redisのインスタンスが失敗した場合は、アラームとして管理者に通知メッセージを送信するための責任を見張り。
（3）フェイルオーバー：マスターノードハングが、自動的にスレーブノードに転送されます（センチネルはほとんどが仕事を必要とすることに同意する必要がある分散選挙を）。
コンフィギュレーション・センター：フェールオーバーが発生した場合、クライアントに新しいマスタアドレスをクライアントに通知します。
1.2、センチネル上の注意
（1）フェイルオーバーは、マスターノードがダウンしている、と警備員のほとんどがそれに同意を必要としている決定、それが必要とする分散型選挙の問題を
（2）は、Sentinelは、少なくとも3つのインスタンスを必要とし、その堅牢性を保証するために、
センチネルをクラスタは、二つ以上のノード、クラスタを展開する必要がある場合のみセンチネルセンチネル展開2つのインスタンス、定足数= 1 
構成定足数= 1、マスターダウンは、S1、S2が長いマスターがダウンしていることセンチネルがある限り、行うことができる場合S1とS2センチネルは、フェールオーバーを実行することを選択する一方、スイッチング。しかし同時に、これは必要な過半数（実行するために警備員の数）です。この時間はちょうどM1プロセス、センチネルS1通常動作ダウンしている場合、フェイルオーバーはOKです。しかし、マシン全体のダウンタイムM1とS1の実行、そして唯一の歩哨場合、この時間は、他のマシンと同様にR1が、上のフェイルオーバーは実行されませんが、何の大半は、フェイルオーバーできるようにしないために存在します
古典このような3センチネルノードクラスタ：
構成クォーラム= 2、M1が停止している場合、機械は、次に残りの3つのセンチネル2、S2及びS3は、マスターがダウンしていることに同意することができる場合には、フェイルオーバーを実行することを選択残りの二つのガードが実行されているので、大多数のセンチネル3は、2である一方で、あなたは、フェイルオーバー許可することができます
（3）センチネル+展開アーキテクチャのマスタースレーブのみ、データ損失ゼロを保証するつもりはないのRedisクラスタは、高可用性を確保するためのRedis
1.3、データ交換から（どちらの場合も）のSentinel主損失の問題
データ（1）非同期レプリケーションは、損失につながります。
マスター- >スレーブレプリケーションは非同期であるため、それは、スレーブにコピーされたデータの一部を持っているマスター、それを下にし、この時点で失われたデータの一部ではないかもしれ
スプリットブレインの損失データ（2）結果：
スプリットブレイン：Aを通常のネットワークから、マシンの突然の出発のマスターは、マシンが他のスレーブに接続することはできませんが、実際にはマスターも実行されています。このとき、センチネルは、マスターがダウンしていると思いますし、その後の選挙を回すかもしれない、他のスレーブスイッチがマスターになりました。今回は、クラスタは2つのマスターになります 、いわゆるスプリットブレインを
スレーブを切り替えているが、この時点では、マスターとなりましたが、クライアントは新しいマスターへの切り替えに時間を過ごしましたが、また、古いマスターへの書き込みデータを継続していないことがあります。古いマスターが再び回復したときにそう、それは新しいマスターをハングアップするために奴隷のようになります、あなたのデータは消去されます新しいマスターからデータを再コピーし、。このデータの一部が失われますので、新しいマスタデータ以降のクライアントは、書いていません
1.4、データの損失ソリューション
以下の
min-slaves-to-write 1 //要求至少有 1 个 slave
min-slaves-max-lag 10 //数据复制和同步的延迟不能超过 10 秒
- 1
- 2
（1）データの損失の非同期レプリケーション削減
と分-奴隷を-MAX-ラグこの構成は、あなたはスレーブがデータをコピーすると、ACK遅延が長すぎると、彼らはあまりにも多くのデータをダウンタイム損失を習得できると思いますことを確認することができますマスタデータが制御可能な範囲に減少による欠落スレーブのデータ部分に同期されていない場合、その後の書き込み要求を拒否し、このようにダウンタイムが発生
スプリットブレインデータ損失の（2）還元
マスタ分割脳は他と、発生した場合あなたは、スレーブの数を指定しないと、自分自身にACKメッセージを与えることを何より10秒以上スレーブにデータを送信し続けることができない場合は、失われた接続をスレーブ、その後、2つの構成性を保証以上、その後、クライアントの要求に直接書き込むことを拒否していること。そのため、スプリットブレインシナリオでは、データの10秒までが失われます
1.5、及びodownダウン型開閉機構SDOWN
SDOWNのダウンタイムは主観的である：それはマスターがダウンしていると感じた場合、ダウン主観がダウン客観odownですセンチネルです：センチネルの定足数の数はマスターがダウンしていると感じた場合は、ダウン目的であります
1.6、自動検出機構見張りクラスタ
SentinelはRedisのことで、お互いを発見した パブ/サブシステム実装
の各センチネルが行く（1） センチネル。このチャネルこんにちはメッセージを送る、この時間はニュースに他のすべての警備員を消費し、知覚することができます。他の歩哨の存在に。
（2）2秒ごとに、センチネルは、それらのマスター+スレーブにそれぞれ行くメッセージを送信する際に、対応するチャネルを監視し、自分のホスト、IPの内容と、マスターRUNID構成を監視します。
（3）各Sentinelはスレーブ+の他のセンチネルのこのマスターを聞くに存在する知覚同じに行く
同期（4）各定点監視がお互いを監視するように構成され、センチネルのマスターの他の構成で交換されます
1.7、定足数および過半数を理解します
たびに歩哨がスイッチオーバーを行うには、センチネルの最初のクォーラムに必要な数は（客観的ダウンタイム）odownと思うし、その後、センチネルを行うために、スイッチに選出され、センチネル歩哨の大半も、正式なハンドオーバーを実行するために許可する必要があります。
定足数<大部分、例えば5つのセンチネル、大部分が3である場合、定足数は、次の3つのセンチネルがハンドオーバ承認を行うことができ、2に設定されています。
しかし、定足数> =大多数の場合には、このような5つの歩哨の承認定足数の数を、持っている必要がありますセンチネル、定足数は、あなたがスイッチングを実行するために5人の警備員を承認することに合意している必要があり、5です
1.8、コンフィギュレーションモードを変更するセンチネル
实现步骤:
1.拷贝到etc目录
cp sentinel.conf /usr/local/redis/etc
2.修改sentinel.conf配置文件
sentinel monitor mymast 192.168.110.133 6379 1 #主节点 名称 IP 端口号 选举次数
sentinel auth-pass mymaster 123456
3. 修改心跳检测 5000毫秒
sentinel down-after-milliseconds mymaster 5000
4.sentinel parallel-syncs mymaster 2 --- 做多多少合格节点
5. 启动哨兵模式
./redis-server /usr/local/redis/etc/sentinel.conf --sentinel &
6. 停止哨兵模式
