Redis の高可用性と高同時実行メカニズムの詳細な説明

1. 高い同時実行性メカニズム

Redis はシングル スレッドに基づいており、スタンドでホストできることがわかっています。 -alone モード 数万程度しかありませんが、Redis のマスター/スレーブ アーキテクチャと読み取りと書き込みの分離により、ビッグ データ下での数十万の高い同時リクエストをどのように改善するか。

ビデオ コースの推奨事項 →: 「数千万のデータに対する同時実行ソリューション (理論と実践)」

1. マスター/スレーブ レプリケーション

Redis のマスター/スレーブ レプリケーションの構成は強調されませんが、主にマスター/スレーブ レプリケーションの原理とプロセスに依存します。マスターホストは管理者として必要であり、複数のスレーブマシンを構築します。スレーブ スレーブが起動しようとすると、マスター ホストにコマンド PSYNC を送信しますが、このときスレーブ スレーブが再接続されると、スレーブ スレーブが持っていないデータがマスター ホストからコピーされます。初めて接続すると、完全な再同期がトリガーされます。トリガー後、マスターホストはバックグラウンドでプロセスを開始し、RDBスナップショットファイルを生成すると同時に、この期間の書き込み操作をキャッシュに保存し、RDBファイルが生成されると、RDBファイルを送信します。スレーブ マシンにファイルを送信すると、スレーブ マシンはファイルを取得します。その後、ファイルは最初にディスクに書き込まれ、次にメモリにロードされます。最後に、マスター ホストもメモリにキャッシュされたデータをスレーブ マシンに送信します。同じ時間です。マスター/スレーブ間のネットワーク障害が発生し、複数のスレーブが再接続した場合、マスターは 1 つの RDB のみを再起動してすべてのスレーブにサービスを提供します。 [関連する推奨事項: Redis ビデオ チュートリアル ]

ブレークポイントの再開: マスターとスレーブにレプリカ オフセットがあり、その中にマスター ID があり、オフセットはネットワーク障害後にスレーブが再接続すると、対応する最後のレプリカ オフセットを見つけてコピーします。対応するオフセットが見つからない場合は、完全な再同期がトリガーされます。

①レプリケーションの完全なプロセス

(1) スレーブ ノードが開始され、マスター ノードのホストと IP を含むマスター ノードの情報のみが保存されますが、レプリケーション プロセスは実行されません。 start

マスター ホストと IP はどこから来ますか? redis.conf の smileof 設定の

(2) スレーブ ノード内には、新しいホストがあるかどうかを確認するスケジュールされたタスクがあります。マスターノードに接続し、毎秒コピーします。それが見つかったら、マスターノードとのソケットネットワーク接続を確立します。
(3) スレーブノードはマスターノードに ping コマンドを送信します。
(4) パスワード認証。マスターが requirepass を設定すると、スレーブ ノードは認証のために masterauth パスワードを送信する必要があります。
(5) マスター ノードは初めて完全なレプリケーションを実行し、すべてのデータをスレーブ ノードに送信します。
(6) マスター ノードは、コマンドの書き込みを継続し、それらをスレーブ ノードに非同期でコピーします。

②データ同期関連するコア メカニズム

は、スレーブが初めて msater に接続するときに実行される完全なコピーを指します。そのプロセスの詳細なメカニズム

(1) マスターとスレーブの両方がオフセットを維持します。

マスターは自身のオフセットを継続的に蓄積し、スレーブも自身のオフセットを継続的に蓄積します
スレーブは自身のオフセットを毎秒マスターに報告し、マスターも各スレーブのオフセットを保存します

これは、完全なレプリケーションに特に使用されるという意味ではありません。主な理由は、両方のスレーブが同じであることです。マスターとスレーブは、相互間のデータの不一致を知るために、それぞれのデータのオフセットを知る必要があります。

(2) バックログ

マスター ノードにはバックログがあります。デフォルトのサイズは 1MB です。
マスター ノードがデータをスレーブ ノードにコピーすると、バックログにもデータのコピーが同期的に書き込まれます。
バックログは主に完全レプリケーションに使用されます。中断後の増分レプリケーション

(3) マスター実行 ID

info サーバー、マスター実行 ID
が表示されます。マスター ノードが再起動したり、データが変更された場合、ホスト IP に基づいてマスター ノードを見つけることは信頼できません。 , その後、スレーブ ノードは異なる実行 ID に従って区別される必要があります。実行 ID が異なる場合は、完全なコピーが作成されます。
実行 ID を変更せずに Redis を再起動する必要がある場合は、redis-cli デバッグを使用できますreload command

（4）psync

スレーブノードはpsyncを使用してマスターノードからコピーし、psync runid offset
マスターノードは自身の状況に応じて応答情報を返します。完全レプリケーションをトリガーするのは FULLRESYNC runid offset である可能性があります。または、CONTINUE が増分コピーをトリガーする可能性があります

③フル コピー

(1) マスターは bgsave を実行し、rdb スナップショット ファイルをローカルに生成します
(2) マスター ノードは rdb スナップショット ファイルをスレーブ ノードに送信します rdb コピー時間が 60 秒 (repl-timeout) を超える場合、ノードはコピーが失敗したと判断します。このパラメータは適切に調整できます。
(3) ギガビット ネットワーク カードを搭載したマシンの場合、通常 1 秒あたり 100MB、6G のファイルが転送され、60 秒を超える可能性があります
(4) マスター ノードが RDB を生成しているとき、すべての新しい書き込みコマンドはメモリにキャッシュされます。スレーブ ノードが RDB を保存した後、新しい書き込みコマンドはスレーブ ノードにコピーされます。
(5) client-output -buffer-limit スレーブ 256MB 64MB 60、コピー中にメモリ バッファが 64MB 以上を消費し続けるか、一度に 256MB を超える場合、コピーを停止し、コピーは失敗します。
(6) スレーブ ノードが rdb を受信した後、古いデータ バージョンに基づいて外部サービスを提供しながら、自身の古いデータをクリアし、メモリ内の rdb を自身に再ロードします。
(7) スレーブ ノードが AOF をオンにすると、BGREWRITEAOF が即座に実行され、 AOF は書き換えられます

rdb の生成、ネットワーク経由の rdb コピー、スレーブ古いデータのクリーニングとスレーブの aof の書き換えには非常に時間がかかります

コピーされたデータの量が 4G ～ 6G の場合の場合、フル コピー時間は 1 分半から 2 分かかる可能性があります。

④増分レプリケーション

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

⑤ハートビート

マスター ノードとスレーブ ノードは相互にハートビート情報を送信します

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

##⑥非同期レプリケーション

#マスターが書き込みコマンドを受信するたびに、データを書き込むようになりました内部的に送信し、スレーブ ノードに非同期で送信します。

2. 読み取りと書き込みの分離: マスターは書き込み操作を担当し、スレーブはマスターによるアクセス クエリの削減を支援する責任を負います。

##2. 高可用性メカニズム

高同時実行性の場合、複数のクラスターに 1 つのマスターと複数のバックアップが装備されます。は 1 つのホストのみです。マスターがダウンし、システム全体が書き込み操作を実行できず、スレーブがデータを同期できない場合、システム全体が麻痺し、システム全体が使用できなくなります。 Redis の高可用性メカニズムはセンチネル メカニズムです。センチネルは Redis クラスターの重要なコンポーネントであり、クラスターの監視、情報通知、フェイルオーバー、構成センターを担当します。

(1) クラスター監視。Redis マスタープロセスとスレーブプロセスが正常に動作しているかどうかを監視します。

(2) メッセージ通知。Redis インスタンスに障害が発生した場合、センチネルはアラーム通知としてメッセージを送信します。管理者に送信

(3) フェイルオーバー、マスター ノードがハングアップした場合、自動的にスレーブ ノードに転送されます

(4) 構成センター、フェイルオーバーが発生した場合、クライアントに新しいマスター アドレスを通知します
Sentinel それ自体が分散されており、クラスターとして機能するため、連携して動作する必要があります。

マスター ノードがダウンしていることが判明した場合、分散選挙を伴う監視員の過半数の同意が必要になります。

センチネル メカニズムは、堅牢性を確保するために少なくとも 3 つのノードを確保する必要があります。テスト中に 2 つのノード (1 つはマスター ノード、もう 1 つはスレーブ ノード) のみを指定した場合、責任を負うセンチネルが存在します。監視では、マスター ホストがダウンすると、選出にセンチネルが必要になります。その場合、マスター ノードの s1 センチネルは機能できなくなり、選出はスレーブ ノードの s2 センチネルによってのみ実行できます。選択後、フォールトを実行する必要があります。転送には 1 つのセンチネルが機能する必要があり、その多数派パラメータはフェイルオーバーに必要なセンチネルの数を指定します。現時点では、フェイルオーバー用の多数派を持たない S2 センチネルは 1 つだけです。したがって、堅牢性を確保するには少なくとも 3 つのノードが必要です。

3. 高可用性と高同時実行性に起因するデータ損失の問題

(1) 非同期レプリケーションによって発生するデータ損失

理由は、マスター -> です。スレーブのレプリケーションは非同期であるため、一部のデータはマスターがクラッシュする前にスレーブにコピーされず、データのこれらの部分が失われる可能性があります。

(2) スプリット ブレインによるデータ損失

スプリット ブレイン、つまりマスターが配置されているマシンが突然通常のネットワークから外れ、他のスレーブ マシンに接続できなくなりますが、実際、マスターはまだ実行中です。

この時点で、センチネルはマスターがダウンしていると判断し、選挙を開始して他のスレーブをマスターに切り替える可能性があります。

現時点では, クラスターには 2 つのスレーブが存在します。マスターがあり、いわゆるスプリット ブレインです。

この時点でスレーブがマスターに切り替わりますが、クライアントには切り替える時間がない可能性があります。

したがって、古いマスターが再び復元されると、古いマスターは独自のスレーブとして新しいマスターにハングされます。データは消去され、新しいマスターから再度データがコピーされます。

非同期レプリケーションとスプリット ブレインによるデータ損失の解決策

min-slaves-to-write 1
 min-slaves-max-lag 10

少なくとも 1 つのスレーブが必要です。データ レプリケーションと同期の遅延は 10 秒を超えることはできません

1 回の場合スレーブ、データ レプリケーション、および同期の遅延が 10 秒を超えると、この時点でマスターはリクエストを受信しなくなります

上記 2 つの構成により、非同期レプリケーションとスプリット ブレインによるデータ損失を軽減できます

(1) 非同期レプリケーションによるデータ損失を軽減します

min-slaves-max-lag を使用する構成を変更すると、スレーブ コピー データと ACK 遅延が長すぎると、マスターがダウンした後に大量のデータが失われる可能性があると考えられ、書き込み要求が拒否されます。これにより、一部のデータが失われるのを防ぐことができます。スレーブによるデータ損失を制御可能な範囲で低減する

(2) スプリットブレインによるデータ損失を低減

マスタがスプリットブレインの場合この構成により、指定された数のスレーブにデータを送信し続けることができず、スレーブが 10 秒以上自分自身に ack メッセージを送信しない場合、クライアントの書き込みが確実に行われます。リクエストは直接拒否されます

このようにして、スプリット ブレイン後の古いマスターはクライアントからの新しいデータを受け入れなくなり、データ損失が回避されます。いずれかのスレーブとの接続が失われ、10 秒後にどのスレーブも自身に ACK を返さない場合、そのリクエストは拒否されます。新しい書き込みリクエスト

したがって、スプリット ブレイン シナリオでは、最大 10 秒間のデータが失われた

プログラミング関連の知識については、

プログラミング入門

をご覧ください。 ！

以上がRedis の高可用性と高同時実行メカニズムの詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。