単一の Redis サーバーは、数万から数十万の QPS を処理できます。キャッシュの場合、通常は読み取りの高同時性をサポートするために使用されます。したがって、アーキテクチャは、1 つのマスターと複数のスレーブを持つマスター スレーブ アーキテクチャになります。マスターは他のスレーブ ノードへのデータの書き込みとコピーを担当し、スレーブ ノードは読み取りを担当します。すべての読み取り要求はスレーブ ノードを経由します。これにより、水平方向の拡張を容易に実現し、高い同時読み取りをサポートできるようになります。 Redis レプリケーション -> マスタースレーブアーキテクチャ -> 読み取りと書き込みの分離 -> 高い読み取り同時実行性をサポートするための水平拡張 Redisレプリケーションのコアメカニズム
スレーブノードは主に水平拡張と読み取り書き込み分離に使用されます。拡張されたスレーブ ノードにより、読み取りスループットが向上します。 マスタースレーブアーキテクチャを使用する場合は、マスターノードの永続性を有効にすることをお勧めします。スレーブ ノードをマスター ノードのデータのホット バックアップとして使用することはお勧めしません。その場合、マスターの永続性をオフにすると、マスターがクラッシュして再起動したときにデータが空になり、レプリケーション後にスレーブノードのデータが失われる可能性があります。 さらに、マスター用のさまざまなバックアップ計画も作成する必要があります。すべてのローカル ファイルが失われた場合は、バックアップから RDB を選択してマスターを復元し、起動時にデータが存在することを確認します。後述する高可用性メカニズムを採用した場合でも、スレーブノードはマスターノードを自動的に引き継ぐことができますが、センチネルがマスターの障害を検出する前にマスターノードが自動的に再起動する可能性があり、その結果、上記のスレーブノードのデータがすべてクリアされる可能性があります。 Redis マスタースレーブレプリケーションの基本原理 スレーブノードを起動すると、マスターノードに PSYNC コマンドが送信されます。 スレーブ ノードがマスター ノードに初めて接続する場合は、完全な再同期がトリガーされます。このとき、マスターはバックグラウンド スレッドを開始して RDB スナップショット ファイルを生成し、クライアントから受信したすべての新しい書き込みコマンドをメモリにキャッシュします。 RDB ファイルが生成された後、マスターは RDB をスレーブに送信します。スレーブはまずそれをローカル ディスクに書き込み、次にそれをローカル ディスクからメモリにロードします。次に、マスターはメモリにキャッシュされた書き込みコマンドをスレーブに送信し、スレーブもこのデータを同期します。ネットワーク障害によりスレーブノードがマスターノードとの接続を失った場合、自動的に再接続されます。接続が確立されると、マスター ノードは不足しているデータのみをスレーブ ノードにコピーします。 マスタースレーブレプリケーションのブレークポイント再開転送 Redis 2.8 以降では、マスター スレーブ レプリケーションのブレークポイント再開がサポートされています。マスター/スレーブ レプリケーション プロセス中にネットワーク接続が切断された場合、最初からコピーするのではなく、最後のコピー ポイントからコピーを続行できます。 マスターノードはメモリ内にバックログを維持します。マスター ノードとスレーブ ノードの両方がレプリカ オフセットとマスター実行 ID を保存します。オフセットはバックログに保存されます。マスターとスレーブ間のネットワーク接続が切断された場合、スレーブはマスターが最後のレプリカ オフセットからレプリケーションを続行できるようにします。対応するオフセットが見つからない場合は、再同期が実行されます。 ホスト + IP に基づいてマスター ノードを特定することは信頼できません。マスター ノードが再起動されたり、データが変更されたりした場合は、異なる実行 ID に基づいてスレーブ ノードを区別する必要があります。 ディスク複製なし マスターはメモリ内に直接 RDB を作成し、ローカル ディスクに保存せずにスレーブに送信します。設定ファイルで repl-diskless-sync yes をオンにするだけです。
期限切れキーの処理 スレーブはキーを期限切れにせず、マスターがキーを期限切れにするのを待つだけです。マスターがキーの有効期限を切れるか、LRU を通じてキーを削除すると、del コマンドがシミュレートされ、スレーブに送信されます。 複製の完全なプロセス スレーブ ノードが起動すると、マスター ノードのホストと IP を含むマスター ノードの情報がローカルに保存されますが、レプリケーション プロセスは開始されません。 スレーブ ノードにはタイマー タスクが内蔵されており、接続して複製する新しいマスター ノードがあるかどうかを毎秒チェックします。見つかった場合、マスターノードとのソケットネットワーク接続を確立します。次に、スレーブ ノードはマスター ノードに ping コマンドを送信します。マスターが requirepass を設定した場合、スレーブ ノードは認証のために masterauth パスワードを送信する必要があります。マスターノードは初めて完全なレプリケーションを実行し、すべてのデータをスレーブノードに送信します。その後、マスター ノードは書き込みコマンドをスレーブ ノードに非同期的に複製し続けます。 全文
増分レプリケーション
鼓動 マスターノードとスレーブノードは相互にハートビートメッセージを送信します。 デフォルトでは、マスター ノードは 10 秒ごとにハートビートを送信し、スレーブ ノードは 1 秒ごとにハートビートを送信します。 非同期レプリケーション マスターは書き込みコマンドを受信するたびに、まずデータを内部的に書き込み、次にそれを非同期的にスレーブ ノードに送信します。 Redisはどのようにして高可用性を実現するのか システムが 365 日のうち 99.99% の時間、外部にサービスを提供できる場合、そのシステムは高可用性であると言えます。 スレーブに障害が発生しても、他のスレーブが同じデータを使用して同じ外部クエリ サービスを提供できるため、可用性には影響しません。 しかし、マスターノードが停止した場合はどうなるでしょうか?データを書き込むことができず、すべての書き込みキャッシュが無効です。スレーブノードの用途は何ですか?データを複製するマスターがなければ、システムは使用不可能になります。 Redis の高可用性アーキテクチャは、フェイルオーバー、またはマスター/スレーブ切り替えと呼ばれます。 マスター ノードに障害が発生したときに自動的に検出し、スレーブ ノードをマスター ノードに自動的に切り替えるプロセスを、マスター スレーブ切り替えと呼びます。このプロセスは、Redis のマスター スレーブ アーキテクチャの下で高可用性を実現します。 |
>>: あなたもクラウドの世界の 7 つの新しいパラドックスに直面していますか?
企業では、ほとんどの製品マネージャーが実際の業務で競合製品の分析を行うことはほとんどありません。マー...
ウェブサイトの運用はウェブマスターにとって大きな課題であり、運用結果の品質はウェブサイトの価値に直接...
1920 年代、アメリカのビール市場における競争は極めて熾烈でした。統計によると、当時のシュリッツビ...
Google は最近開催された「Cloud Next」イベントで、あらゆるレベルの開発者や技術意思決...
17 年以上の運営実績を持つアメリカの老舗ホスティング ブランドである a2hosting が、ブラ...
知乎の香港株式市場への上場の追求は前例のない効率を達成した。米国上場の中国株が急落を続ける中、損失を...
ウェブマスターがウェブサイトの品質を判断する際に最も重要な要素の 1 つは、ウェブサイトのスナップシ...
2018年最もホットなプロジェクト:テレマーケティングロボットがあなたの参加を待っています暑い7月は...
クラウド コンピューティングとクラウドには共通点があります。クラウドコンピューティングのリソース使用...
ウェブマスターは、独自の Web サイトを所有する人々のグループです。彼らはインターネット上でユーザ...
みなさんこんにちは。私はHongtu Internetです。 2 か月前、下水道ウェブサイトの最適化...
【中国・深セン、2020年7月28日】本日、「スマート深セン、前進」をテーマにしたファーウェイクラウ...
2018年最もホットなプロジェクト:テレマーケティングロボットがあなたの参加を待っていますBaidu...
2003年に、impactvps(バックエンドドメイン名はsubnetlabs.com)を当サイトの...
一方、グーグルは本社があるカリフォルニアで大規模な開発計画を立てている。一方、同社のクラウドコンピュ...