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

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

Redis 备份、容灾及高可用实战的示例分析

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

オプション 2

Redis 备份、容灾及高可用实战的示例分析

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

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

メリット

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

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

不足

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

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

Redis 备份、容灾及高可用实战的示例分析

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

実行スレーブ 1 をアップグレードするためのスレーブ 1 上の「slaveof no one」コマンドは、新しいマスターノードになります。
Slave1 を書き込み可能に設定します。これは、ほとんどの場合、スレーブが読み取り専用として設定されているためです。
クライアント (つまり、Redis に接続するプログラム) に新しいマスターノードの接続アドレスを伝えます。
新しいマスターからデータをコピーするようにスレーブ 2 を構成します。

アーキテクチャプラン 2

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

Redis 备份、容灾及高可用实战的示例分析

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

Slave1 で smileof no one コマンドを実行して、Slave1 を昇格させます。新しいマスターノードとして
Slave1 を書き込み可能に構成します。これは、ほとんどの場合、スレーブ構成が読み取り専用であるためです。
新しいマスターからスレーブ 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 アーキテクチャ

Redis 备份、容灾及高可用实战的示例分析

##7. Redis Sentinel 実装原則

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

1) リーダーを選出するためにセンチネル間で選挙が行われ、選出されたリーダーがフェイルオーバーを実行します
Sentinel リーダーは、スレーブノードから 1 つを新しいマスターノードとして選択します。その文を書き直すと次のようになります。スレーブ選出を実装するには、次の選出方法を実行する必要があります。 a) マスターからの切断までの時間

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

b) スレーブの優先度

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

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

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

d) 実行 ID

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

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

Redis 备份、容灾及高可用实战的示例分析