Redis バックアップ、災害復旧、高可用性の実践の分析例

1. Redis の簡単な紹介

Redis は、高パフォーマンスのキー/値非リレーショナル データベースであり、その高性能特性により、高可用性、永続性をサポートします。 、および複数のさまざまなデータ構造、クラスターなどにより目立つようになり、一般的に使用される非リレーショナル データベースになります。

さらに、Redis には多くの使用シナリオがあります。

セッション キャッシュ

Redis キャッシュ セッションには、ショッピング カート シナリオなど、長時間セッションを維持する必要があるアプリケーション シナリオで永続性が提供されるため、非常に優れた利点があります。優れた長時間セッションのサポートを提供し、ユーザーに優れたショッピング体験を提供します。

フルページキャッシュ

WordPressでは、Pantheonは、閲覧したページを最速でロードできる優れたプラグインwp-redisを提供しています。

Queue

Redis はリスト操作とセット操作をサポートしているため、メッセージ キュー プラットフォームとしての使用に非常に適しています。私たちは購入を制限するために Reids のキュー機能をよく使用します。たとえば、休日やプロモーション期間中に、ユーザーの購入行動を制限するためのアクティビティが実行され、今日の購入は数回のみ、または期間内に 1 回のみに制限される場合があります。応用にも適しています。

ランキング

Redis は、メモリ内の数値を増減する操作を非常に適切に実装しています。そのため、小説サイトで小説をランク付けし、ランキングに基づいて上位の小説をユーザーに推奨するなど、多くのランキングシナリオで Redis を使用しています。

パブリッシュ/サブスクライブ

Redis はパブリッシュおよびサブスクライブ機能を提供します。パブリッシュおよびサブスクライブには多くのシナリオがあります。たとえば、Redis のパブリッシュおよびサブスクライブ機能を使用して、次のようなスクリプトを作成できます。スクリプトトリガーのパブリッシュとサブスクライブ、チャットシステムの起動。

さらに、Redis が優れたパフォーマンスを発揮するシナリオは他にもたくさんあります。

2. Redis 利用における単一障害点の問題

Redis はさまざまな企業で利用されており、その多くの優れた機能と豊富なアプリケーション シナリオがその理由です。存在。 。そうなると問題やリスクも出てきます。 Redis には豊富なアプリケーション シナリオがありますが、一部の企業では依然として Redis アプリケーションを実践する際に比較的保守的に単一ノード デプロイメントを使用しているため、将来のメンテナンスにセキュリティ リスクが生じます。

私は 2015 年に単一障害点による業務中断の問題に対処したことがあります。 Redis が最初にデプロイされたときは、分散デプロイメントではなく単一ノード デプロイメントが使用され、災害復旧の問題は考慮されていませんでした。

当時、Redis サーバーを使用してユーザーの割引商品の購入を制御していましたが、原因不明の理由により Redis ノードのサーバーがダウンし、ユーザーの購入を制御できなくなりました。ユーザーが期間内に割引商品を複数回購入する行動。

このようなダウン事故は、会社にとって取り返しのつかない損失をもたらしたと言えます。セキュリティリスクの問題は非常に深刻です。当時システムを運用・保守していた者としては、次のような対応が必要でした。この問題を修復し、アーキテクチャを改善します。そこで、非分散アプリケーションにおける Redis の単一障害点を解決する方法について調査および学習を開始しました。

3. 非分散シナリオでの Redis アプリケーションのバックアップと災害復旧

Redis のマスター/スレーブ レプリケーションは現在、非常に一般的になっています。一般的に使用されるマスター/スレーブ レプリケーション アーキテクチャには、次の 2 つのアーキテクチャ ソリューションが含まれます。

一般的に使用される Redis マスター/スレーブ レプリケーション

オプション 1

通常の場合この構造は最も一般的で、1 つのマスター ノードと 2 つのスレーブ ノードがあります。クライアントはデータの書き込み時にはマスターノードに書き込み、読み取り時には2台のスレーブから読み取ることで読み取り拡張を実現し、マスターノードの読み取り負荷を軽減します。

オプション 2

このアーキテクチャには、1 つのマスターと 2 つのスレーブもあります。マスターとスレーブ 1 はキープアライブを使用して、さまざまな方法で VIP 移行を実装します。クライアントがマスターに接続するときは、VIP を介して接続します。これにより、解決策 1 の IP 変更の状況が回避されます。

Redis マスター/スレーブ レプリケーションのメリットとデメリット

メリット

マスター データのバックアップを実現します。マスターに障害が発生した場合、スレーブ ノードは新しいマスターに昇格し、古いマスター

の代わりにサービスを提供し続け、読み取り拡張を実現できます。マスター/スレーブ レプリケーション アーキテクチャは、通常、読み取り拡張を実現するために使用されます。マスターは主に書き込み機能を実装し、スレーブは読み取り機能を実装します

不足

アーキテクチャ ソリューション 1

マスターの場合失敗すると、クライアントはマスターから切断され、書き込み機能を実装できなくなり、同時にスレーブはマスターからコピーできなくなります。

現時点では、次の操作を実行する必要があります (Slave1 が Master に昇格すると仮定します):

1. 実行スレーブ 1 をアップグレードするためのスレーブ 1 上の「slaveof no one」コマンドは、新しいマスター ノードになります。

2. Slave1 を書き込み可能に設定します。これは、ほとんどの場合、スレーブが読み取り専用として設定されているためです。

3. クライアント (つまり、Redis に接続するプログラム) に新しいマスター ノードの接続アドレスを伝えます。

4. 新しいマスターからデータをコピーするようにスレーブ 2 を構成します。

アーキテクチャ プラン 2

マスターに障害が発生した場合、クライアントはデータ操作のためにスレーブ 1 に接続できますが、スレーブ 1 は単一ポイントになります。これは単一障害点 (単一障害点) であり、多くの場合回避する必要があります。

その後、次の操作を実行する必要があります。

1. Slave1 で smileof no one コマンドを実行して、Slave1 を昇格させます。新しいマスター ノードとして

2. Slave1 を書き込み可能に構成します。これは、ほとんどの場合、スレーブ構成が読み取り専用であるためです。

3. 新しいマスターからスレーブ 2 を構成します。データ レプリケーション

すべてのアーキテクチャ ソリューションでは、フェールオーバーのために手動介入が必要であることに注意してください。手動介入の必要性により、運用と保守の負荷が増大し、ビジネスにも大きな影響を及ぼします。現時点では、Redis の高可用性ソリューション - Sentinel

IV. Redis Sentinel の概要

Redis Sentinel は、Redis 用の高可用性ソリューションを提供します。実用的な観点から見ると、Redis Sentinel を使用すると、人間の介入なしで特定の障害を防ぐ Redis 環境を作成できます。

Redis Sentinel は分散アーキテクチャを採用し、共同で協力するために複数のプロセスを実行します。複数の Sentinel プロセスを実行して連携します。複数の Sentinel が特定のマスターにサービスを提供できなくなると、障害検出が実行され、誤検知の可能性が減ります。

5. Redis Sentinel の機能

Redis 高可用性ソリューションにおける Redis Sentinel の主な機能には、次の機能が含まれます:

監視

Sentinel はマスターとスレーブが期待どおりに正常に実行されているかどうかを常にチェックします

通知

Sentinel は API を通じてシステム管理者に通知できます監視対象の Redis インスタンスが失敗する

自動フェイルオーバー

マスターが期待どおりに実行されない場合、Sentinel はフェイルオーバー プロセスを開始でき、スレーブの 1 つがフェイルオーバー プロセスを開始します。それがマスターになると、他のスレーブは新しいマスターを使用するように再構成され、Redis サービスを使用するアプリケーションには、接続時に新しいアドレスを使用するように通知されます。

構成プロバイダー

Sentinel は、クライアント サービス検出の認証ソースとして使用できます。クライアントは Sentinel に接続して、特定のサービスを現在担当している Redis マスター アドレスを取得します。 。フェイルオーバーが発生した場合、Sentinel は新しいアドレスを報告します。

6. Redis Sentinel アーキテクチャ

##7. Redis Sentinel 実装原則

Sentinel クラスターは、それ自体と Redis マスター/スレーブ レプリケーションを監視します。マスター ノードに障害が発生したことが判明した場合、次の手順が実行されます:

• 1) リーダーを選出するためにセンチネル間で選挙が行われ、選出されたリーダーがフェイルオーバーを実行します

• Sentinel リーダーは、スレーブ ノードから 1 つを新しいマスター ノードとして選択します。その文を書き直すと次のようになります。 スレーブ選出を実装するには、次の選出方法を実行する必要があります。 a) マスターからの切断までの時間

マスターからの切断時間がダウンアフターミリ秒を超えた場合 ( Sentinel 設定 ) * 10 秒に、マスターが利用できないと Sentinel が判断してからフェイルオーバーの実行を開始するまでの時間を加えた場合、スレーブはマスターへの昇格には適していないと考えられます。

b) スレーブの優先度

各スレーブには優先度があり、redis.conf 構成ファイルに保存されます。優先順位が同じ場合は続行します。

c) コピー オフセット位置

コピー オフセットは、データがマスターからコピーされる場所を記録します。コピー オフセットが大きいほど、より多くのデータがマスターから受信されます。コピー オフセットが同様に、選択を続行します。

d) 実行 ID

最小の実行 ID を持つスレーブを新しいマスターとして選択します

フローチャートは次のとおりです:

• ##3) センチネル リーダーは、前のステップで選択された新しいマスターに対して、slaveof no one 操作を実行し、それを昇格させます。マスター ノード

• 4) Sentinel リーダーは他のスレーブにコマンドを送信し、残りのスレーブを新しいマスター ノードのスレーブにします

##5 ) Sentinel リーダーは、元のマスターをスレーブにダウングレードさせます。通常の操作が再開されると、Sentinel リーダーは新しいマスターから複製するコマンドを送信します。
上記のフェイルオーバー操作これらはすべて、手動介入なしで Sentinel 自体によって完了します。

以上がRedis バックアップ、災害復旧、高可用性の実践の分析例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。