分散システムのRedisマスタースレーブアーキテクチャ

分散システムのRedisマスタースレーブアーキテクチャ

単一の Redis サーバーは、数万から数十万の QPS を処理できます。キャッシュの場合、通常は読み取りの高同時性をサポートするために使用されます。したがって、アーキテクチャは、1 つのマスターと複数のスレーブを持つマスター スレーブ アーキテクチャになります。マスターは他のスレーブ ノードへのデータの書き込みとコピーを担当し、スレーブ ノードは読み取りを担当します。すべての読み取り要求はスレーブ ノードを経由します。これにより、水平方向の拡張を容易に実現し、高い同時読み取りをサポートできるようになります。

Redis レプリケーション -> マスタースレーブアーキテクチャ -> 読み取りと書き込みの分離 -> 高い読み取り同時実行性をサポートするための水平拡張

Redisレプリケーションのコアメカニズム

  • Redis は非同期メソッドを使用してデータをスレーブ ノードにコピーします。ただし、Redis 2.8 以降では、スレーブ ノードはコピーするデータの量を毎回定期的に確認するようになります。
  • マスター ノードは複数のスレーブ ノードで構成できます。
  • スレーブ ノードは他のスレーブ ノードに接続することもできます。
  • スレーブ ノードがレプリケーションを実行している場合、マスター ノードの通常の操作はブロックされません。
  • スレーブ ノードがレプリケーションを実行している場合、スレーブ ノード自身のクエリ操作はブロックされません。サービスの提供には古いデータセットが使用されます。ただし、レプリケーションが完了したら、古いデータセットを削除し、新しいデータセットをロードする必要があります。現時点では外部サービスは停止されます。

スレーブノードは主に水平拡張と読み取り書き込み分離に使用されます。拡張されたスレーブ ノードにより、読み取りスループットが向上します。

マスタースレーブアーキテクチャを使用する場合は、マスターノードの永続性を有効にすることをお勧めします。スレーブ ノードをマスター ノードのデータのホット バックアップとして使用することはお勧めしません。その場合、マスターの永続性をオフにすると、マスターがクラッシュして再起動したときにデータが空になり、レプリケーション後にスレーブノードのデータが失われる可能性があります。

さらに、マスター用のさまざまなバックアップ計画も作成する必要があります。すべてのローカル ファイルが失われた場合は、バックアップから RDB を選択してマスターを復元し、起動時にデータが存在することを確認します。後述する高可用性メカニズムを採用した場合でも、スレーブノードはマスターノードを自動的に引き継ぐことができますが、センチネルがマスターの障害を検出する前にマスターノードが自動的に再起動する可能性があり、その結果、上記のスレーブノードのデータがすべてクリアされる可能性があります。

Redis マスタースレーブレプリケーションの基本原理

スレーブノードを起動すると、マスターノードに PSYNC コマンドが送信されます。

スレーブ ノードがマスター ノードに初めて接続する場合は、完全な再同期がトリガーされます。このとき、マスターはバックグラウンド スレッドを開始して RDB スナップショット ファイルを生成し、クライアントから受信したすべての新しい書き込みコマンドをメモリにキャッシュします。 RDB ファイルが生成された後、マスターは RDB をスレーブに送信します。スレーブはまずそれをローカル ディスクに書き込み、次にそれをローカル ディスクからメモリにロードします。次に、マスターはメモリにキャッシュされた書き込みコマンドをスレーブに送信し、スレーブもこのデータを同期します。ネットワーク障害によりスレーブノードがマスターノードとの接続を失った場合、自動的に再接続されます。接続が確立されると、マスター ノードは不足しているデータのみをスレーブ ノードにコピーします。

マスタースレーブレプリケーションのブレークポイント再開転送

Redis 2.8 以降では、マスター スレーブ レプリケーションのブレークポイント再開がサポートされています。マスター/スレーブ レプリケーション プロセス中にネットワーク接続が切断された場合、最初からコピーするのではなく、最後のコピー ポイントからコピーを続行できます。

マスターノードはメモリ内にバックログを維持します。マスター ノードとスレーブ ノードの両方がレプリカ オフセットとマスター実行 ID を保存します。オフセットはバックログに保存されます。マスターとスレーブ間のネットワーク接続が切断された場合、スレーブはマスターが最後のレプリカ オフセットからレプリケーションを続行できるようにします。対応するオフセットが見つからない場合は、再同期が実行されます。

ホスト + IP に基づいてマスター ノードを特定することは信頼できません。マスター ノードが再起動されたり、データが変更されたりした場合は、異なる実行 ID に基づいてスレーブ ノードを区別する必要があります。

ディスク複製なし

マスターはメモリ内に直接 RDB を作成し、ローカル ディスクに保存せずにスレーブに送信します。設定ファイルで repl-diskless-sync yes をオンにするだけです。

  1. repl-diskless-sync yes# より多くのスレーブが再接続する必要があるため、レプリケーションを開始する前に 5 秒待機します repl-diskless-sync-delay 5

期限切れキーの処理

スレーブはキーを期限切れにせず、マスターがキーを期限切れにするのを待つだけです。マスターがキーの有効期限を切れるか、LRU を通じてキーを削除すると、del コマンドがシミュレートされ、スレーブに送信されます。

複製の完全なプロセス

スレーブ ノードが起動すると、マスター ノードのホストと IP を含むマスター ノードの情報がローカルに保存されますが、レプリケーション プロセスは開始されません。

スレーブ ノードにはタイマー タスクが内蔵されており、接続して複製する新しいマスター ノードがあるかどうかを毎秒チェックします。見つかった場合、マスターノードとのソケットネットワーク接続を確立します。次に、スレーブ ノードはマスター ノードに ping コマンドを送信します。マスターが requirepass を設定した場合、スレーブ ノードは認証のために masterauth パスワードを送信する必要があります。マスターノードは初めて完全なレプリケーションを実行し、すべてのデータをスレーブノードに送信します。その後、マスター ノードは書き込みコマンドをスレーブ ノードに非同期的に複製し続けます。

全文

  • マスターは bgsave を実行して、rdb スナップショット ファイルをローカルに生成します。
  • マスター ノードは rdb スナップショット ファイルをスレーブ ノードに送信します。 rdb レプリケーション時間が 60 秒 (repl-timeout) を超えると、スレーブ ノードはレプリケーションが失敗したと見なします。このパラメータは適宜増やすことができます(ギガビットネットワークカードを搭載したマシンの場合、通常は1秒あたり100MBが送信され、6Gのファイルは60秒を超える可能性があります)
  • マスターノードが RDB を生成すると、すべての新しい書き込みコマンドがメモリにキャッシュされます。スレーブ ノードは RDB を保存した後、新しい書き込みコマンドをスレーブ ノードにコピーします。
  • レプリケーション中にメモリ バッファーが継続的に 64 MB 以上を消費したり、一度に 256 MB を超えたりすると、レプリケーションは停止され、失敗します。
  1. クライアント出力バッファ制限スレーブ256MB 64MB 60
  • スレーブ ノードは、RDB を受信すると、古いデータをクリアし、RDB を自身のメモリに再ロードしながら、古いデータ バージョンに基づいて外部サービスを提供します。
  • スレーブ ノードで AOF が有効になっている場合は、BGREWRITEAOF がすぐに実行され、AOF が書き換えられます。

増分レプリケーション

  • 完全なレプリケーション プロセス中にマスターとスレーブ間のネットワーク接続が切断された場合、スレーブがマスターに再接続すると増分レプリケーションがトリガーされます。
  • マスターは、自身のバックログから失われたデータの一部を直接取得し、スレーブ ノードに送信します。デフォルトのバックログは 1MB です。
  • マスターは、スレーブによって送信された psync 内のオフセットに基づいてバックログからデータを取得します。

鼓動

マスターノードとスレーブノードは相互にハートビートメッセージを送信します。

デフォルトでは、マスター ノードは 10 秒ごとにハートビートを送信し、スレーブ ノードは 1 秒ごとにハートビートを送信します。

非同期レプリケーション

マスターは書き込みコマンドを受信するたびに、まずデータを内部的に書き込み、次にそれを非同期的にスレーブ ノードに送信します。

Redisはどのようにして高可用性を実現するのか

システムが 365 日のうち 99.99% の時間、外部にサービスを提供できる場合、そのシステムは高可用性であると言えます。

スレーブに障害が発生しても、他のスレーブが同じデータを使用して同じ外部クエリ サービスを提供できるため、可用性には影響しません。

しかし、マスターノードが停止した場合はどうなるでしょうか?データを書き込むことができず、すべての書き込みキャッシュが無効です。スレーブノードの用途は何ですか?データを複製するマスターがなければ、システムは使用不可能になります。

Redis の高可用性アーキテクチャは、フェイルオーバー、またはマスター/スレーブ切り替えと呼ばれます。

マスター ノードに障害が発生したときに自動的に検出し、スレーブ ノードをマスター ノードに自動的に切り替えるプロセスを、マスター スレーブ切り替えと呼びます。このプロセスは、Redis のマスター スレーブ アーキテクチャの下で高可用性を実現します。

<<:  Linux の仮想メモリと物理メモリを理解する

>>:  あなたもクラウドの世界の 7 つの新しいパラドックスに直面していますか?

推薦する

Pinduoduo はなぜトラフィックを気にしないのでしょうか?

Pinduoduoは「Pinduoduo スピード」を再定義しました。 11月3日、ピンドゥオドゥオ...

ウェブサイトの重量とトラフィックが停滞する原因は何でしょうか?

トラフィックはウェブサイトの血液であり、重みはウェブサイトの血液が補充されることを保証する基礎である...

簡単な分析: ホームページへの単一キーワードのランキングを最適化する方法

単一キーワードのホームページへのランキングを最適化するにはどうすればよいでしょうか。今日のインターネ...

検索エンジンのランキングの背後にあるロジックは、ユーザーに私たちのことを考えてもらうことです

SEO は、最終的には検索エンジンに対処することです。検索エンジンも人間によって発明されたものなので...

最も完成度が高い!ミニ番組チャンネル宣伝まとめ、保存しました!

ミニプログラムは軽量な製品で、発売当初はあまり好評ではありませんでした。共有する方法がなく、入り口も...

IIS ログからスパイダーのクロール時間を分析して、クイックコレクション Web サイトを作成し、元のコンテンツをタイムリーに保護します。

ウェブマスターは、権威の高いウェブサイトがオリジナル コンテンツを収集し、そのオリジナル コンテンツ...

農業用モバイルアプリ開発の実現可能性と必要性

広東省の南方農村新聞は「柑橘類トン」「農業資材トン」「エビ・カニトン」「養豚業トン」を立ち上げました...

モバイル時代の検索危機: 大量のリンクからユーザーを救えるのは誰か?

収益の96%を広告から得ているインターネット大手のGoogleは、モバイル時代において良い成績表を出...

電子商取引で何度も敗北してきた百度は、今や電子商取引のショッピングガイドになろうとしている

百度が電子商取引に強くないというのはもはやニュースではない。検索プロモーション、アフィリエイトプロモ...

digitalvirt はどうですか?デジタルバーチャルの米国as4837ラインVPSの簡単なレビュー

DigitalVirt VPS はいかがでしょうか?米国の AS4837 ライン上の Digital...

おすすめ: Ftpit - 4 つの純粋な SSD 特別 VPS のプロモーション

FTPIT の今回のプロモーションには、SSD CACHE ではなく、純粋な SSD ハードドライブ...

数百の独立系ソフトウェアベンダーがAWS Marketplace Chinaに掲載されています

2021 年 4 月 6 日、Western Cloud Data が運営する AWS Market...

Tencent Cloud: 超お得なプロモーション、年間38元から、さまざまな「ハイエンド」および安価なクラウドサーバーから選択可能

Tencent Cloud はほぼ常にプロモーションを行っていますが、最近開始されたプロモーションの...

これまで無視されてきたキーワードランキングに影響を与える要因

ウェブサイトの最適化を行う人にとって、ランキングの問題は誰もが死ぬほど心配する問題です。必要な外部リ...