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

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 サイトの他の関連記事を参照してください。