Aクラスター・エディション
最後のケースでは、我々は単に使用のRedisを導入し、以下はRedisのは、クラスタ環境では、次の時間です。
クラスタを意味
Redisのクラスタを単一の解決できない問題を解決するために表示されるようにバインドされて、次のように簡単にまとめ、それをどのような疑問：
- 1つのRedisのインスタンスがRedisのかキャッシュとして、または使用するデータベースとして、利用できない、またはすべてのインスタンスで利用できない場合は、スタンドアロン環境では、ビジネスに大きな影響を引き起こすことがバインドされ、機械の単一障害点の確率が非常に高いです。
- 我々はG、スタンドアロン環境の数百数十サポートを提供することができないデータをキャッシュするために必要な場合は、純粋なメモリ操作としてRedisのアプリケーション、OSの制限の対象には、メモリは、無制限の拡大することはできません
- スタンドアローン非常に良い状況でマシンのパフォーマンス、一般的に、10ワット未満でスタンドアローンの缶高同時実行環境をサポートするべきではない、多くのサブスレッドのタスクがある10〜15ワットで公式QPSが、考慮。
CAPの原則
また、分散システムでは、CAP定理として知られている、一貫性（一貫性）、可用性（アベイラビリティ）、パーティション・トレランス（パーティションのフォールトトレランス）は、3つの両方を持つことはできません。例えば、強い一貫性と可用性が愛好家のペアで、次のことが紹介され、共存させることはできません。Redisのは、APクラスタ実装されています。
クラスタの実装
単一障害点を解決する1
マシンは信頼できないので、それはいくつかのものよりも多くを行うだろう。便利なパフォーマンスの問題を解決するために下にスライドしながら、水平方向のスケーリングRedisのサーバーは、この問題を解決するものではありません：
マスタープラグアンドテーブル軟膏は、n個のミラーのマスター、にそれぞれ理論的に保持する同等のデータの完全なマスターの量を、軟膏マスターダウンした後、スレーブは、まだサービスを提供するために、完全なデータを保持するだけでなく、個別の読み取りと書き込みをサポートし、それに興奮少しがあると考えることができます。
まず、二つの用語を説明します。
- マスターから、
シンプルで理解するために、クライアントがホストに接続することができ、すなわち、及びからも接続することができます - スタンバイ
機器、すなわち、バックアップマシンは、クライアントがホストのみの後にダウンし、バックアップサーバーに接続できない、ホスト機能の代替調製機は接続することができます
通常、ホストはマシンから読みを読み書きすることができます。
これは、新たな問題が付属しています
一貫性
各スレーブ保有者の完全なデータを作る方法を、落ち着いて？データの整合性の問題は、そう他の実施例の以下の略図を生じる：
クライアントデータはMatser両方のスレーブに、マスタデータ同期に書き込まれます。今、単に要求を受信による米国や欧州の変動に、スレーブ2のネットワークを同期要求し、完全なデータ同期を受信、または軽く受信SLAVE1が、エラーがデータ同期中に発生し、実際の同期が完了していないので、今が行われていると仮定マスターとスレーブ1最新のデータが、スレーブ2は、単にこのデータを持っていないような状況、。現在の緊急事態を想定、マスターとスレーブ1は、この時点でサービスを提供できる唯一のスレーブ2を残して、ダウンしている、この新しいデータはそう失わ挿入されています。
展開のレベルは、いくつかの問題があったので、ちょうどあなたの袖をロールアップし、それを行います。一般的に、そのいくつかのプログラム（拡張以下の拡張に属するコンテンツ）があります。
強い整合性
まあ理解、または3台のマシンはすべて成功するか、すべて失敗します。今、クライアントが強い整合性を達成するために、マスターのRedisは、1つのプロセスがあるので、マスターは、正常に同期データに次の2つのスレーブ書かれているに書き込みコマンドを送信し、マスターがいる場合にのみ、2つのスレーブの同期の結果を待ってブロックすることができます書き込みが完了すると、両方のは、[OK]を、正常な応答マスターです。スレーブ1の通知の同期が完了している場合は、スレーブ2通知が失敗した場合、または半日後に、何の同期結果はマスターのみが再試行またはデータが正常に取り消されたか、強い一貫性を保つために、この同期が失敗したことを信じることができることを与えられていません。しかし、同等のサービスの面で失効データ、またはクライアントの再試行（スレッドがまだブロックされているこの時間）かどうかを使用できません。このように、ビジョンは非常に美しいですが、コストは可用性に大きすぎる、深刻な被害です。
弱い一貫性
それは確かにブロックされ、同期を使用することはできませんどのようにうるさい、の可用性ので、ちょっと、それは非同期通知の聖歌に置き換えられます。クライアントデータの後マスター、ライン上のマスターの成功、および2つの非同期通知スレーブマスタデータの同期を到着したが、2件のスレーブのデータが完全に一致し、マスターであることを保証することはできません。
最終的一貫性
更新への第三者による受信に成功し、スレーブ1、スレーブ2の具体的な同期運転、非同期の後に、サードパーティのデータ同期を得るために、（応答は十分な速さでなければならない）を提出信頼できるサードパーティ、マスター同期データがある場合と考えることができ、最終的にことを確認してください2つのスレーブを更新することができます。
質問は、データを読み込みます
Redisの別々の読み取りと書き込みの後、仮定マスタデータが更新されましたが、スレーブは更新が完了するまでの時間を持っていません。2つの既存のクライアント、データは新しいデータが読み出され、他は古いデータを読み取ることで、完成し、スレーブからデータを読み込み、マスターから読み取ります。
マスターシングルポイントの問題
それはマスタースレーブまたはマスタとスレーブがあるかどうか、ホストマスターから不可分で、質問は、マスター自体、またはシングルポイント・マシン、問題の原点に戻って...
Redisのは、それを達成する方法ですか？
マスター一点問題解決
マスターが利用可能であるかどうかを判断する方法を、場合人物を想像してみ？非常にシンプルな、マスターとの通信を確立し、マスターは、サービスを提供することが可能かどうかを判断します。：以下、あなたは次のセンチネル（センチネル）を導入することができ
、私はなぜ1、私は3を描いたスマートあなたは見張りの上に気づいていなければならないと信じて、またそれが2であるの？
まず、私たちは存在センチネルの意味を定義する必要があり、マスターの問題を解決するために、単一の点で、ぶっきらぼうに言って、それが現在のマスターが生きている監視することで、サービスを提供することができます。
マスターセンチネルと、ある時点間のネットワーク変動は、センチネルは、マスターダウンを考える災害復旧を開始し、実際に新しいマスタースレーブスイッチ、古き良きマスター、となります場合、マスターは唯一の定点サーベイランスであることを今仮定しています典型的なネットワークパーティション問題が生じ、接続の一部を与え、まだ古いマスター、新しい接続の一部と一貫性のない相互作用新しいマスターと連絡を取り合います。
唯一の前哨実現可能な、プラス何が起こるか見張り以来？いくつかの点で歩哨の接続の問題、マスターの問題を判断し、別の見張りとマスターは考えダウン通常の接続、良い判断マスターを、維持、及びそれに耳を傾ける最後に、何の問題を考えていない場合は？明らかに、2つだけ歩哨も可能。
1人の歩哨の半数以上が、マスターダウンを考えるとき、マスターを監視し、彼らはマスターが実際にダウンしていると考えることができます前に、それは、現在のセンチネルの半分よりも大きな得票数で、災害復旧するには、少なくとも3つのガードは起動する必要があります。
仕事が救助を開始する方法、である場合には、この程度Sentinelは、このセクションでは、センチネル詳細なフォローアップ特別なセクションの面で広がっていません。
Redisの実装
ここでは、Redisのではシンプルで小さなデモを見ては、データの同期を実現する方法である必要があり：
環境：Mac OSの
ツール：シェル、ドッカ（私は怠け者だ、デフォルトの設定]ドッキングウィンドウコンテナを使用して、たくさんのことを設定する必要はありません）
説明：このをRedisのは、デフォルトの設定を使用してデモ、コンフィギュレーションの結果を変更し、このデモは少し異なるものになります。
1.まず、我々はマシンシミュレーションでRedisのクラスタ環境を作成します。最初の4つの空のシェルを起動します
。2. 4シェルは、次のコマンドを入力して、それぞれ、左から右へ（効果を実証するために、我々は、フロントエンドは、Redisのインスタンスを実行しているからブロックされてみましょう）：
左上：
docker run --name master -p 6379:6379 redis
右上：
docker run --name slave1 -p 6380:6380 redis
左下：
docker exec -ti master redis-cli
右下：
docker exec -ti slave1 redis-cli
：効果があるとして
、我々は成功した2つのRedisのインスタンス、1 6379、1 6380を立ち上げ、
同時に2つのクライアント、接続インスタンス6379、接続例6380を発売します
サンドボックス機構ドッキングウィンドウは、2つのコンテナ間の通信ではないので、また、私たちは、インスタンス間で以下の双方向通信のためのブリッジを構築します：
docker network create -d bridge myBridge
docker network connect myBridge master
docker network connect myBridge slave1
[OK]を、これまでのところ、私たちの準備が完了しています。
実証するため3.私たちは今、セクション6379のキーを追加し、：
4. 6380が6379をスレーブに設定されている
次のコマンドで使用されるクライアント6380に接続されています：
replicaof 172.17.0.2 6379
[OK]を、終了し、我々は今、4つのシェルディスプレイ・インターフェースを見て
コピー・オン・ライトモードの使用、新しい演劇：マスターのシェルでは、我々は非常に少ない事があったが、成功したスレーブ接続後にマスターを見ることができますバックグラウンドスレッド23は、SYNCコマンドでRDBファイルの完了をスレーブに送信された後、（すなわち、総量が現在のマスタでRDBファイルを生成した）bgsaveを運びます。
シェルスレーブでは、我々はそれを見ることができ、SYNCチャネルを構築するために始めた、マスター、との接続を確立した後、接続が彼の古いデータ最初のクリアから送られたマスターRDBデータを受信した後、滑らかであることを確認するためにマスターするには、pingを送って、 RDBは、メモリにデータをロードします。
我々は結果を見て：
これまでのところ、マスターとスレーブの間で、データボリュームの完全同期を完了すること。
増分データ同期：
私たちは、その後、スレーブ・ビューに移動し、その後、key11でマスターに追加し、あなたがkey11がスレーブに同期されています見ることができます
以下は、私たちはRedisのマスター・スレーブレプリケーションのロジックを要約したものです。
- データ同期の総量：
マスターと回復再接続した後、長い時間のためのスレーブマスター、またはスレーブダウンなどシーンに新たな接続の一般的な使用、。
同期の総量は、RDBファイルを使用する必要があり、デフォルトでは、RDBの第一世代は、ディスク上に格納されたファイル、およびので、RDBの後に生成されたすべての文書には、その後、完成したスレーブに送信されています。したがって、性能は、ディスクの速度によって制限されるのconf構成に追加することができる：REPL-ディスクレス同期なし、生成されたRDBディスク・ファイルは、スレーブの形式でネットワークを介して送信直接落下しません。
データ同期処理については、上記のデモは、既にここに詳細なプロセスがありすぎて説明を行うにはありません。
また、独自のスレーブの古いデータを削除し、指摘し、新しいデータをロードするプロセスは、デフォルトではブロックされている、あなたは、この時間の間に、confので非同期に設定することができ、要求に対するスレーブがまだ応答して、古いデータに戻って、しかし、軟膏をブロックすることができ、メインスレッドでのみ動作し、新しいデータセットをロードします。 - 増分同期：
同期の全額、もう少し複雑に比べ増分同期。
：私たちは、次のマスターとスレーブの情報が何であるかを見て
入力し、「情報の複製」
私たちは、そのマスターで、そこに現在の自身の複製IDだけでなく、独自のデータがオフセットオフセット、およびスレーブだけでなく、持って見ることができます最後のマスタデータ同期の情報であるオフセットそれらの複製のIDだけでなく、replidのマスターとのマスター、。
送信されたデータのバイト数自体をオフセットどのように多くのスレーブ・ストリームに自身のマスターコピーは、新しいオブジェクトは、独自のデータセットの動作を変更するとき、オフセットスレーブを更新するために使用することができ、数に増加した場合状態。実質的に各複製IDのオフセット、データの正確なバージョンを決定することができます。
スレーブがマスターに接続している場合、コマンドを使用しMasetrから始めるべきデータを知っている、とスレーブへのフォローアップのデータ同期もせPSYNC古いマスターは、彼らのレコード契約をreplicationID、これまでそれらを相殺送ら
そうか、それの同期、時間のときスレーブ同期再びこの1時間で、マスター4Gデータが更新された、前のスレーブ最新の同期時間が1時間であれば、そのようにAの問題を想定し、？答えはありません。
上記のチャートから、私たちはメッセージ「repl_backlog_sizeが」と呼ばれ、これは運用コマンドバッファのマスターで見ることができ、その大きさは、理解を容易にするために構成することができ、あなたはリングメモリ空間と考えることができます。
新しい命令を交換する最も古い命令の開始前に、インデックスは= 0インデックス= 0、命令に、それがいっぱいになるまで、内側のリング、リング全体のメモリを埋めるためのデータ、その後のコマンドを再度を、開始します。
バッファ内に見つかった場合、スレーブオフセット情報が引き継がれた場合に、マスタオフセットバッファに対応するコマンドを見つけるために、オフセットに基づいて、それがバッファ内に見つからない場合、命令同期スレーブに従うことです対応するオフセット、データの総量は、RDBの同期を行います。
デフォルトモードは、スレーブが読み取り専用、読み書きモードはCONFによって調整することができることです。
マスタ・スレーブモード、Redisのそれは非同期レプリケーションですので、各スレーブデータを受信し、常にデータの損失、この特定の使用シナリオが許容できるかどうかを確認する必要性、寛容PubMedのネットワークパーティションが存在するであろうことを保証することはできません。
さらに、配置することによりRedisの支持部の一貫性、：
分レプリカ・ツー・ライトXXX
MIN-MAX-LAG-XXXレプリカが
互いに通信タイムアウト最小成功スレーブライトデータを設定し、最大。例えば、少なくとも三つの軟膏が成功し書かれている場合にのみ、3のように構成されたXXX、このデータは、成功した書き込みと考えられ、最終的にはRedisのデータセットにされるであろう。
問題を解決するための1 Redisの容量
スペースはので、しばらくお待ち、後続の章Redisのパーティションに説明し、限定されています。
